X_AUDIT_SINK_FAILED

an action ran and its sink refused the record, so the change is unrecorded

the sink threw on an allowed record — the handler had already committed, so this is not a rollback. A refused denied/failed record is logged instead and the original error still reaches the caller, because answering with an audit error there would hide the X_FORBIDDEN and turn the audit backend's health into an oracle

the fix branches on whether this call is replayable, and meta.replayable carries the same fact. Replayable (the call arrived with an Idempotency-Key): fix the sink runtime.ts installs as auditSink, then retry with the same key — the replay re-records without re-running the handler. Not replayable (no key was in play, whether or not the action declares idempotent): fix the sink and reconcile this one change by hand — do not retry, because a second call runs the committed handler again