Troubleshooting
I Fixed It, But I Still See the Old Error
A deterministic loop-break flow for stale-session errors after config or key changes.
Common support pattern: you update the key, fix the setting, or reconnect the tool — but the exact same error keeps showing up. Most of the time, the fix is real, but your active runtime/session is stale.
Reality check: “still seeing old error” usually means old state is still active somewhere (session, thread, browser, model fallback, or wrong account/workspace), not that your new fix failed.
What causes this loop
- Stale runtime state: config changed but active process didn’t reload.
- Wrong surface/thread: you fixed dashboard settings, then tested in a different context.
- Wrong account/workspace: change made in one account, error comes from another.
- Fallback masking: primary setting changed, but a fallback path is throwing the same-looking error.
5-minute recovery flow
1) Capture the exact current error text
Do not paraphrase. Copy the full latest error exactly once so you can compare old vs new behavior.
2) Prove where the fix was applied
Confirm account, workspace, and setting path. If you can’t prove the exact location, treat the fix as unverified.
3) Start one fresh context only
Open a fresh session/thread and run one tiny canary task. Avoid bringing full old chat context.
4) Compare error fingerprints
If the error text changed, progress is real. If it is byte-for-byte identical, likely stale runtime or wrong context.
5) One controlled restart + retest
Do one restart/reconnect cycle, then run the same canary once. No rapid retries.
Copy/paste loop-break prompt
I already changed config/keys, but I still see an old error.
Do this exactly:
1) Ask me for the exact latest error text (verbatim).
2) Ask me to confirm account/workspace/surface where I applied the fix.
3) Give me ONE tiny canary test in a fresh session.
4) Compare old vs new error fingerprints.
5) If still identical, give one controlled restart/reconnect step and one retest.
Rules:
- No broad retries
- No big prompts
- No multi-step reconnect loops
- Return clear conclusion: stale state / wrong context / unresolved fix
Escalate with this packet
Support packet:
- Exact old error text
- Exact new error text
- What you changed (setting/key/tool), where, and when
- Test surface/context (dashboard, DM, server channel, thread)
- Account/workspace used during fix vs during test
- One canary test result after fresh session
- Whether a single restart/reconnect changed behavior
Bottom line: when the same error keeps appearing after a fix, stop broad retries and run a proof-first stale-state check. One clean canary beats ten random retries.