fix: raise answeragent-mcp timeout and batch vectorstore chunk lookup#1084
Merged
Conversation
The MCP query_vector_store tool intermittently fails with 'timeout of 5000ms exceeded'. Two fixes: - AnswerAgentMCP node: pass API_TIMEOUT to the answeragent-mcp subprocess (default 30s, overridable via ANSWERAGENT_MCP_API_TIMEOUT). The subprocess does not inherit process.env, so the axios client otherwise falls back to a hardcoded 5s timeout. - queryVectorStore: replace the per-doc DocumentStoreFileChunk lookup loop (N unindexed pageContent queries) with a single batched In() query, guarded against empty results. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The MCP
query_vector_store/query_vector_store_with_filtertools (used by the Kumello agent) intermittently fail withMCP error -32603: timeout of 5000ms exceeded.Two separate root causes:
@answerai/answeragent-mcp's axios client defaults totimeout: 5000. TheAnswerAgentMCPnode spawns the MCP as a stdio subprocess, andMCP/core.tsspawns it withenv: { ...serverParams.env, PATH }— the subprocess does not inheritprocess.env, so settingAPI_TIMEOUTon the service has no effect.queryVectorStorereports onlyretriever.invoke()astimeTaken(~0.3–0.5s), but then runs oneDocumentStoreFileChunk.findOneBy({ storeId, pageContent })per result doc — N unindexed lookups on atextcolumn. The full request takes 1–4s and the tail crosses 5s under load.Changes
AnswerAgentMCP.ts— passAPI_TIMEOUTinto the subprocessenv(default30000, overridable via theANSWERAGENT_MCP_API_TIMEOUTservice env var). 30s is below the MCP SDK's 60s request timeout, so a genuinely slow call still fails cleanly.documentstore/index.ts(queryVectorStore) — replace the per-doc lookup loop with a single batchedIn()query, guarded against an emptydocsarray (In([])is undefined behavior in TypeORM). Behavior-equivalent;Inwas already imported.Verification
pnpm --filter flowise-components build✅pnpm --filter flowise build(server) ✅doc.id/doc.chunkNooutcomes unchanged, including theelsefallback branch.doc.id/doc.chunkNoare consumed only by the Flowise UI "Test Query" view — the MCP/agent path never reads them, so the loop change cannot alter agent behavior.Risk
Low and contained. Edit 1 only supplies a value to an already-supported knob and only affects the AnswerAgent MCP subprocess. Edit 2 only touches data used by an internal UI view, never the agent path.
Deploy
Requires a redeploy of the Kumello Flowise service after merge.
🤖 Generated with Claude Code