email-connect/docs/verification-retry-review-2026-10-07.md

Verification retry correction — 2026-10-07

Released: digest1e613d43 is live with one Ready replica. Founder approval, private backup, deployment and no-send verification are complete; the detailed receipt below includes the corrected validation-client failure.

Source contract: POST /v1/registration-verifications keeps its 202 JSON {request_id, accepted: true} response. Repeated tenant/client/registration operations return the same receipt after provider acceptance without resending. The correlation ID may change; changing recipient, username or display name for the same operation is rejected. A new registration is a separate operation.

A durable reservation precedes SMTP and keeps only the challenge digest. An unknown send outcome returns redacted 422 delivery_outcome_unknown, retryable=false, and keeps its usable challenge until expiry. Definitive retryable non-acceptance returns 503 and atomically cancels the failed challenge before retry. Permanent rejection stays terminal. Existing pre-upgrade challenges have no recorded SMTP outcome, so their retries fail conservatively while existing consume/cancel links keep working. There is no automatic resend or expired-challenge renewal for the same registration.

39 transactional tests passed. The full repository suite with the pinned GreenMail harness running passed all 101 tests with zero skips. The revised real SMTP/IMAP verification journey observed exactly one mailbox message after store restart and HTTP retry. Harness container/network were removed afterward. Synthetic fixture accounts only. Packaged image receipt follows separately.

Release scope is the email-connect container image only, reusing the live PVC, caller token, ConfigMap, ServiceAccount and NetworkPolicies. It does not authorize another caller, sender, provider or credential delivery. Founder live go remains separate from code preparation under the-custodian/docs/agent-environment-orientation.md section 4. The pre-release SQLite backup must use the SQLite backup API while consistent, with output kept private; never emit its rows.

Rollback: block sending first (scale receiver to zero, preserving its PVC), then compare/reconcile reservation outcomes. Old code ignores verification reservations: an unrestricted rollout undo can duplicate verification mail. Prefer rolling forward with the retry invariant preserved. Additive schema can be read by the old image, but schema compatibility is not delivery safety.

Published candidate and activation packet

Source: 7258505917. Image: forgejo.coulomb.social/coulomb/email-connect@sha256:1e613d43734c44c5cd32c6083fda8b4da5d01ef43d10c6ca9c29a33c788cf75c. Owner pin in deployment.yaml is now applied under the recorded founder approval. The packaged image passed synthetic retry/restart smoke as UID10001, with read-only root, temporary SQLite and network disabled. One provider call, unchanged request receipt and digest-only handle persistence were verified.

Fresh live observation/server preflight on railiance01: cluster UID a553c742-0115-43d4-99a4-a5ca56fe0786; node92.205.62.239 Ready, no pressure; CPU requests3455m/4000m; one Ready email-connect replica still on sha256:e095d7e51c68a29ff6b82d735c734d5d27e0041b937dc958ecee5bcb5ddf5e8b. Parsed dry-run spec comparison proves only the container image changes. Both guarded JSON image patch and non-root read-only-PVC backup helper passed server dry-run. No live object changed. Existing PVC=email-connect-data, Secret reference=email-connect-runtime.

Founder decision 8da41538-8482-4c72-b83d-e0fce1b662f0 was resolved following the founder's Ok, go ahead. Scope: ADMINISTER @ realm:kubernetes/railiance01, activation=APPROVED for this exact release. Do not apply the whole package to make this image correction: preserve live runtime ownership and use the reviewed guarded image patch.

Activation sequence: recheck UID/old digest/one replica/headroom; briefly scale email-connect to zero and wait for its pod to exit, preventing old/new senders from overlapping. Create the reviewed bounded helper with read-only data PVC and writable emptyDir /tmp, automountServiceAccountToken=false and no runtime env. Use stdlib SQLite backup API on the configured database into a private helper file; stream it to a fresh node-side mode0600 artifact in a mode0700 directory without printing bytes, addresses, rows or challenge handles. Validate backup integrity and record only its hash/size. Remove helper, apply JSON test(old image)+replace(new image), resume one replica and verify rollout/probes plus no-send authenticated rejection. No production mail is sent for acceptance. Native authentication SMTP/reset remains outside this receiver change.

Failure before the patch: remove helper and resume the old one replica. Failure after new code has served: stop sending and keep the PVC/backup; reconcile before any old-image rollback because the old verification code ignores reservations. This packet grants no new caller, platform sender or offsite backup consumer.

Completed release receipt

Release started2026-10-07T20:29:29Z; final new-pod Ready20:33:16Z, window227 seconds. First capture/update attempt58.27s completed the backup and image change, then failed its client-side authenticated check: the probe used the raw mounted token while the service normalizes it with strip(). Raw header construction raises ValueError; corrected normalization gives the expected denial. The safety path held the new receiver at zero replicas during repair; it never rolled back to old verification code. Resumption and all corrected checks took5.35s; one Ready replica remained healthy afterward.

Validation: healthz/readyz200, bad bearer401, approved bearer + disallowed invitation template400, empty verification400. SQLite integrity passes and the new verification_attempts table exists. These calls create no delivery/challenge records and send no mail. The post-repair spec comparison proves the resumption changed only replicas0→1; the pre-release server comparison proves the reviewed permanent change is the image. Backup helper pod count is zero.

Private backup: node root0700 /tmp/email-connect-preverification-20261007T202924Z/database.sqlite3, mode0600, 40960 bytes, SHA256 3b4651064fa7dd7bd5073ed8567480ea1f4cb527dbe6c7462cc778182e7da1f8. Matching workstation0700 /tmp/csoc-email-private-hkt09g6u/database.sqlite3, mode0600. Isolated image rehearsal as UID10001/network disabled adds the reservation table and preserves every row fingerprint in the four existing tables. No private values enter this receipt or Git; copies remain for the retention/custody handoff, not as proof of governed durable backup coverage.

Five synthetic deployment failure cases passed, including capture refusal, pre-patch failure and lost patch response/post-patch verification failure. Corrected historic execution helper is preserved in ../deploy/k8s/railiance/deploy-verification-2026-10-07.py. Its old-image guard refuses repeating this completed release; it is not a generic rollout tool.

EMAIL-WP-0006 is finished. Residual caller/sender/limit/ledger recovery work is live in CSOC-WP-0010-T04, inbox/bounce/retention/copy custody in T05, and cross-owner journey/user acceptance in T06. CSOC-WP-0008/0010 remain active.