Sprint Item
#5 of 8 — Medium severity — after #4 (Tuesday PR 2 of 2)
Block Relations
|
|
| Blocked by |
#4 — reuse the shared {error, code} helper for the multi-worker failure response |
| Blocks |
— |
| Repo/day |
Independent of Monday #1–#3 and #6–#8 |
Calendar Day
Tuesday, July 21, 2026 (PR 2 of 2)
Planned Effort
3 story points (Medium) — sprint item #5
Problem
Under gunicorn --workers N, POST /api/set-workspace silently updates only the worker that served the request — _workspace_path_override is module-level process memory — yet it returns success. The other workers keep serving the old workspace, and the operator gets a false OK with no signal that the change did not take effect fleet-wide.
Goal
One PR that makes the endpoint honest under multiple workers: either propagate the change across workers, or (preferred) return a clear, machine-distinguishable failure instructing the operator to use WORKSPACE_PATH / --base-dir. Single-process behavior stays unchanged.
Scope
Part A — endpoint honesty (prefer fail-loud)
Part B — preserve single-process behavior
- In a single-process deployment,
POST /api/set-workspace behaves exactly as today.
Part C — test + docs
- A multi-worker test asserts the chosen behavior (no false success).
- Update
DEPLOYMENT.md to document the multi-worker constraint and the WORKSPACE_PATH / --base-dir guidance.
Out of scope
Acceptance Criteria
Verification
cd C:\Users\Jasen\CppAliance\cppa-cursor-browser
.\.venv\Scripts\Activate.ps1
pytest -q tests/test_workspace_path_thread_safety.py
pytest -q
- Manual: run with
gunicorn --workers 2, POST /api/set-workspace → response is a distinguishable failure (or verified propagation), never a bare success.
Sprint Item
#5 of 8 — Medium severity — after #4 (Tuesday PR 2 of 2)
Block Relations
{error, code}helper for the multi-worker failure responseCalendar Day
Tuesday, July 21, 2026 (PR 2 of 2)
Planned Effort
3 story points (Medium) — sprint item #5
Problem
Under gunicorn
--workers N,POST /api/set-workspacesilently updates only the worker that served the request —_workspace_path_overrideis module-level process memory — yet it returns success. The other workers keep serving the old workspace, and the operator gets a false OK with no signal that the change did not take effect fleet-wide.Goal
One PR that makes the endpoint honest under multiple workers: either propagate the change across workers, or (preferred) return a clear, machine-distinguishable failure instructing the operator to use
WORKSPACE_PATH/--base-dir. Single-process behavior stays unchanged.Scope
Part A — endpoint honesty (prefer fail-loud)
code, using the shared helper from item Fix app.py and scripts/export.py CLI: switch to argparse, add --port/--host/--base-dir, fix default host, validate --since #4 where available) telling the operator to setWORKSPACE_PATH/--base-dir.threading.Lockand is the larger option — default to fail-loud.Part B — preserve single-process behavior
POST /api/set-workspacebehaves exactly as today.Part C — test + docs
DEPLOYMENT.mdto document the multi-worker constraint and theWORKSPACE_PATH/--base-dirguidance.Out of scope
Acceptance Criteria
WORKSPACE_PATH/--base-dir.DEPLOYMENT.mdupdated.Verification
gunicorn --workers 2,POST /api/set-workspace→ response is a distinguishable failure (or verified propagation), never a bare success.