1.9 KiB
Audit run lifecycle and data integrity under failure
Type: research Status: resolved
Question
Under process termination, restart, timeout, duplicate Feishu delivery, database failure, or concurrent requests, which AgentRun, lock, session, workspace, audit, and outbound-message invariants can be violated or leave work lost, duplicated, or permanently stuck?
Answer
The happy path and database lock uniqueness work, but the lifecycle is not crash-safe. Deterministic fault injection confirmed permanent inbound loss, terminal runs retaining locks, active runs losing locks, duplicate active sessions, completion without outbound delivery, unconstrained audit run IDs, and max-turn termination being stored as failure. Process-local queues, non-transactional startup recovery, unused leases, silent audit/history writes, and direct workspace mutation add restart and indefinite-hang failure modes.
The complete contract mapping, eight fault probes, recovery analysis, and required release evidence are in the run lifecycle and data-integrity audit.
The newly-clear implementation and decision frontier is:
- Make Feishu intake and queued work durable
- Make run, session, lock, and recovery transitions safe
- Make outbound Feishu delivery durable and idempotent
- Decide workspace commit semantics for failed runs
- Reconcile the audit and run-history contract
Execution-time authorization remains owned by Bind and reauthorize deferred and card actions, while cross-component metrics, alerts, and operator runbooks remain owned by Define production observability and incident recovery.