Skip to content

feat: configurable EMBED_TIMEOUT_MS / RERANK_TIMEOUT_MS - #29

Merged
TheGreatAxios merged 1 commit into
mainfrom
embed-timeout-env
Aug 6, 2026
Merged

feat: configurable EMBED_TIMEOUT_MS / RERANK_TIMEOUT_MS#29
TheGreatAxios merged 1 commit into
mainfrom
embed-timeout-env

Conversation

@TheGreatAxios

Copy link
Copy Markdown
Contributor

Why

Embed/rerank client timeouts are hardcoded at 10s in embed-client.ts / rerank-client.ts. In production, ollama embed calls have been observed taking 6-9 seconds -- capture requests are racing the fixed timeout with little margin. Operators need to raise this per deployment.

What

  • EMBED_TIMEOUT_MS -> EngineConfig.embed.timeoutMs -> EmbedClientConfig.timeoutMs (schema already supported this field; it was just never wired from env).
  • RERANK_TIMEOUT_MS -> EngineConfig.rerank.timeoutMs -> RerankClientConfig.timeoutMs (also already supported by RerankClientConfigSchema).

Both use the existing optionalIntEnv helper in mount-config.ts (positive-int validation, undefined when unset so each client's own 10s default still applies).

Added EngineConfig.embed.timeoutMs / EngineConfig.rerank.timeoutMs fields (were missing -- the intermediate config type would have dropped the value between loadMemoryConfig() and the client config it feeds).

Tests

New src/mount-config.test.ts covering: unset -> undefined (default preserved), and each env var set -> flows through to the resulting config field. Full suite passes (318 tests).

Add EMBED_TIMEOUT_MS and RERANK_TIMEOUT_MS so operators can raise the
fixed 10s HTTP timeout per deployment. Ollama embed calls have been
observed taking 6-9s in production, leaving little margin against the
hardcoded default.
@TheGreatAxios
TheGreatAxios merged commit 3b6ded2 into main Aug 6, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant