Skip to main content

Event and delivery statuses

Three status fields describe the life of an event: the event status, the internal status and the delivery status of each subscriber. They are written only by the system. You cannot change them from a screen or from the API. The values come from the delivery worker in crates/services/app-server/src/services/integration_delivery.rs.

Event status​

Field Status in the Event monitor (column event_status).

ValueMeaning
newThe event was written. The worker has not handled it yet. This is the value the system writes.
partialAt least one non-polling delivery is still pending or processing. The worker looks at the event again on its next pass.
sentEvery delivery that the worker handles is sent. See the note on polling below. This is a final state.
failedNothing is pending and at least one delivery is failed. This is a final state.
skippedNo subscriber took the event: no subscriber is active, or none matches the event code and warehouse. This is a final state.

Moves (done in one pass of the worker; it looks only at events that are new or partial, 100 at a time, oldest first):

FromToWhen
new, partialskippedNo active subscriber exists, or no active subscriber matches.
new, partialpartialAfter this pass some non-polling delivery is still waiting (for example a retry delay).
new, partialfailedAfter this pass nothing waits and at least one delivery is failed.
new, partialsentAfter this pass nothing waits and nothing failed.

A partial event is picked up again every pass until it becomes sent or failed.

Polling subscribers do not count. A delivery for a subscriber with Delivery poll is created pending and left alone. The worker leaves it out of the decision, so an event that only polling subscribers wait for becomes sent while its delivery row still reads pending.

The value done is not written by the delivery worker. The clean-up job keeps terminal events for 30 days, then deletes rows whose event status is sent, failed or skipped. It preserves new and partial events because they may still need delivery work. Internal status is independent of this retention decision.

Internal status​

Field Internal (column internal_status).

ValueMeaning
newThe default. Nothing in-house has handled the event.
doneA built-in internal subscriber handled the event successfully and stored its result (IntegrationEventBmc::record_internal_result).

A failed in-house handling leaves the value at new and shows up as a failed or retrying delivery.

Delivery status​

Field Status in the Delivery log (column transmit_status).

ValueMeaning
pendingCreated, or waiting for the next try after a failure, or a polling delivery that nobody has collected.
processingA worker has taken the delivery and holds a 60-second lease. If the worker dies, the delivery can be taken again after the lease.
sentThe webhook answered 2xx, or the in-house handler succeeded. Final.
failedThe attempts reached Max Retries, or the Delivery value is not known to the worker (for example queue). Final.

Moves:

FromToWhen
(new row)pendingThe worker matched the event to the subscriber.
pendingprocessingA worker claims it: attempts are fewer than Max Retries and the wait time has passed.
processingsentSuccess. Attempts goes up by one, Last Error is cleared, HTTP Code is stored for a webhook.
processingpendingFailure with attempts still fewer than Max Retries. Attempts goes up by one. The next try waits Retry Delay × 2^n seconds (see Subscribers).
processingfailedFailure and Attempts has reached Max Retries.
pendingfailedThe subscriber's Delivery is not webhook, internal or poll. The error is unknown delivery method {value}.

A failed delivery is not tried again. There is no button or API method to retry it.