Repository: cppa-cursor-browser
Assignee: Brad @bradjin8
Severity: Medium
Problem
The project's 15 HTTP endpoints are described informally in the README without threading caveats, and no standalone API reference or deployment guide exists. A deployer adding --threads 2 to gunicorn receives no signal from any layer — code, configuration, or documentation — that this will produce a data race on _workspace_path_override. The Flask app does not constrain its WSGI threading model, and the absence of a documented threading contract removes the last non-code mechanism that could warn about the safety constraint. Even after the race condition is fixed (item 2), deployers need guidance on supported configurations.
Acceptance Criteria
Implementation Notes
This item should be sequenced after item 2 (thread-safety fix) so the documentation reflects the actual safety guarantees. If item 2 is not yet merged, write the documentation with a "single-threaded only" constraint and a TODO to update after the race is fixed. Cover: (a) why the default flask run is single-threaded and safe, (b) what breaks under --threads (if the race is unfixed), (c) recommended production setup (gunicorn with --workers but --threads 1), and (d) the pywebview desktop mode's threading model. Keep it concise — one page, not a deployment manual.
References
- Eval finding: test 16
- Cluster:
threading-deployment-undocumented
- Related files:
README.md, utils/workspace_path.py, app.py (Flask app factory / run configuration)
- Compounds: COMPOUND-B (race condition + missing documentation), COMPOUND-E (undocumented API + race condition)
Repository: cppa-cursor-browser
Assignee: Brad @bradjin8
Severity: Medium
Problem
The project's 15 HTTP endpoints are described informally in the README without threading caveats, and no standalone API reference or deployment guide exists. A deployer adding
--threads 2to gunicorn receives no signal from any layer — code, configuration, or documentation — that this will produce a data race on_workspace_path_override. The Flask app does not constrain its WSGI threading model, and the absence of a documented threading contract removes the last non-code mechanism that could warn about the safety constraint. Even after the race condition is fixed (item 2), deployers need guidance on supported configurations.Acceptance Criteria
DEPLOYMENT.md(or a "Deployment" section in README) documents supported WSGI configurations and threading constraintsWORKSPACE_PATHenvironment variable's trust boundary is documented (already partially covered in README — consolidate)Implementation Notes
This item should be sequenced after item 2 (thread-safety fix) so the documentation reflects the actual safety guarantees. If item 2 is not yet merged, write the documentation with a "single-threaded only" constraint and a
TODOto update after the race is fixed. Cover: (a) why the defaultflask runis single-threaded and safe, (b) what breaks under--threads(if the race is unfixed), (c) recommended production setup (gunicorn with--workersbut--threads 1), and (d) the pywebview desktop mode's threading model. Keep it concise — one page, not a deployment manual.References
threading-deployment-undocumentedREADME.md,utils/workspace_path.py,app.py(Flask app factory / run configuration)