Skip to content

Prepare stable 2.5.12 original query timeout correction - #145

Merged
rmcdaniel merged 2 commits into
maintenance-2.5-patch-helpersfrom
fix/stable-query-timeout-143
Oct 13, 2026
Merged

rmcdaniel merged 2 commits into
maintenance-2.5-patch-helpersfrom
fix/stable-query-timeout-143

Conversation

@rmcdaniel

Copy link
Copy Markdown
Member

Backport #144 onto exact published 2.5.11 as a separately qualified 2.5.12 candidate. A canonical query timeout now reaches the caller with its original typed response, rather than triggering a distinct query admission through HTTP retries. Unrelated transport retries keep their existing behavior.

Normally installed exact candidate wheel passes 239 client/retry tests, including default 1.20 and explicit 1.19 discovery plus namespaced/control routes. The twelve canonical-timeout controls fail against normally installed 2.5.11. A separate immutable Server 2.6.1 HTTP control is being qualified; the original observer setup failure stopped before API admission, was retained, and its resources were immediately retired.

Full final source/stable gates, actual HTTP control and published installation are required before publication. The unchanged published 2.5.11 identity and frozen consumer/cohort tuples remain intact. Pending main Nexus producer work is excluded. Query hydration/authority remains open in #143, with the actual Server timing/status contract separately owned in Server #433. Refs #143; source #144.

@rmcdaniel

Copy link
Copy Markdown
Member Author

Complete source CI 38343855047 passes at 3256e2a79ede12b9d71f26e50a4a80dc88d4978c. The normally installed compatible stable candidate passes 239 client/retry tests; all twelve canonical-timeout Client regressions fail published 2.5.11. Ruff and mypy pass, and the corpus guard/history fixtures remain unchanged.

Four actual HTTP controls on unchanged immutable Server 2.6.1 / MySQL / Redis pass with default 1.20 and explicit minimum 1.19. Each starts its own synthetic workflow; the isolated control's query/lease limits are 3/8 seconds, independent of every original failed reference and its deadlines. Published 2.5.11 sends three slow-query POSTs and exposes the final failure after 9.66–9.82 seconds. The candidate sends one, exposes the first original query_worker_execution_timeout / 504 body after 3.19 seconds, and preserves that response exactly. Each control also executes an ordinary fast query returning 7. Real leased query identities and typed late-completion fences are retained.

The first observer setup failed before discovery/admission and its stack was immediately retired. Fresh corrected controls use a separate stack. All runtime/control containers, networks and database volumes are now retired, before the original 04:15 cutoff.

This qualifies the caller retry correction. Query hydration/lease authority remains open in #143, and Server #433 owns the actual timing/status boundary. No Source600 retrospective cause, original deadline extension, frozen retuple or new Nexus capability is inferred. Stable #145 and registry verification remain separate gates.

@rmcdaniel
rmcdaniel merged commit db0c029 into maintenance-2.5-patch-helpers Oct 13, 2026
12 checks passed
@rmcdaniel
rmcdaniel deleted the fix/stable-query-timeout-143 branch October 13, 2026 04:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants