Description
LaunchDarkly drift safety-net sync. The toolSearchRerankerPromptV2 flag is currently on in prod (LD version=3, served true) but the in-code default in launchDarkly.ts was false. If LD becomes unreachable — or in a self-hosted deployment without LD — isToolSearchRerankerPromptV2Enabled() would silently fall back to the v1 reranker prompt, causing a regression relative to prod behavior.
The handler was introduced on 2026-05-05 via #9805 and has been untouched ever since. Today is 2026-05-19, so the prod-vs-code divergence has existed for ≥14 days — meeting the cron's "stable, take the fix" threshold.
Change is a one-liner: third-arg default false → true plus a doc comment refresh. No callers assert on the default and the only consumer (llm_reranker.ts) wraps the call in a try/catch that already logs LD failures, so behavior on LD outage simply matches prod instead of regressing to v1.
How did I test this PR
- Confirmed prod LD edge config:
on=true, fallthrough.variation=0, variations[0]=true, version=3, no rules/targets.
- Verified the only runtime caller (
apps/apollo/src/lib/composio_actions/utils/toolRouter/llm_reranker.ts:824) just awaits the boolean and falls through to its existing log-and-skip path on error — no other code paths to update.
- Blast-radius grep across
apps/apollo/{src,tests} — no test asserts on the default value.
cd apps/apollo && doppler run -- pnpm with-env vitest run src/lib/composio_actions/utils/toolRouter/llm_reranker.test.ts → 34/34 passed.pnpm check-types → no errors.pnpm lint -- src/common/lib/external/launchDarkly.ts → 0 warnings, 0 errors.
cc @abir-taheer @lingalarahul7 @dhawal1
Origin: cron-03fc887bd1a1 / zen-cron-97caebf85577
Triggered by: abir@composio.dev | Source: Cron: Prevent LaunchDarklyDefault Drift
Session: https://zen-api-production-4c98.up.railway.app/dashboard/#/chat/zen-cron-97caebf85577
@zen-agent
