Implement an EF Core update that refuses to overwrite an order changed since the client loaded it.

• Use the client-supplied version as EF's original value.
• Do not automatically retry a user-authored edit with fresh values.
• Return a stable conflict response for the client.
• Pass cancellation to query and save calls.

I load the entity, apply the intended field change, and replace EF's original concurrency value with the version the client actually edited. EF includes that version in the update predicate. A concurrency exception means the row was deleted or changed after the client's read, so I return a conflict and let the user reload or merge deliberately.

public static async Task<UpdateOrderResult> UpdateDeliveryNoteAsync(
    AppDbContext db,
    Guid orderId,
    UpdateDeliveryNote request,
    CancellationToken cancellationToken)
{
    var order = await db.Orders
        .SingleOrDefaultAsync(
            candidate => candidate.Id == orderId,
            cancellationToken);

    if (order is null)
        return UpdateOrderResult.NotFound();

    order.DeliveryNote = request.DeliveryNote.Trim();
    db.Entry(order)
        .Property(candidate => candidate.RowVersion)
        .OriginalValue = request.RowVersion;

    try
    {
        await db.SaveChangesAsync(cancellationToken);
        return UpdateOrderResult.Updated(order.RowVersion);
    }
    catch (DbUpdateConcurrencyException)
    {
        return UpdateOrderResult.Conflict(
            "The order changed after you opened it. Reload before saving again.");
    }
}

EF generates an update constrained by primary key and original rowversion. A matching index already exists through the primary key lookup. Conflict rate is operationally useful: frequent conflicts may reveal a workflow problem rather than a need for blind retries.

• The row is deleted after the initial client read.
• The request contains an invalid or missing version.
• The note changes independently from another field.
• The client submits the same update again after success.

• Run two contexts against the same original version.
• Verify the losing writer does not overwrite stored data.
• Test deletion between read and save.
• Verify the successful response returns the new version.

• Comparing rowversion only in application memory.
• Using the freshly loaded version instead of the client's original version.
• Automatically retrying and silently overwriting another user's decision.
• Returning a generic 500 response for an expected conflict.