Repository navigation
fix(session-erasure): map the pipeline's unsupported_storage refusal to a static 503 - #114
Conversation
…to a static 503
The pipeline answers an erase it cannot perform with its current storage or
ingest state with 503 {"error":"unsupported_storage","feature":"session_erase"}.
Repeating that request cannot succeed, so Control now reports it as a
non-retryable 503 session_erasure_unsupported_storage with a fixed message
and no retry hint, on both the erase and the verification read.
Only a 503 body is read, bounded to 4096 bytes with the reader cancelled on
every path; the match is exact on both fields. Anything else (other codes,
wrong or missing feature, malformed, empty or oversized bodies, read failures,
other 5xx) stays the static retryable session_erasure_unavailable, 501 stays
not_implemented, and no upstream text or Retry-After is forwarded.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
Important Review skippedBot user detected. To trigger a single review, invoke the
 |
|
Independent exact-head review of df7a108: PASS, no material findings. Adversarial pass: only HTTP503 with the exact unsupported_storage/session_erase marker selects the new static error; malformed/oversized/wrong-feature/other5xx retain the retryable outage error. The new error-body read is capped at4096 bytes and cancels its reader in finally; no upstream text, identifiers or Retry-After reaches the client. Both DELETE and verification GET are covered, with no change to authorization, tenant/workspace targeting or completion/audit proof. Extra provider fields cannot be echoed. 501 remains the existing Contextual pass: matches pipeline#516 head4b4d2410 and the permanent-for-current-state RH011/RH013 contract. Static message gives no blind retry instruction; OpenAPI/docs cover both routes and preserve transient outage behavior. The earlier coordination note's stale501 label was corrected to the existing Validation on this exact Control head: targeted session-erasure tests 13/13, typecheck passes, and the actual cross-repo Control HTTP -> pipeline4b4d2410 -> PGlite/versionedMinIO/Postgres-search proof passes 57 assertions. Existing package/lock bytes equal the previously installed fixture checkout; no code/dependency changes made in this review. CI run43024452745 reports SUCCESS. This is an independent source comment, not a merge or activation bypass; Khaliq/merge loop owns integration. No real database/store/deploy or flag action. |
Summary
The history pipeline now answers an erase it cannot perform with its current storage or ingest state with an authenticated
503 {"error":"unsupported_storage","feature":"session_erase"}. Repeating that request cannot succeed, so Control must not describe it as retryable.503 session_erasure_unsupported_storagewith the fixed messageThis session cannot be erased with the current storage or ingest configuration.and no retry hint. Both the erase request and the verification read share this mapping.503 session_erasure_unavailable: other codes, wrong or missingfeature, malformed, empty, non-object or oversized bodies, read failures, other 5xx and network errors.501staysnot_implemented.Retry-Afteris not forwarded. The two-field error shape is unchanged.docs/session-erasure.mdand both503descriptions inopenapi.yamllist the new code.Source only. The feature stays default-off; no deployment, flag or permission change is implied.
Tests
New test in
test/session-erasure.test.tscovering the DELETE and the verification GET, the exact recognised refusal with an upstreamRetry-Afterheader, provider text alongside the exact shape, wrong feature / missing feature / wrong case / other codes / array / string / non-JSON / empty / oversized bodies, 501 with the same body, and 500 with the same body. The existing table test (too_many_ownersand{}stillsession_erasure_unavailable) is unchanged.Local checks on the PR head (
layered-heavy, one worker):npm run typecheckexit 0;test/session-erasure.test.ts13 tests, 13 pass, 0 fail, 0 cancelled.🤖 Generated with Claude Code
Open in [code]smith · Need help on this PR? Tag
@codesmith-botwith what you need.Summary by cubic
Maps the history pipeline's
unsupported_storagerefusal to a static, non-retryable 503 so Control stops describing an unretryable erase as retryable.errorandfeaturefields match exactly, returns503 session_erasure_unsupported_storagewith a fixed message, no retry hint, and no forwardedRetry-After— on both the erase request and the verification read.session_erasure_unavailable;501staysnot_implemented.docs/session-erasure.mdand both503descriptions inopenapi.yamllist the new code.Written for commit df7a108. Summary will update on new commits.