dohertj2/mxaccessgw
1
0
Fork 0
Code Issues 14 Pull Requests 2 Actions Packages Projects Releases Wiki Activity

Merge docs/runbook-evidence-precision: what the deployed-build identification evidence rests on
ci / nightly-windev (push) Has been skipped
Details
ci / windows-x86 (push) Successful in 1m17s
Details
ci / java (push) Successful in 2m51s
Details
ci / portable (push) Successful in 10m51s
Details

Browse Source
This commit is contained in:
Joseph Doherty
2026-08-11 06:06:48 -04:00
parent e5dbcee17c f6b6184e70
commit 22a34f7f31
1 changed files with 15 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/runbooks/IdentifyingADeployedBuild.md
+15 -3
View File
@@ -48,7 +48,13 @@ In rough order of cost:
`statuses` proves it is not. Keep it non-destructive by writing to a read-only tag — the refusal `statuses` proves it is not. Keep it non-destructive by writing to a read-only tag — the refusal
still exercises the path and returns `OPERATIONAL_ERROR` with detail `1007`. still exercises the path and returns `OPERATIONAL_ERROR` with detail `1007`.
2. **PDB source hashes.** Slower, needs the deployed symbols, but independent of anything the build 2. **PDB source hashes.** Slower, needs the deployed symbols, but independent of anything the build
stamped. This is what settled the 2026-08-11 investigation. stamped. **Do not read this as *the* technique on its own.** What settled the 2026-08-11
investigation was two independent derivations agreeing: a PDB source-hash match, and a
contemporaneous deploy record written the same evening that named the same two commits. The
convergence is the result's strength, not either method alone — a hash match tells you which
sources a binary was built from, but not that the build was intentional or which host it went to.
A reader with only one of the two available should weight it accordingly and look for a second
line of evidence.
3. **Deployment-side naming.** Since 2026-08-07 the server deploys to a dated directory 3. **Deployment-side naming.** Since 2026-08-07 the server deploys to a dated directory
(`Server-YYYYMMDD`) with the NSSM `Application`/`AppDirectory` repointed at it, and backup (`Server-YYYYMMDD`) with the NSSM `Application`/`AppDirectory` repointed at it, and backup
directories carry operator-chosen labels naming the work (for example directories carry operator-chosen labels naming the work (for example
@@ -68,8 +74,14 @@ the server and a later one for the worker.
The 2026-08-09 deploy was **two separate swaps**, which is why a single build time does not describe The 2026-08-09 deploy was **two separate swaps**, which is why a single build time does not describe
it: the 2026-08-11 investigation dated the server file write to 19:20:24 and the worker to 19:50:06, it: the 2026-08-11 investigation dated the server file write to 19:20:24 and the worker to 19:50:06,
the latter two minutes after `53f69cd` merged at 19:48. The two worker backup directories from that the latter two minutes after `53f69cd` merged at 19:48, with a matching service stop/start at
day are the second swap's fingerprint, not redundancy. 19:50:29/34.
That reading is confirmable from artifacts still on disk, without trusting the narrative: windev
carries **two** worker backup directories from that day (`Worker.bak-20260809` and
`Worker.bak-20260809-planwrites`), and wonder carries `Worker.bak.20260809-planwrites`. Two backups
because there were two worker operations. This is easy to misread as redundancy — it is the second
swap's fingerprint.
## The 2026-08-09 deploy returned the worker to mainline ## The 2026-08-09 deploy returned the worker to mainline