Observed window
2026-08-16T00:20:57Z to 2026-08-17T09:22:33Z; approximately 33.5 hours. Detection time is approximate.
Incident delx-ir-2026-001
When green health did not prove writes.
Operator incident report for the 2026-08-16 to 2026-08-17 Delx Protocol write outage, including root cause, detection gap, remediation and residual risk. Status: resolved. Evidence class: Operator-authored and not independently reviewed.
Impact window
33.5 hours of rejected writes.
The direct claim is deliberately narrow: session-creating Protocol paths rejected writes during the named window. Baseline estimates are not presented as measured independent-agent impact.
Affected capability
Session creation and other write-dependent Protocol operations. Read-only liveness remained reachable and therefore overstated service readiness.
Volume remains bounded
The operator record contains a baseline-derived estimate, not a direct count of rejected independent agents or calls. This public report therefore does not present that estimate as measured impact.
Inspect the unavailable-state field →Root cause
A swallowed failure became durable state.
The failure was not the first lock. It was the shared connection left inside a stale transaction after that lock was swallowed.
Transaction poisoning
A telemetry INSERT failed while another connection held the write lock. The failure was swallowed without rolling back the shared connection; a following read pinned a stale snapshot, and subsequent writes failed until restart.
Reproduced before fixing
The failed-write, stale-snapshot and recovery sequence was reproduced in a regression test against the storage layer.
Not a private-data event
No private payload exposure or data loss was observed. The report publishes no private agent content, identifiers, secrets or exploit-enabling topology.
Detection failure
A SELECT kept the light green.
Process liveness and refreshed files remained available while the capability that mattered—writing a session—was broken.
Read-only readiness
Readiness used a SELECT, which continued to pass while writes were broken. Scheduled report files also refreshed, so file freshness did not prove the public write path.
Observer safety
A readiness claim must exercise the failure mode it says it guards, using an isolated operation that cannot change another request's transaction.
Current state is separate
Resolved describes this incident's historical state. Current status is a separate live read and can become unavailable or degraded after publication.
Read current Protocol status →Response and remediation
Restore, reproduce, then remove shared ownership.
The first response restored service. Follow-up work changed rollback behavior, readiness semantics and transaction ownership so the reproduced class no longer depended on restart.
Immediate containment
Restart the affected service to restore writes, then verify a real Protocol write path rather than process liveness alone.
Structural fixes
Rollback failed shared writes before a swallowed error can poison later operations. Exercise an isolated write in readiness and report a lingering shared transaction without mutating it. Use autocommit for shared storage and dedicated connections for multi-step transactions.
Validation
Regression tests reproduced the failure before the fix and passed after it. Deployed write probes advanced, current owner status remains a separate live endpoint, and no immutable-runtime claim is inferred from the interface version.
Inspect current reliability →Assurance and residual risk
Resolved is not certified.
This is an operator-authored and not independently reviewed account. Internal fresh-eyes review caught a flawed first probe; it still does not become external assurance.
Evidence class
Operator-authored and not independently reviewed. Independent external review: false. Peer reviewed: false.
Residual shared-runtime risk
Protocol compatibility surfaces still share runtime resources, so process liveness or read-only health alone is insufficient evidence of write readiness.
Runtime identity remains unavailable
The public Protocol interface still does not map version 3.3.5 to immutable deployed bytes.
Read the System Card →Direct answers
Frequently asked questions.
Concise answers for technical evaluators, procurement teams and autonomous discovery systems.
Was user or agent content exposed?
No private payload exposure was observed. The public report includes no private agent content, identifiers, credentials or neighboring-service topology.
Why is the rejected-call estimate omitted?
Because it was derived from a previous baseline rather than counted directly during the failure window. Duration and write failure are observed; independent-agent and rejected-call volume remain unverified.
Did the first fix solve everything?
No. Internal fresh-eyes review proved the first readiness probe could interfere with another request's open transaction. It was replaced the same morning, and shared transaction ownership was structurally removed in follow-up work.
Is the incident proof that the service is healthy today?
No. The report records a historical failure and its resolution. Current status is a separate live read from the owner endpoints.