Repository navigation
Accept published PHP health read during or after its own task repair - #676
Conversation
The operator metrics probe reads metrics, then health, in separate requests. Past the redispatch window, published PHP's TaskWatchdog repairs the overdue task and projects the run before TaskDispatcher redispatches it and projects the run again. A health read in between sees the run needing repair (durable_resume_paths); one after it sees the task redispatched. Both are later points of the same PHP repair, not differences from the metrics read before them. For PHP at that stage only, health may now be at the metrics' state or a later point of the repair. Native runs no repair loop and stays held to exactly the state its metrics show. Main's postgres-17 fixtures failed this way on the published PHP reference (run 39815830012).
This PR's own postgres-17 run caught published PHP's metrics inside the repair window: the task repaired once and still overdue, and the run projected as needing repair (runs.repair_needed and backlog.repair_needed_runs 1). The contract now models PHP's three states past the redispatch window in order, overdue, repairing and redispatched, each with its counts and warnings. With a repair count, PHP's metrics may show repairing or redispatched; health may show the metrics' state or a later one. Native still has only the state its metrics show, and a run needing repair without a repaired task fails.
|
Pushed |
|
Fixes a flaky
operator-metricsdifference in Shared Server fixtures. It comes from the published PHP reference, not native. Main's latest postgres-17 run (39815830012) failed this way, and so did train #675's (120010743834). In both, no PHP pass line precedes the difference.Why PHP differs from itself. The probe reads
system/operator-metrics, thensystem/health, in two requests. Past the redispatch window, PHP'sTaskWatchdog::recoverExistingTaskrepairs the overdue task and projects the run in one transaction. Only after that commit doesTaskDispatcher::dispatchsetlast_dispatched_atand project the run again. A health read in between sees the task still overdue and the run projectedrepair_needed, sodurable_resume_pathswarns. A read after the redispatch seestask_transportandrouting_healthclear. The contract already accepted metrics taken after the repair (REPAIRED), but assumed health matched the metrics' state.Change. For
runtime: phpatwaiting_after_redispatchonly, health may be at the metrics' state or at a later point of that repair. The order is overdue, then repairing, then redispatched. Health behind its metrics is still rejected. Native runs no repair loop and is held to exactly the state its metrics show.Tests (
ServerParityOperatorMetricsContractTest.mjs, 40/40): PHP health mid-repair passes, and PHP health after the redispatch passes. Each of these is rejected: native showing either state, PHP health behind metrics that show the redispatch, and the repair warning at another stage. Against main's contract, exactly the two new PHP cases fail.