Bundled @trustgraph/client in shipped Docker image uses 10 s default timeout for graphRag — every Graph-RAG query times out before completion #140

Repo: trustgraph-ai/workbench-ui
Suggested title: Bundled @trustgraph/client in shipped Docker image uses 10 s default timeout for graphRag — every Graph-RAG query times out before completion
Suggested labels: bug, build

Summary

The Workbench UI shipped inside trustgraph/trustgraph-flow:2.3.21
(image: deploy-workbench-ui-1, asset:
/usr/lib/python3.12/site-packages/workbench/ui/assets/index-*.js)
bundles a version of @trustgraph/client that does not pass an
explicit timeout when calling graphRag(). As a result, the
makeRequest() 10 000 ms default fires for every Graph-RAG query,
the UI retries 3 times, and the user sees:

Request <id> timed out

in the browser console — even though the rag service has happily
processed and returned the answer (a typical Graph-RAG query on a
moderate corpus takes 20–40 s end to end).

The fix is already in main of @trustgraph/client but is not in
the image released as part of trustgraph-flow 2.3.21.

Reproduction

1. Run the standard trustgraph/trustgraph-flow:2.3.21 docker-compose stack.
2. Ingest a small corpus (anything that produces a few hundred entities).
3. In the Workbench UI → chat → Graph-RAG mode, ask any non-trivial question.
4. Browser DevTools console:

   SOCKET: opening socket... without auth user: <user>
   SOCKET: connecting to /api/socket
   SOCKET: socket opened
   App: Socket connected, loading flows...
   Request <id> timed out
   

5. Rag-service logs show several Handling input <uuid> entries
   clustered ~10 s apart — one per UI retry — followed by the actual
   answer being computed long after the UI gave up.

Root cause

In @trustgraph/client/src/socket/trustgraph-socket.ts
(latest, line 556):

makeRequest<RequestType, ResponseType>(
  service, request,
  timeout?: number,
  retries?: number,
  flow?: string,
) {
  if (timeout == undefined) timeout = 10000;   // ← 10 s default
  if (retries == undefined) retries = 3;
  ...
}

The latest graphRag() wrapper in the same file
(line 1335)
already overrides this:

graphRag(text, options?, collection?) {
  return this.api.makeRequest<...>(
    "graph-rag",
    {... query, user, collection, entity-limit, ...},
    60000,   // ← Longer timeout for complex graph operations
    undefined,
    this.flowId,
  ).then(r => r.response);
}

But the bundled JS in the running 2.3.21 workbench-ui image shows
the older form with no third argument:

{return this.api.makeRequest("graph-rag",{query:t,user:this.api.user,
  collection:n||"default","entity-limit":r==null?void 0:r.entityLimit,
  "triple-limit":r==null?void 0:r.tripleLimit,...})}

i.e. it falls through to makeRequest's 10 s default. So even
correct backend behaviour cannot deliver a Graph-RAG answer in
time.

This is a build-staleness issue: the workbench-ui was packaged
before the @trustgraph/client PR that added the explicit
60000 was published / pinned in package.json.

Suggested fix

1. Bump the @trustgraph/client dependency in package.json to a
   version that contains the
   60000 explicit timeout commit
   (≥ 1.7.1, based on what workbench-ui/package.json already
   declares — but the published image was built against an older
   resolution).
2. Republish the workbench-ui Docker image and update the tag
   pinned by trustgraph-flow:2.3.x.
3. Optional but recommended: also pass an explicit timeout in
   workbench-ui call sites so the UI behaviour is robust to future
   client default changes — Graph-RAG should reasonably allow
   ≥ 5 minutes given typical multi-hop traversal latency.

Workaround (current users)

Patch the bundled JS in the running container (lost on
docker compose down):

docker exec <workbench-ui-container> sh -c '
  JS=/usr/lib/python3.12/site-packages/workbench/ui/assets/index-*.js
  cp "$JS" "$JS.bak"
  sed -i "s/n==null&&(n=1e4)/n==null\&\&(n=6e5)/g; \
          s/o==null&&(o=1e4)/o==null\&\&(o=6e5)/g" "$JS"
'
# then hard-reload the browser tab (the JS asset is browser-cached)

This raises the makeRequest and makeRequestMulti defaults from
10 s to 600 s. Confirms the fix end-to-end.

Note: there is also a complementary backend bug

Even after the UI patch, requests over 120 s die at the
api-gateway because of a hardcoded dispatcher timeout. That is
a separate issue (see related, below) — fixing only the UI side
is necessary but not sufficient if you have heavy graph-rag
queries.

Related

• trustgraph-ai/trustgraph — "api-gateway --timeout flag silently
  ignored by all per-service dispatchers (manager.py:239, 396)"
  (companion issue; recommend filing both at once).
• trustgraph-ai/trustgraph #874 "Hardcoded timeout values should
  be configurable" — adjacent, but does not cover this UI path.

Environment

• trustgraph/trustgraph-flow:2.3.21
• Workbench UI asset path inside container:
  /usr/lib/python3.12/site-packages/workbench/ui/assets/index-*.js
• Browser: Chrome (any modern browser will reproduce; the timeout
  is in the bundled JS, not in the browser).