docs(plans): correct S16's #269 claim about S13 Step 11

What does this MR do and why?

The S16 container-remote plan says S13 Step 11 resolves the transfer-deadline gap in #269 before wiring the UpstreamDoer adapter into Fetch, and makes that the reason S16 does not block on 269. S13 Step 11 settled the gap the other way: it ratified the flat request_total_timeout as written rather than replacing it. So 269 stays open, and no S13 plan step is left to carry it.

The plan is otherwise write-once after its plan MR, so the correction travels here rather than in a step branch. It matters before Track B rather than at it. Step 12's External prerequisite bullet is one of the places that repeats the claim, but Step 12 is roughly eight Track A MRs out — Steps 1c, 2a-2c, 7, 8, 10, and 11 come first. Until this lands, the plan tells every reader that S13 Step 11 carries 269, including anyone triaging 269 itself, which is open and unowned.

What S13 Step 11 actually delivers to S16

Named as the prerequisite State
the remote.UpstreamDoer adapter over upstreamhttp.Client on maininternal/remote/upstreamhttp/doer.go, Doer and NewDoer
the shared remotetest/conformance.go seam assertion on mainremotetest.AssertUpstreamDoerConformance
the 269 transfer-deadline resolution not delivered — the flat bound was ratified instead

Both artifacts landed with !1290 (merged), the first of S13 Step 11's three MRs.

S13's own plan closes the plan obligation ("discharged by decision rather than by implementation"), while internal/remote/interfaces.go keeps the engineering problem open on the UpstreamDoer doc comment: "that ratification is not a closure of the underlying problem". Those are two claims, and the correction rests on both. Only S16's plan still carries the old reading.

Where the claim was repeated

  • the S13 landed/not-landed inventory, which listed the adapter as not landed
  • Research Findings 2, which quotes the doc comment as it read before the rewrite
  • the research finding whose heading promised the transfer-deadline fix
  • the gated-criteria paragraph, whose stated reason for not blocking on 269 was that S13 Step 11 carries it
  • the dependency DAG node labelled with the work item
  • Step 12's External prerequisite bullet and its scope paragraph
  • the outstanding-dependency entry for S13 Step 11

The correction itself goes in Research Findings 2, where the plan first reads S13's claim; the other sites point at it rather than repeating the paragraph.

The conclusion survives, the reason changes

S16 still does not block on 269, on different grounds: the progress-based read deadline changes how upstreamhttp.Client computes a deadline, and every S16 step reaches that client through the adapter. No step in this plan writes code the fix touches.

Two scheduling predictions came out with it

Both were arguments rather than facts, and they come out regardless of how each turned out:

  • The ordering argument said S16 would not reach Track B until fifteen Track A MRs had merged. Seven have.
  • The outstanding-dependency preamble said S13's cadence would put its steps well ahead of S16 Track B. That one has held so far — S13 Step 11's production code is all on main while S16 is still in Track A — but a forecast about another slice's cadence is not this plan's to make.

What replaces them is checkable: the adapter, the seam assertion, and the standalone remote request flow are all on main. The standalone flow is a different entry point no step here consumes, which the plan already says in Step 13's Note, and S13 Step 11's one open MR (!1292 (merged)) is still changing the adapter — it widens Doer.client to a clientDoer interface and adds an error-path response release — so the seam's shape is not settled until it merges.

Not in scope

Work item 269 itself. Its fix 1 (the progress-based read deadline) and fix 3 (cache fill survives client disconnect) are S13-owned, unassigned, and have no plan step to carry them; that needs an owner, and a spec MR and plan MR of its own. This MR corrects the S16 plan's description of the situation only.

Related to #288

Edited by Radamanthus Batnag

Merge request reports

Loading
Loading