You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Session error path drops cause and stack from ProviderInitError, hiding root cause #24430
When Provider.resolveSDK throws InitError({providerID}, {cause: e}) (packages/opencode/src/provider/provider.ts:1522), the session pipeline catches it and re-emits via new NamedError.Unknown({message: err.message}).toObject(). err.cause and stack are discarded.
This makes CI failures undebuggable. The real failure (NPM install error, missing peer dep, network failure, etc.) lives on err.cause and is silently dropped.
Expected: preserve the original named error (name: "ProviderInitError") and pass cause chain through to the consumer, e.g.
Observe CI log shows only UnknownError: ProviderInitError — the underlying InstallFailedError and its cause are gone.
Operating System
Linux (GitHub Actions ubuntu-latest), macOS 25.4
Impact
Every cf-ai-gateway repo that hit the 1.14.x install regression saw an unactionable error. Multiple Cloudflare repos (workers-sdk, workerd, kumo, containers, vinext) pinned older opencode versions without an upstream issue because the symptom was not diagnosable.
If these are intentionally filed as separate issues to address different layers of the same problem, that is fine — just flagging for maintainer awareness.
Activity
github-actions commentedon Apr 26, 2026
This issue might be a duplicate of or closely related to existing issues. Please check:
loadOptions(dir)inNpm.addreify path fails on CI runners → silent ProviderInitError for dynamic providers #24431: Reports the sameProviderInitErroron CI runners from the sameloadOptions(dir)/ reify path — this is the upstream cause that Session error path dropscauseand stack fromProviderInitError, hiding root cause #24430's error-swallowing makes undebuggableprovider/error.tsIf these are intentionally filed as separate issues to address different layers of the same problem, that is fine — just flagging for maintainer awareness.
github-actions commentedon Jul 3, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.