Land the configuration surfaces for `virtual_repositories.resolution.resolve_timeout`, the key !2249 declares on S13's shared resolution block. ## Why this is its own issue The knob bounds one whole virtual resolution. S13's other resolution knobs bound one leg each and compose without a ceiling, and nothing on the server side supplies one: no read handler sets a request deadline and the tree has no `http.TimeoutHandler`. See the `resolve_timeout` paragraph in S13's `## Configuration`, added by !2249, for the bound, the derivation of the `90s` default and the two rules a consumer honors. It is S13's rather than npm's because the bound is a property of the resolution, and S30 and S32 need the same one. The S31 plan originally had Step 12 (#893) declare these surfaces; !2250 moves that out of the plan. ## Scope - `proto/artifactregistry/config/v1/config.proto`: `string resolve_timeout = 5` on `ResolutionConfig`, plus the regenerated `gen/**`. - `internal/config/virtualrepositories.go`: the `90s` default, the `durationOrDefault` arm, and the `ResolutionConfig.ResolveTimeout` field. - Zero and negative need no bespoke check. `parseDurationField` in `internal/config/server.go` already rejects a non-positive duration with `errDurationNotPositive`, and `durationOrDefault` reaches it for every non-empty value, so an explicit `"0s"` or `"-1s"` fails startup while an omitted key still defaults. - No lower bound against another knob. S13 derives the default from `probe_concurrency`, `probe_timeout` and `container_remote.token_exchange_timeout`, and says of the derivation that it moves with those three and "not with `request_total_timeout`, which now bounds a leg outside the budget". - `config.example.yaml`: the key under `virtual_repositories.resolution`. - `docs/dev/configuration-reference.md`: the row, written as as-is behavior with no reference to a spec, plan or sprint, per the configuration guardrail. ## Tests Five, all in `internal/config/virtualrepositories_resolvetimeout_test.go`: a non-default value round-tripping through `config.Load`, the omitted-key default, an unparseable value reporting the dotted path on `DurationParseError.Field`, zero and negative rejected at load, and the ordering the default is derived from. That last one reads `Resolution.ResolveTimeout` against the three defaults S13 derives it from, `Resolution.ProbeConcurrency`, `Resolution.ProbeTimeout` and `ContainerRemote.TokenExchangeTimeout`, and asserts the default clears the container worst case those three compose. It is what makes the derivation enforceable rather than prose, so it belongs with the field, and it fails when any of the three moves. ## Merge order 1. !2249, the spec amendment that declares the field, with !2250 alongside it. 1. This issue's MR. 1. Step 14 of the S31 npm virtual plan, the composition root (#895), which cannot open before this merges: it builds `virtual.Resolver` from the configured `remote.ResolutionConfig`, so it has no source for `ResolveTimeout` until the field exists. Step 14 needs #1139 as well, which gives `remote.ResolutionConfig` the field to receive the value and the mechanism that applies it. 1. Step 12 (#893) is not gated on this issue. An earlier version of item 3 said it was, on the premise that its facade takes the duration as a constructor parameter; under the S13 DRI ruling the facade holds no duration at all, so Step 12 has no configured source to wait for. ## Notes - The four surfaces and their test already exist on `dmeshcharakou/s31-npm-virtual-step-12`, pushed, at `180c85771` when this was written, and are carried by **!2255**, Step 12's draft MR. That MR bundles them together with the `internal/format/npm` work, so this issue's MR is carved out of it: the config surfaces and `internal/config/virtualrepositories_resolvetimeout_test.go` come here, and !2255 keeps its `internal/format/npm` work. - **The carve-out re-derives rather than relocates.** That branch predates !2249's final derivation and disagrees with it at four points. Its default is `40s`. Its comment derives that figure as `ceil(20/10) * 5s` plus `defaultVRRequestTotalTimeout`, with zero slack. `validateKnobBounds` adds `errVRResolveTimeoutBelowTransferBudget`, a lower bound requiring the value to exceed `request_total_timeout` plus `probe_timeout`. And two of its tests stand on that lower bound, `TestVirtualRepositories_ResolveTimeoutExceedsTheRequestBudget` and `TestLoad_VirtualRepositories_ResolveTimeoutBelowTheTransferBudget`, the second with `20s` and `37s` written into its cases. !2249 sizes the default at `90s` off the container worst case and takes `request_total_timeout` out of the budget, so all four are re-derived here rather than moved. - That branch's `docs/dev/configuration-reference.md` row is wrong on more than the number. It states that a cache fill still running at expiry is cut off and that the read leaves no partial cache entry behind. S13's acceptance criteria require the opposite: a cold fill outliving the budget runs to a clean end of body and publishes its cache row, because the budget is released at winner selection. - The deadline mechanism and its non-positive-duration guard belong to neither MR: the S13 DRI ruled the budget into `virtual.Resolver`, armed inside it and released at winner selection. #1139 tracks that work, and it carries the `remote.ResolutionConfig.ResolveTimeout` field the mechanism reads, which is separate from the `internal/config` field this issue lands. - No plan MR is needed. The plan guardrail covers features and initiatives; this is one configuration field a merged spec amendment declares. - Do not carry #266's pointer onto this field. #266 tracks the npm-virtual packument merge, and this key is format-agnostic. Related to #893