#6223·opensre

[BUG] A stale account session keeps the LLM route on every surface except the shell

Author: Davidson3556Created Sep 12, 2026Updated Sep 12, 2026
Labelsbugnot plannedon-hold

Summary

A dead OpenSRE account session still owns the LLM route everywhere except the interactive shell, so opensre ask fails with a connection error even when a working local provider is configured.

Expected vs actual behavior

Expected: when the stored account session no longer validates, commands fall back to the configured LLM_PROVIDER.

Actual: account_llm_route() (config/account.py:208) returns a route whenever an account record and token exist on disk. It never asks whether that session still works, so a dead one beats a working local provider.

#6112 assumed this was already safe. Its Scope section says opensre ask, the gateway and cron "still fall back to the configured LLM_PROVIDER when no account route exists". That holds once the record is gone. It does not hold while the record sits on disk and the webapp rejects it or cannot be reached.

Steps to reproduce

  1. Configure a working provider (LLM_PROVIDER=openai plus a key, or opensre onboard local_llm).
  2. Write an account record whose app URL is unreachable:
bash
cat > /tmp/stale.json <<'JSON'
{"version": 1, "account": {"user_id": "u", "organization_id": "o", "email": "[email protected]",
 "app_url": "http://127.0.0.1:9", "signed_in_at": "2026-01-01T00:00:00Z",
 "token_expires_at": "2026-01-02T00:00:00Z", "llm_provider": "openai", "llm_model": "gpt-5.4-mini"}}
JSON
  1. Run:
bash
OPENSRE_ACCOUNT_METADATA_PATH=/tmp/stale.json OPENSRE_ACCOUNT_TOKEN=stale \
  opensre ask "what does SIGKILL do?"

The same command without those two env vars answers normally.

Can you reproduce it consistently?

Yes.

Logs and error output

$ opensre ask "..."          # stale record present
OpenAI API failed: Connection error.

$ opensre ask "..."          # no stale record
`SIGKILL` immediately terminates a process at the kernel level, ...

Additional context

opensre account status already reports this session as unavailable, or invalid on a 401. The route resolver never looks.

The gate work on #6112 adds OPENSRE_IGNORE_ACCOUNT_ROUTE, which does unblock the command:

bash
OPENSRE_IGNORE_ACCOUNT_ROUTE=1 opensre ask "..."

Only the interactive sign-in screen sets it. That PR documents the variable as a stopgap; this issue tracks the real fix.

Two ways to go:

  1. Have account_llm_route() drop a route whose last validation failed, caching the verdict so it costs no request per turn.
  2. Keep the route and fall back to the configured provider when the hosted call fails, saying so in the error.

Either way the error text needs work. "OpenAI API failed: Connection error." gives no hint that a stale account session caused it.

Environment: macOS 15, main at 27a492b1e.