[rmcdaniel]

Default sync activity correction and actual Server controls

Draft #172 is now 7f547a221a05689f743d1bd906e60696e3b78b71, whole 80e55045077cc93d1fcf93bf9a789ae2de30eca6. The default remote callable uses the existing bounded context-preserving pool, and heartbeat_sync() schedules the original attempt's heartbeat on its owner's event loop. Async callbacks retain async execution. Cancelling an await neither releases a still-running thread's slot nor proves it stopped; incomplete shutdown reports the thread and retains registration. Cooperative process supervision is unchanged.

Tests-first d127bc3 has five failures on unchanged main and on the normally installed published 2.6.1 producer. Corrected focused controls pass, including actual workflow-task completion while two sync callbacks remain blocked, loop heartbeat progress, exact cancellation heartbeat ownership, physical slot retention and truthful shutdown. The final worker selection is 252 pass / two existing skips; the separate cooperative/remote/prepared supervision selection is 198 pass. Ruff and strict Mypy for the changed source pass.

Fresh actual HTTP controls use immutable published Server2.9.7 image 06ed2b6305a0 and normally installed Python2.6.1 clients, with original 30-second run / 60-second execution budgets:

• Published-worker cohort: one MainThread activity blocks the loop. The second callback and an independent workflow do not progress, and no worker heartbeat is sent during the held interval. Releasing the fixture's external gate later lets all three runs return exact results; that does not turn the failed progress observation into a pass.
• Source-worker cohort: two dw-remote-activity callbacks stay blocked concurrently while the independent workflow completes. Before release, six genuine activity-heartbeat receipts preserve task/attempt/owner identity and one worker-heartbeat receipt reports zero free activity slots. All three runs return the same exact signed int64 maximum/null/Unicode results. Both business workers exit 0.
• Stopped mode=ro / query_only SQL independently verifies six qualifying completed runs, four completed one-attempt activities, fourteen completed first-attempt tasks, 37 events, zero repairs/registrations/failed jobs, exact microsecond start-plus-30/60 deadlines and unchanged database/WAL hashes.

Unsuccessful observer originals stay separate: one assumed describe() was a dict, another assumed a nonexistent raw property, and a third sampled an earlier in-flight heartbeat rather than waiting for the actual zero-slot acknowledgement. They account for nine separately retained run rows and are not product failures or passing originals. Each fresh corrected cohort has its own namespace-compatible queue and instance IDs. The API needed 137/no OOM at teardown; no graceful API claim.

The first source CI's corpus gate failed because an unnecessary activity-capacity edit inside the sequential run_until dispatcher also selected its unchanged history-page context. That edit is removed: sequential admission remains unchanged, and the bounded pool still owns physical capacity. An exact old-source counterfactual fails the official corpus command; the current source passes unchanged corpus policy with 42 codec / 61 replay fixtures and all 54 policy controls. No fixture was fabricated, and no policy or threshold was weakened. Sonar's valid S9073/S5778 assertion findings have focused test-source corrections; final analyzer resolution is still pending.

Exact final normal CI/Sonar, source merge/fresh main, immutable package publication and normally installed fixed-package acceptance remain pending. No protocol floor, dependency, Server code or frozen actor change. This issue remains open until delivery.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud