Prepare compatible Python 2.5.14 query authority patch

[rmcdaniel]

Compatible query-authority patch

Backports source #151 onto normally published 2.5.13 / 97119f3, then prepares version 2.5.14. Pending Nexus cooperation and the held major train on main are excluded.

The worker preserves the original query delivery budget through external loading, replay, handler dispatch and result submission. Advertised protocol 1.20 uses non-renewing status; explicit 1.19 and older runtimes retain only their exposed local lease checks. The optional strict mode refuses unsupported registration. The caller's first failure and public terminal receipt reconciliation stay intact.

The exact source candidate passed all ordinary Python 3.10–3.12, integration, lint, package, regression-corpus, documentation and boundary gates in run 38656883494. Its failed local broad run and unchanged-main reproduction remain recorded in #151. This stable head requires its own checks.

Draft: actual slow-loading controls against the newly qualified/published PHP query-authority runtime, stable artifact qualification, publication and normal installed consumers remain pending. Server #459 is still a release candidate; no published authority tuple is inferred.

No package publication, native query capability, Cloud/frozen tuple promotion or historical Source-cause claim. #143 remains open.

[rmcdaniel]

Compatible candidate HTTP controls

Private built wheel from stable candidate 21e1f268ccc38d71551e12f9d6946be41604c10f (2.5.13 base plus query-authority backport and 2.5.14 metadata) passes actual ordinary Worker.run() query controls on unchanged published Server 2.6.3, SQLite/file cache:

• Default protocol 1.20 and explicit minimum 1.19 each register normally, reach a waiting workflow, return exact signed-int64/null/Unicode query output, stop and deregister without an error, then terminate their original workflow.
• require_query_task_authority=True refuses the older Server before any registration POST, in both protocols. These are compatibility controls, not live query-authority qualification.
• The initial observer asserted against the whole control-plane response instead of its documented result field. It remains unsuccessful; separate corrected originals passed.

Final review fixes pass 85 stable tests, Ruff and mypy; the source equivalent passes 86 tests. Both new tests independently fail the previous source: boolean attempt mutation invokes the handler, and transport discovery outlives the original delivery budget. No retry budget or historical fixture changed.

Exact stable hosted CI is separately dispatched against the declared PHP source candidate. Source #151 remains separate. Actual new-runtime slow-loading/handler authority, publication, registry installation and published consumers are still pending. No PyPI, native, Cloud or frozen tuple adoption claim.

[rmcdaniel]

The candidate 2.5.14 wheel is now qualified against normally pulled published Server 2.8.0, immutable image index sha256:cba7c4c6732529293ef6c2625a64785dcb21b4f7fe0013fdc74f1af466f534ac (source dd720e6b51844707be2885f8873c23de98c847a7). The loaded Workflow package is 2.5.20 / 2f810bed66413b1dabf8a1ff01118d6be09b7218.

Three fresh authenticated HTTP cases use normal Worker.run, original four-second query budgets and 64 KiB externally referenced input with a one-byte persistent-cache capacity:

• Timely query returns the exact signed-int64/null/Unicode value; one query claim, one payload GET and one completion.
• Expiry during an actual payload response cancels loading; no handler entry or completion submission. The original caller receives its first canonical 504.
• Expiry during an async query handler cancels that handler; no return or completion submission. The original caller receives its first canonical 504.

Each case preserves a single original query ID and unchanged workflow history. Status observations are non-renewing. Delay is injected after actual HTTP response headers without changing returned bytes, claims or responses. All three cases pass. The first setup observer used a nonexistent available key; it failed before workflow admission and was corrected to the published status=available field.

The test is being added to the source/stable candidates. This is private-wheel qualification, not a PyPI release or normally installed public 2.5.14 claim. Earlier published Server 2.6.3 default-1.20 / explicit-1.19 compatibility and strict pre-registration refusal remain separate. No larger Source/Cloud cohort, synchronous-handler interruption, native authority capability or frozen tuple promotion is claimed. Final source/stable gates, publication and registry-installed verification remain required.

[rmcdaniel]

The final compatible candidate is 1bcf50b48c17ee75e676abe7f6f86cf331425c96; the source counterpart is 36e5a656bd55766a84713ddf2a4e7b9b048a97d1. The committed HTTP test was repeated from a fresh private wheel of that stable head (f45e68dc8e1eb4ebeb8e7b868ab658c01e999081eac97dfa40f5c41d11bc3bfb): all three original authority cases pass, including exact hydrated input verification.

Server 2.8.0 and Helm 0.1.168 publication run 38660892747 is successful. The Server app stopped with explicit SIGTERM, exit 0 / no OOM / no restart. Final read-only state had zero registrations, only the default namespace and no remaining runs after normal case cleanup. The initial readback used the wrong registration table name and was corrected; it is not a product finding. All phase containers, SQLite volume, network, wheel/dependencies/copied source/raw data and the task-pulled Server image have been removed.

Final source and stable ordinary CI remain pending on these new heads; stable CI 38662841466 pins the qualified exact Server source. No public 2.5.14 package/tag/install claim yet. Existing frozen Cloud cohorts remain unchanged.

[rmcdaniel]

Maintainer review of exact 1bcf50b48c17ee75e676abe7f6f86cf331425c96 / tree f4e9a7e5bd781cfa450a0788ce57b5401d7acea9 is complete. Compatible scope is limited to the original query loading/execution budget, non-renewing observation, same-response reference reuse, focused tests/docs and 2.5.14 metadata; pending main/Nexus behavior is excluded.

Final stable CI 38662841466 passes all ten jobs, including Python 3.10–3.12, lint, package, corpus, real integration on exact Server dd720e6b and target-branch qualification. The three separate normally pulled Server 2.8.0 authority cases and old Server 2.6.3 default-1.20 / explicit-1.19 compatibility are recorded above. The two review counterfactuals cover bounded transport discovery and boolean attempt aliasing. Async expiry, unavailable/mutated observations and original typed timeout handling are covered; the synchronous-handler interruption limit is documented.

Proceeding with the ordinary compatible merge and immutable patch publication. Registry-installed verification, supported protocol checks, source/docs alignment and downstream consumers remain required before #143 delivery.

[rmcdaniel]

Version correction: the final registry/tag check found the already published documentation-only 2.5.14 (67be8f0f05301667521e9ca4c59e3223163e7272, published October 14). It remains immutable and unchanged. The query candidate was never tagged or published to PyPI.

The query implementation merged through #152 is being prepared as 2.5.15. The follow-up also restores the published 2.5.14 backfill docstring/reference page/changelog, preserving its start-inclusive, end-exclusive contract. Existing query executable logic remains unchanged; only the restored Client docstring changes that source file, plus version/docs metadata.

Candidate f493e6f2b4f1600751b3b59839ab0819b0661faa / tree 4733ccc04ddc9e0720c9c15ef9962216a765c2e0 has both the query merge and published 2.5.14 as parents. It requires its own exact gates and normal registry-installed acceptance. The earlier private 2.5.14 wheel controls remain implementation evidence, not a public version identity or release claim.