Skip to content

Record the rest of the game day, and say what it found - #69

Merged
Bryancruzcb merged 1 commit into
mainfrom
ops/gameday-results
Sep 24, 2026
Merged

Bryancruzcb merged 1 commit into
mainfrom
ops/gameday-results

Conversation

@Bryancruzcb

Copy link
Copy Markdown
Owner

Finishes the game day's measured part. Data and docs only, no script changes.

What's in it

deploy/gameday/results.tsv gets five rows:

scenario when (UTC) outcome the numbers
02-fill-disk 09-22 06:44 cleared pending 45 s, firing 646 s, cleared 707 s
02-fill-disk 09-22 06:56 cleared pending 45 s, firing 646 s, cleared 706 s
02-fill-disk 09-23 19:28 cleared pending 60 s, firing 661 s, cleared 721 s
03-stale-index 09-23 19:30 indexed (no-op) nothing to index: 60 s, 5,941 chunks before and after
03-stale-index 09-23 23:21 indexed 409 chunks in 181 s, index age back to 0 mid-write, canary 1.00

The two 09-22 disk runs finished on the node after PR #65 but only ever reached SSM's command output. They were read back from aws ssm list-command-invocations (commands 5804eaf1, 097fac2a).

deploy/gameday/README.md:

  • Opens with what each scenario found, replacing "Nothing here has been run yet".
  • Scenario 3 now says the Job is incremental, so a run only measures something after a vault sync that changed notes. That's why there are two runs and not three.
  • Scenario 4's "exit 3 is the state this repository is in today" now records that the cloud scorecard was taken on 2026-09-21 (f1cf665).

Not done

  • A third scenario 3 run. It needs another vault sync with changes, or a --full variant of the script. The variant isn't built.
  • The destroy-and-rebuild proof and cost.md's measured row. Both wait for the next ops.py up and for September to close.

Report

Paradigm: none. Data rows and prose, no code unit changed.
Changed: deploy/gameday/results.tsv (5 rows), deploy/gameday/README.md (3 sections).
Rules applied: FP-01, results kept as inert data in the file the scripts already read their header from. The field count of every row was checked against the header before writing.
Verified: every number is copied from the scripts' own result rows (SSM output for the 09-22 runs, send_command.py output for the 09-23 runs). Rows read back from the file: 11 columns, 12 rows.
Unverified: CI hasn't run on this branch yet.
Deviations: scenario 3 has two runs where PLAN.md asks for three, and the first overlapped a disk run. Both are stated in the README instead of being dropped.

Five rows join results.tsv. Three are scenario 2 at the new 83 percent
target: two ran on 2026-09-22 after PR #65 but only ever reached SSM's
output, and one ran on 2026-09-23. All three went the same way:
DiskAlmostFull pending at 45 to 60 s, firing at 646 to 661 s, cleared by
itself about 60 s after the filler was removed.

Two are scenario 3 on staging. The first measured nothing: the indexer Job
is incremental, nothing had changed since the last sync, so it finished in
60 s with the chunk count unchanged and the index age still climbing. It
also overlapped the third disk run. The second followed a desktop vault
sync of 56 changed notes: 409 chunks added in 181 s, the API's index age
back to 0 while the Job was still writing, canary at 1.00 throughout, no
failed readiness check. PR #25's reopen held.

The README said nothing had been run and that scenario 4 could only report
no-card. Both were stale: it now opens with what each scenario found, says
why scenario 3 needs a vault sync before every run, and records when the
cloud scorecard was taken.
@Bryancruzcb
Bryancruzcb merged commit bc0e0b5 into main Sep 24, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant