microsoft / microsoft/work-iq

ask_work_iq fails with persistent error after ~30 consecutive calls in a single VS Code Copilot session (possible throttling / service degradation)

Open
#40 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
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
  1. Open VS Code with GitHub Copilot Chat in Agent mode.
  2. Use ask_work_iq tool 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?"
  3. First ~30 queries complete successfully with detailed results.
  4. Starting from approximately the 31st–34th call, all subsequent calls fail with:
    An error occurred invoking 'ask_work_iq'.
    
  5. Retrying the same previously-successful query still fails.
  6. 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-After header info).
    • Automatically recover after the cooldown period.
  • 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
  1. Surface meaningful error details — Include error codes, HTTP status, and/or a Retry-After value in the error response so callers can handle it programmatically.
  2. Document rate limits — If there is a per-session or per-minute call limit, document it clearly so users can plan around it.
  3. Graceful degradation — If throttled, return a specific throttling error and allow automatic recovery after the cooldown window instead of permanently failing.
  4. Improve logging — Provide a way to access MCP server logs for diagnosis (e.g., workiq logs command 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.