feat(mobile): lock chat input while bot is responding + 20s timeout#1537
feat(mobile): lock chat input while bot is responding + 20s timeout#1537felixmuinde wants to merge 56 commits into
Conversation
Signed-off-by: Juan José Mata <juanjo.mata@gmail.com>
Signed-off-by: Juan José Mata <juanjo.mata@gmail.com>
Signed-off-by: Juan José Mata <juanjo.mata@gmail.com>
Updated regex for Docker image tag matching in deployment script. Signed-off-by: Juan José Mata <juanjo.mata@gmail.com>
Signed-off-by: Juan José Mata <juanjo.mata@gmail.com>
Signed-off-by: Juan José Mata <juanjo.mata@gmail.com>
Refactor deployment logic to handle alpha and beta tags more clearly, removing unnecessary beta deployment conditions. Signed-off-by: Juan José Mata <juanjo.mata@gmail.com>
Signed-off-by: Juan José Mata <juanjo.mata@gmail.com>
- Add _isWaitingForResponse flag to ChatProvider; set in _startPolling, cleared in _stopPolling so it covers the full polling lifecycle not just the initial HTTP POST - Add _pollingStartTime + 20s timeout in _pollForUpdates; if the bot never responds the flag resets, errorMessage is surfaced, and input unlocks automatically - Gate send button and keyboard shortcut on isSendingMessage || isWaitingForResponse so users cannot queue up multiple messages while a response is in flight (adding an interrupt like with other chat bots would require a larger rewrite of the backend structure) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (7)
📝 WalkthroughWalkthroughThe pull request introduces CI/CD infrastructure with CodeQL security analysis and automated Docker image deployment to AWS ECR, adds a polling timeout mechanism to the mobile chat provider, updates message send gating logic to account for response waiting states, and establishes Terraform infrastructure for AWS ECR repository provisioning with OIDC-based authentication. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~35 minutes Suggested labels
Poem
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a7b0fbdbdc
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| onPressed: (chatProvider.isSendingMessage || chatProvider.isWaitingForResponse) | ||
| ? null | ||
| : _sendMessage, |
There was a problem hiding this comment.
Keep input lock tied to polling completion
This enable/disable gate now depends on isWaitingForResponse, but that flag is still cleared in ChatProvider._pollForUpdates as soon as the first assistant token arrives, before _stopPolling() ends the response lifecycle. In streaming replies, the send controls re-enable while the previous assistant response is still in flight, so users can submit overlapping prompts again despite the intended single in-flight lock.
Useful? React with 👍 / 👎.
| if (_pollingStartTime != null && | ||
| DateTime.now().difference(_pollingStartTime!) >= _pollingTimeout) { | ||
| _stopPolling(); |
There was a problem hiding this comment.
Timeout only stalled polls, not active responses
This timeout condition uses elapsed time since polling started and aborts after 20s even when the assistant is actively producing content. Any legitimate long response (or one that completes close to the 20s mark) can be truncated and surfaced as an error because polling is stopped before fetching the next update, and the timer is never extended when progress is observed.
Useful? React with 👍 / 👎.
Summary
isSendingMessage || isWaitingForResponse), not just during the initial HTTP POST. Prevents users from queuing up multiple messages while a response is in flight._isWaitingForResponseflag: tracks the full polling cycle from_startPollingto_stopPolling, exposed as a getter so the UI can react to it.Test plan
🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Bug Fixes
Chores