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

[Harishkrishna17]

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).

[Harishkrishna17]

Quick follow-up after digging into the source rather than just the bundled JS:

The fix is already in master of this repo. package.json requires
@trustgraph/client@^1.7.1, and package-lock.json resolves it to
1.7.2. I unpacked both versions from npm:

npm pack @trustgraph/client@1.7.1
# package/dist/index.esm.js, line 1140-1153:
graphRag(text, options, collection) {
  return this.api.makeRequest("graph-rag", { ... },
    60000,                              // ← already present in 1.7.1
    undefined, this.flowId)
    .then((r) => r.response);
}

1.7.2 is identical for this path. So as long as the workbench-ui
image is rebuilt against the current package-lock.json, the bug
goes away — no source change needed.

The reason the shipped 2.3.21 workbench-ui image still exhibits
this is that its bundled index-*.js reflects an older
node_modules resolution from before the client graphRag wrapper
got the 60000 arg. In the bundled JS inside the container we have:

this.api.makeRequest("graph-rag",{query:t, user:..., "entity-limit":...})
// — 3 args, no timeout, no retries, no flowId

i.e. fewer args than the 1.7.x client emits, which means the build
was made when node_modules/@trustgraph/client was still on a 1.6.x
or earlier resolution.

Suggested resolution:

1. Rebuild the workbench-ui Docker image off current master and
   republish it under the 2.3.x tag (or whatever tag
   trustgraph-flow:2.3.x pulls).
2. Optional but worth considering: pin
   @trustgraph/client to an exact version (drop the ^) in
   package.json so future image builds can't silently regress to
   an older minor version that lacks the override. Same for
   @trustgraph/react-state (^1.7.3 → an exact pin) since it
   transitively consumes the client.

Happy to send a PR for the pin-tightening if you'd like, but I won't
since the source is already correct and the only hard fix is
on the publishing side.

(Cross-linking the gateway-side companion issue and PR for context:
trustgraph-ai/trustgraph#894 and trustgraph-ai/trustgraph#895 — even
after the UI patch, the api-gateway dispatcher hardcodes 120s and
will cut off any graph-RAG query above that, so both fixes are
needed.)

[cybermaggedon]

Migrated to https://github.com/trustgraph-ai/trustgraph-ui