LEARN. PRACTICE. GROW.A request retains its already-selected target
The script sends a critical pilot POST and confirms entry into the green handler. An Event holds processing before the write. Only after that confirmation does policy change to blue. A second POST from the same cohort now goes to blue, returns 100 and writes its receipt. Meanwhile the first client remains pending and the counter retains one in-flight request. This interleaving uses explicit signals rather than an estimated network delay. The exercise demonstrates that the new selection rule does not retroactively reroute an already-executing handler. It establishes no behavior for persistent sessions, multiplexing, retries, client cancellation or lost connections because those mechanisms were not exercised.
Draining requires observing admitted work
After checking the new path, the script releases the Event and waits for the first client to finish. Its response still identifies green and contains 108. Only afterward does the script close the candidate listener and confirm a subsequent request still works through blue. This sequence separates withdrawing new selections, completing already-admitted work and retiring the component. At a real target, define wait limits and what happens when an operation exceeds available time. Waiting indefinitely is not a complete policy; terminating without assessing effects is not one either. The plan should identify supported interruption, authority, partial state, escalation and resumption criteria. The lab chose controlled normal completion and did not exercise interruption of remote operations.
The last consequence can occur after cutover
The temporary file ends with two records: blue/100 followed by green/108. The second effect was produced after routing had already recovered for new requests. Closing green leaves the file unchanged. Policy-change time therefore cannot delimit all candidate effects by itself. In a real application, relate admitted requests, acknowledgements and persisted effects before deciding reconciliation or compensation. If a connection is lost after a possible write, absence of a response does not establish absence of an effect. This additional scenario is discussed in questions but was not executed by the lab. The script implements no idempotency and authorizes no blind POST replay; retry policy depends on the contract and confirmed state.
Acceptance and communication with RUN
The proposed workshop brings together APS, supplier, service owner and RUN. In English, participants should explain what was installed, what receives new requests, what continues executing and which effects require treatment. The guide exists but has not been performed by a human group. Thirteen local groups passed twice on CPython 3.13.1 using three owned listeners and cleanup of sockets, threads and the temporary directory. http.server is not recommended for production and the teaching router does not offer enterprise-component security or capacity. Retain target exercises, specialist review and demonstrated autonomy as outstanding. In subsequent review, separate functional coverage, draining and reconciliation into owned actions with criteria establishing the intended outcome.
python3 content/labs/release-routing/run.py --output /tmp/dr-release-draining.json
# Compare routeChangeDoesNotCancelInFlight and effectAfterCutoverRemains.
# Proposed human workshop: explain remaining work and recovery in English.The new POST writes blue/100; after releasing the Event, the earlier POST writes green/108, which remains in the receipt.
Common pitfalls
Recovered routing as cancellation, listener closure as reconciliation or blind replay of a POST with ambiguous acknowledgement.
Related topics: Draining and wait limits · Handover and subsequent review
Routing change controls future selections; the plan needs separate decisions about earlier requests, effects and component retirement.
Reference: threading: Event and thread lifecycle · Release management practices 2026-09; scoped GitLab GitHub CodeDeploy and EF Core documentation