Repository navigation
fix(core): keep healthy well-known origins when one is unreachable - #46188
ryanskidmore wants to merge 1 commit into
Conversation
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
|
Automated PR Cleanup Thank you for contributing to opencode. Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions. This PR was closed because it matched the following cleanup criteria:
PRs created within the last month are not affected by this cleanup. If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate. Thanks again for taking the time to contribute. |
Issue for this PR
Closes #46187
Type of change
What does this PR do?
WellKnown.load()resolved origins with a fail-fastEffect.forEach, so one unreachable origin failed the whole batch. The wellknown plugin called it throughEffect.orDie, so that failure killed the plugin before it registered its transform — and every well-known integration disappeared, not just the dead one.Config.loadWellknowncatches the same failure and returns[], so the remote config for the healthy origins went with it.Each origin is now resolved independently. If one fails we keep its last known manifest, or skip it when nothing is cached.
refresh()goes through the same path, so a temporary outage falls back to the cache and correctly reports "no change" instead of failing.I also swapped the plugin's
orDiefor a logged catch. Worth noting it has to catch and continue — simply deletingorDieisn't enough, becauseyield*would still short-circuit beforectx.integration.transform(...)and the symptom would be unchanged.The confusing part of the original bug is that
auth login <url>prints "Authentication provider discovered" and then "Integration not found" for the same URL. Those come from different paths:wellknown.addonly fetches the one origin you passed, so it genuinely succeeds, and the lookup afterwards reads a registry the dead plugin never populated.It also only appears after a restart, since
load()reuses the in-memory cache — which makes it look like whichever version you just installed broke it.How did you verify your code works?
Two tests in
packages/core/test/wellknown.test.ts, both of which fail onv2and pass with this change (I checked by stashing thesrc/changes and re-running):entries()returns only the live originrefresh()returnsfalseand keeps the manifestFrom
packages/core:bun run test test/wellknown.test.ts(5 pass) andbun run test test/config/config.test.ts(35 pass), plusbun typecheck.I also reproduced the original failure end-to-end with the installed
0.0.0-beta-18684client againstpackages/core/script/wellknown-server.ts: adding an unresolvable origin towellknown:sourcesmakesauth loginfail for a healthy origin, and removing it fixes it.Not in this PR, but related:
WellKnown.remove()exists and nothing reaches it — no route and no CLI — sowellknown:sourcesonly ever grows and the only way out of this state today is editing SQLite by hand. Happy to follow up if you want that exposed.Screenshots / recordings
Not a UI change.
Checklist