Repository navigation
fix: harden runtime concurrency and production guardrails - #106
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
|
Codex Review Summary: ✅ CompletedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8e5221fbd5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| lock = self._lock_for_run(run_id) | ||
| with lock: | ||
| run = self._approve_locked(run_id, task_id, approved) |
There was a problem hiding this comment.
Offload approval locking from the API event loop
When an approval request arrives while the same run is executing (for example, a retried approval POST after execution resumes), this synchronous lock acquisition blocks until the entire execution finishes. api/main.py calls runtime.approve() directly inside the async decide_approval handler, while the background execution holds this lock across tool calls and retries. Consequently, one stale approval request can freeze unrelated requests, including health checks, on that API worker for the remaining execution time instead of promptly returning a conflict. Run the blocking approval operation in a thread pool, or make the route synchronous so FastAPI offloads it.
Useful? React with 👍 / 👎.
Summary
409 ConflictValidation
Security follow-up
The audit currently reports 62 pre-existing dependency vulnerabilities across six packages. This PR preserves the report artifact but does not turn it into a required gate, because doing so would permanently fail the default branch until coordinated dependency upgrades are validated. Those upgrades should be a dedicated remediation PR.
Scope
The runtime lock is intentionally process-local. SQLite remains documented as single-node checkpoint durability; distributed workers still require shared coordination and a shared store.