Shared Redis/Postgres across Fleet, Insights, and Polly causes cross-component job misrouting

Last updated: September 18, 2026

Symptom

A standalone LS agent-feature component (Fleet, Insights, or Polly) in a self-hosted LangSmith deployment fails most or all of its background jobs immediately.

The error surfaced in the UI is often a generic aggregate error (for example InsightsReportError), but the worker logs for the failed job show something like:

404: Graph 'agent' not found

The component's own pod is otherwise healthy. Connectivity checks unrelated to the job queue (LLM auth proxy, JWKS/TLS endpoints, model provider access) all look fine, which makes the failure look unrelated to the component's setup.

Cause

Fleet, Insights, and Polly are separate standalone components, each with its own worker pool and its own graph loaded in memory. If two or more of these components are pointed at the same Redis database and the same Postgres schema, they end up sharing one job queue.

When the queue is shared, a worker belonging to one component can dequeue a job that actually belongs to a different component. That worker doesn't have the requesting component's graph loaded, so the job fails right away. For example, a Fleet worker picking up an Insights job fails with 404: Graph 'agent' not found because Fleet doesn't have the "agent" graph Insights expects.

Because the misroute happens at the queue level, it has nothing to do with the component's own auth, TLS, or connectivity setup, so troubleshooting those areas won't turn up anything.

Resolution

Give each component its own dedicated queue backing so jobs can't cross over:

  • Redis: components can share the same Redis server, but each must use its own separate logical database. Set a distinct database index at the end of each component's Redis connection string (for example ending in /0, /1, /2 for Fleet, Insights, and Polly respectively).

  • Postgres: components can share the same Postgres instance, but each must use its own dedicated schema. Each component's schema is set independently via its own Helm value and defaults to public, so if you haven't overridden it for every component, they're all landing in the same schema.

After updating the values, verify what each component's pods are actually using, don't assume the Helm values file is what's applied. For each of the Fleet, Insights, and Polly deployments, check the running environment:

kubectl set env deploy/<component> --list | grep -E "REDIS_URI|POSTGRES_URI"

Confirm each component resolves to a distinct Redis database index and a distinct Postgres schema.

If a connection string change in Helm values doesn't seem to take effect, check whether existingSecretName is set for that component's Redis or Postgres configuration. When it's set, the chart skips rendering and updating that component's connection-string secret entirely, so changing connectionUrl in Helm values has no effect. The pod keeps using whatever connection string is already stored in the pre-existing secret. In that case, update the secret directly rather than the Helm value.

References