Skip to main content

Asset Retry and Failure

Summary​

A publish failure marks the outbox row failed, increments its retry count, and leaves it eligible for the next relay pass. There is no verified retry ceiling, backoff, or dead-letter path.

Audience​

Engineering, integration, QA, architecture, security, and product reviewers.

Reference Content​

Failure handling on publish​

OutcomeAction
PublishAsync returns successMarkProcessed: status Processed, ProcessedOnUtc stamped, error cleared
PublishAsync returns falseMarkFailed: status Failed, RetryCount + 1, error text recorded
PublishAsync throwsLogged as a warning, then MarkFailed (same as above)
Relay iteration itself throwsCaught and logged; loop continues on the next poll

Retry mechanics​

GetPendingAsync selects rows whose status is Pending or Failed. A failed row is therefore picked up again on the next 10-second pass and retried. RetryCount increases each time but is not compared against any ceiling in the verified source.

What is not implemented​

  • No maximum retry count or give-up threshold.
  • No backoff or delay between retries (retries occur every poll).
  • No dead-letter storage or dead-letter routing on the producer side.
  • No automatic outbox cleanup of processed or failed rows.

Because a failed publish never blocks the writing request, an asset lifecycle change is durably recorded even when the broker is unavailable; the event remains pending until publication succeeds.

Requires confirmation​

Retry ceilings, backoff policy, dead-letter strategy, alerting on stuck rows, and outbox retention/cleanup require confirmation.

Source References​

  • microservices/src/shared-kernel/Messaging/OutboxProcessor.cs
  • microservices/src/asset-service/Infrastructure/Persistence.cs
  • microservices/src/asset-service/Messaging/OutboxRelayHostedService.cs

See Also​

Keywords​

  • Retry
  • Failure handling
  • No dead-letter

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-17
  • Review cycle: Quarterly