root/Jyotisha
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

docs(staging): close bounded fetch incident
Staging Backend Quality Gate / validate (pull_request) Successful in 12m46s
Details
Staging Backend Quality Gate / publish (pull_request) Has been skipped
Details

Browse Source
This commit is contained in:
Jesse
2026-08-06 18:00:40 +08:00
parent 52b467cbe5
commit fa8698c95b
3 changed files with 9 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/research/pre_work_error_ledger.md
+1 -1
View File
@@ -145,7 +145,7 @@ A failed exact-SHA staging deploy displayed the multiline staging SSH private ke
Prevention: store `STAGING_SSH_PRIVATE_KEY` only as one unwrapped base64 line; workflows decode it into a mode-`0600` temporary key, validate it with `ssh-keygen`, and delete the temporary directory on every exit. Contract tests must reject direct multiline `SSH_PRIVATE_KEY` injection or `printf` of a decoded secret variable. A leaked staging key must be rotated and revoked before any rerun; production keys remain a separate boundary and were not involved in this incident.
## ERR-095 | Gitea trusted-main fetch can stall until the whole deploy job times out | investigating 2026-08-06
## ERR-095 | Gitea trusted-main fetch can stall until the whole deploy job times out | mitigated 2026-08-06
After exact-SHA staging gate `1473` succeeded, automatic deploy `1474` stopped making log progress for an extended period in the empty-repository `git fetch --no-tags origin main "$DEPLOY_SHA"` step before any SSH or staging mutation. Public and state SHAs remained on the previous healthy release during the stall. The fetch later recovered and the 18-minute run successfully deployed the exact SHA, but the checkout had no command-level bound; without recovery, the 30-minute job timeout was the only escape and the shared mutation queue would remain occupied. The underlying Git transport stall is not proven.