Repository navigation
fix(engine): provider state rebuilds when stored credentials change on disk (#1848) - #1850
Merged
Merged
Conversation
…n disk — a connect on one shard reaches every shard (#1848) The fleet engine shards share one auth.json, but each process caches its provider state per instance. A connect (Amazon Bedrock, OpenCode Go) landed on one shard, which wrote the file and disposed only its own instance, so the picker kept getting pre-connect provider lists from the other shards (and the removed openrouter stayed listed there). Every provider state read now compares a fingerprint of the on-disk credentials with the one the state was built from, and rebuilds that state alone on drift. No instance dispose, so running sessions are untouched. Regression test writes auth.json behind a live instance (connect and disconnect); it fails on the base and passes with the fix.
Contributor
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1848.
Problem
The fleet's engine shards (4094/4194/4294) share one
auth.json, but each process caches its provider state per instance. Connecting Amazon Bedrock or OpenCode Go landed on one shard, which wrote the file and disposed only its own instance. The model picker then read/providerfrom whichever pool member the frontdoor picked, and the other shards were still serving their pre-connect provider lists. On the live hub: 4094 listsamazon-bedrockandopencode-go; 4194 and 4294 don't, and still list the removedopenrouter.Fix
Provider(overlayprovider/provider.ts): the state records a fingerprint of the stored credentials it was built from. Every state read (list,getProvider,getModel,getLanguage,closest,getSmallModel,defaultModel) compares it with the on-disk fingerprint and invalidates and rebuilds only the provider state on drift. There's no instance dispose, so running sessions aren't cancelled. The provider state has no finalizers, so in-flight streams keep their existing SDK objects. If the auth file can't be read, nothing is rebuilt.Tests
stored credentials written by another process reach a live instance. It builds the state, writesauth.jsondirectly the way a sibling shard would, and asserts the provider shows up on connect and goes away on disconnect. Fails on base, passes with the fix.test/provider/provider.test.ts: 101/0.test/provider+test/server+ session llm/prompt: 1391 pass. The 4 failures are the gate's known-environmental families (bounded fan-out,provider stream errors), plus a timing flake insse-tick-telemetrythat passed 4/4 on rerun with the fix.Deploy
Engine binary change, so it rides the staged engine rebuild (same swap window as the
03f8836f/ae93d3a3provenance reconciliation). Once deployed, connects propagate to every shard on the next picker read without a restart.Follow-up (not in this PR)
The app still calls
instance.dispose()afterauth.set(server-compat.ts, settings providers). In the fleet that lands on one pool member and cancels the running sessions in that shard's instance. With this fix the dispose is redundant against new engines, so it can go once no older engines remain.