⚡ Bolt: Skip database writes for terminal sessions - #73
Conversation
Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 07dd799f19
ℹ️ 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".
| // keep last-known status | ||
|
|
||
| // ⚡ Bolt: skip external API polling for terminal states since CLI doesn't need summary | ||
| if (status !== "completed" && status !== "failed") { |
There was a problem hiding this comment.
Resume polling after terminal-session follow-ups
When a stored session is completed or failed, a successful polyagent followup can reactivate the same vendor session, but followupCommand does not update the local StateStore. This condition therefore prevents every subsequent status or status --watch invocation from calling getStatus, permanently displaying the old terminal state even while the agent processes the follow-up; this is especially misleading because the follow-up command explicitly tells users to track the session with status --watch. Mark the session nonterminal after a successful follow-up or otherwise allow it to be polled again.
Useful? React with 👍 / 👎.
💡 What: Skips live external API polling for sessions in terminal states (
completedorfailed) in the CLIstatuscommand. In the web API (/api/sessions), it still fetches the external summary but skips redundant database writes (updating thelast_polledtimestamp).🎯 Why: Prevent N+1 external network calls in the CLI and unnecessary database writes on every 3-second refresh for sessions that will never change status.
📊 Impact: Significantly reduces latency, external rate limit usage, and database load for users with many completed sessions.
🔬 Measurement: Verify
/api/sessionsnetwork request time in browser dev tools when populated with completed sessions, and verify CLI responsiveness.PR created automatically by Jules for task 692459961168206778 started by @parvezk