Middle · Trace · If-Match and atomic versioned updates

Portable .NET9 console only: predict every printed line and explain how one successful update changes the later stale and weak decisions. State which real HTTP, SQL or infrastructure guarantee this program does not test.

Think through your answer before opening the explanation.

Production engineering

using System;
using System.Linq;
using System.Collections.Generic;
using System.Globalization;
using System.Text;
using System.Text.Json;
using System.Threading;
using System.Threading.Tasks;

int version=1; bool Update(int expected,bool weak) { if(weak||expected!=version)return false; version++; return true; }
Console.WriteLine("updated:"+Update(1,false)); Console.WriteLine("version:"+version); Console.WriteLine("stale:"+Update(1,false)); Console.WriteLine("weak:"+Update(2,true));
Reveal answer and reasoning

Version starts at one. Update with expected one and a nonweak flag succeeds, increments to two and prints updated:True. The next line prints version:2. Repeating expected one is stale, so stale:False follows without changing the value. Offering expected two with a weak flag also fails, producing weak:False. The sequence has one memory owner and no concurrent caller. It explains the decision table but cannot establish atomic SQL comparison, missing-header428 behavior, wildcard syntax or list semantics.

Those are actual external cases that must be tested through the real adapter.

The real lab rejects a missing precondition with428, accepts a v1 write as version two and rejects stale v1 or weak v2 with412 without changing the document. Wildcard behavior is tested separately. A controlled concurrency check pauses one request before it opens a transaction, lets another writer commit version four, then releases a request carrying v3 and v4. It reads current state inside its transaction and succeeds as version five.

No database transaction is held during the pause. This proves the full candidate list is evaluated at the actual owned boundary rather than narrowed to an earlier observed version.

What a strong answer covers

  • The console advances version1 to2 once, then rejects stale and weak inputs.
  • Actual missing If-Match is428; a stale or weak mismatch is412 without a write.
  • The full parsed list is evaluated after reading current state inside the same SQLite write transaction.

Common pitfall

Assuming a pre-read narrowed to one version preserves the semantics of the entire If-Match list.

Follow-up questions

  1. How can a stale pre-read reject a still-valid multi-tag condition?
  2. Which user-facing merge and authorization decisions remain after a412?

Self-review

Choose what to revisit. These marks are your own assessment and are separate from lesson completion.

Primary references

Open lesson and code ↗

← All interview questions