Repository navigation
migration-apply re-reads the whole scope per effect, so about 19 effects per 270 s; per-effect cost scales with scope size #5123
Description
Work level: Delivery · Track: Follow-up · Intended Status: Backlog
Owner
The #5119 owner, in the reader and apply work.
Done when
board-v2 migration-apply per-effect precondition and readback cost no longer scales with the whole scope. It reads only the affected item, or one shared refresh per bounded group, so that a selected absent-value initialization of many effects completes within one 500-request / 270-second invocation. It needs controls on effects per invocation and requests per effect.
Current deliverable
None. Filed only. On 2026-10-31, cohort90 batch 1 of #4941 (16 cards, 55 prepared absent-value effects) ended at the 270-second ceiling after 19 effects. All 19 had HTTP 200 receipts and correct readbacks, and the terminal state was the coarse "Unknown". Each effect re-reads the whole selected scope, so throughput is about 19 effects per invocation. Root re-split the remaining cards into scopes of at most 4. Related: #5120, #5121.
Next action
The #5119 owner schedules it.
Blocked on
Nothing external.
Acceptance evidence
None yet.
Activity
EHotwagner commentedon Nov 1, 2026
Root/fdev acceptance (decision 9, #4730 issuecomment-6551301543): every linked PR is merged and none is open. #5160 merged as
11f51947; its independent review APPROVED5a1adfe2and recorded on #5160. Done when is met:migration-applygroups planning initializations with item-scoped preconditions and readback,--max-effectscaps effects per invocation, requests per effect are bounded (1+1+≤7), and the synthetic 77-effect journey takes 299 requests, under the 500 cap. The live large-batch run happens with the next enrollment pass under #5136/#4941; it is not a held assertion here.