uWSGI graceful reload and lazy‑apps interaction: worker recycling order and version consistency

Goal

Determine how uWSGI's graceful reload (SIGUSR1 or touch‑reload) coordinates with --lazy-apps when workers are recycled, specifically whether a deterministic shutdown order can be enforced to avoid version skew across workers.

Constraints and uncertainty

• Graceful reload waits for active requests but does not define a worker shutdown sequence.
• --lazy-apps loads the application independently in each worker, so code changes between worker restarts can produce mixed versions.
• --chain-reload recycles workers sequentially, yet documentation does not guarantee that the new version is fully loaded before the next worker starts.
• The --reload-mercy timeout may terminate workers mid‑request if set too low.

Questions:

1. Can the master process be configured to enforce a strict worker‑by‑worker shutdown order during graceful reload?
2. What hook points (e.g., --hook-post-fork) are safe for signalling that a worker has finished loading the new code before it accepts traffic?
3. Is there a documented pattern to combine --lazy-apps with --chain-reload without exposing clients to version skew?