ask_work_iq fails with persistent error after ~30 consecutive calls in a single VS Code Copilot session (possible throttling / service degradation)
Nobody has claimed this yet.
- Dominant language
- PowerShell
- Stars
- 1k
- Forks
- 132
- Avg merge
- 5d 19h
- Merged PRs (30d)
- 6
Description
Description
When using ask_work_iq via GitHub Copilot Chat (Agent mode) in VS Code to perform a batch of email queries (~50 queries in one session), the tool starts returning a generic error after approximately 30 successful calls. Once the error begins, every subsequent call fails — the service never recovers within the same session, even after waiting several minutes between retries.
Error message:
An error occurred invoking 'ask_work_iq'.
No additional error details, stack trace, or error code are provided, making it impossible to diagnose whether this is a rate limit, a token expiration, or a backend service issue.
Environment
- OS: Windows 11 (x64)
- VS Code: Latest stable (Feb 2026)
- Copilot: GitHub Copilot Chat, Agent mode
- WorkIQ: Installed via VS Code MCP integration (built-in)
- Tenant: Microsoft corporate
Steps to Reproduce
- Open VS Code with GitHub Copilot Chat in Agent mode.
- Use
ask_work_iqtool to query Outlook emails repeatedly in a single conversation session.- Example query: "Summarize the email thread about [topic] from my mailbox. What is the issue about? Who are the participants?"
- First ~30 queries complete successfully with detailed results.
- Starting from approximately the 31st–34th call, all subsequent calls fail with:
An error occurred invoking 'ask_work_iq'. - Retrying the same previously-successful query still fails.
- Waiting 5–10 minutes and retrying within the same session still fails.
Expected Behavior
- All queries should succeed, or if there is a rate limit:
- Return a specific error code/message indicating throttling (e.g., HTTP 429 with
Retry-Afterheader info). - Automatically recover after the cooldown period.
- Return a specific error code/message indicating throttling (e.g., HTTP 429 with
- The generic error message should include actionable details (error code, reason, retry guidance).
Actual Behavior
- After ~30 successful calls, all subsequent calls fail with a generic
"An error occurred invoking 'ask_work_iq'."message. - No error code, no retry guidance, no distinction between throttling vs. service failure vs. auth expiration.
- The service does not recover within the session regardless of wait time.
Impact
This makes WorkIQ unusable for any batch/automated workflow where multiple queries are needed in a single session — e.g., summarizing a series of email threads, reviewing meeting notes across multiple projects, or any scenario requiring repeated ask_work_iq calls.
In my case, ~17 out of 50 planned queries could not be completed because WorkIQ became permanently unresponsive mid-session.
Suggestions
- Surface meaningful error details — Include error codes, HTTP status, and/or a
Retry-Aftervalue in the error response so callers can handle it programmatically. - Document rate limits — If there is a per-session or per-minute call limit, document it clearly so users can plan around it.
- Graceful degradation — If throttled, return a specific throttling error and allow automatic recovery after the cooldown window instead of permanently failing.
- Improve logging — Provide a way to access MCP server logs for diagnosis (e.g.,
workiq logscommand or a log file path).
I'd be happy to provide additional logs or diagnostics if there's a way to capture them.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the failure with repeated ask_work_iq calls through the VS Code Copilot Chat Agent mode MCP integration, then collect any available MCP server diagnostics. Done means the failure distinguishes throttling, authentication, and service errors with actionable retry guidance, and the behavior or cooldown is documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github, vscode
- Domain
- backend, devtools
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100