…#2837) * fix(rdbms): upsert in RescheduleExistingEnvelopeForRetryAsync (#2823) Closes #2823. Also resolves the same root cause for #2462. RescheduleExistingEnvelopeForRetryAsync unconditionally went through StoreIncomingAsync, an INSERT. Under ProcessInline + ScheduleRetry with RetryCount > 1, retry #1 inserted a Scheduled row, the durability agent redelivered it, and retry #2 collided on the (id, received_at) primary key with DuplicateIncomingEnvelopeException. The same INSERT-only path also failed for UseDurableInbox configurations whose inbox row was pre-persisted on arrival (#2462), there on retry #1. Try UPDATE first using the same SQL as ScheduleExecutionAsync. Fall back to StoreIncomingAsync only when 0 rows were affected — the no-pre-existing-row case covers BufferedLocalQueue's scheduled-publish path and ProcessInline's first retry, which is what the unconditional INSERT was reaching today. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(oracle): align RescheduleExistingEnvelopeForRetryAsync with upsert semantics Oracle's RescheduleExistingEnvelopeForRetryAsync was UPDATE-only and only touched execution_time and attempts. That silently no-op'd for ProcessInline retry #1 (no row to update) and never matched ScheduleExecutionAsync's column shape (status, owner_id), leaving the Oracle inbox subtly out of step with the other RDBMS providers. Mirror the MessageDatabase<T> fix: UPDATE with the full ScheduleExecutionAsync shape, fall back to StoreIncomingAsync when 0 rows are affected. Set envelope.Status / OwnerId up front so the body persisted on the INSERT fallback matches the column state. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Streamline persistence library names #2

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions