anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[PR #5040] fix: ensure checkUpgrade sets init: #11218

New Issue
Closed
opened 2026-02-16 18:16:01 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 18:16:01 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/anomalyco/opencode/pull/5040

State: closed
Merged: Yes

Problem

In TUI mode, a race condition occurs in environments where initialization involves significant latency (e.g., SSH, WSL2, remote VSCode).

The checkUpgrade function is scheduled to execute after 1 second. If the TUI initialization phase takes longer than 1 second, checkUpgrade executes first. Previously, checkUpgrade called Instance.provide() without passing the init (InstanceBootstrap) object.

Found this and fixed this using my personal plugin oh-my-opencode, but i thought there is no ai slop for this and found the real cause and fixed so I made this PR.

Root Cause

The Instance.provide() method follows a singleton pattern with caching.

  1. checkUpgrade executes and calls Instance.provide() (without init).
  2. An Instance is created using default settings without executing configuration or event hooks, and this uninitialized instance is cached.
  3. When the main TUI logic eventually calls Instance.provide(init), the system detects the cached instance.
  4. It returns the existing (poisoned) instance, effectively ignoring the provided init object.

Impact:

  • Config hooks are skipped -> Custom agents defined on plugin are not registered.
  • Event hooks are skipped -> Plugins do not receive events.

Solution

Updated checkUpgrade in packages/opencode/src/cli/cmd/tui/worker.ts to accept and pass the init: InstanceBootstrap object.

Now, regardless of whether checkUpgrade or the main TUI loop wins the race to create the Instance, the singleton is guaranteed to be initialized with the correct configuration and hooks.

Reproduction

  1. Run OpenCode TUI in a constrained environment (or inject artificial delay in TUI startup > 1s).
  2. Observe that checkUpgrade runs.
  3. Verify that custom agents defined in config are missing or event handlers are not triggering.

Related

Closes #4846

**Original Pull Request:** https://github.com/anomalyco/opencode/pull/5040 **State:** closed **Merged:** Yes --- ## Problem In TUI mode, a race condition occurs in environments where initialization involves significant latency (e.g., SSH, WSL2, remote VSCode). The `checkUpgrade` function is scheduled to execute after 1 second. If the TUI initialization phase takes longer than 1 second, `checkUpgrade` executes first. Previously, `checkUpgrade` called `Instance.provide()` without passing the `init` (InstanceBootstrap) object. Found this and fixed this using my personal plugin [oh-my-opencode](https://github.com/code-yeongyu/oh-my-opencode), but i thought there is no ai slop for this and found the real cause and fixed so I made this PR. ## Root Cause The `Instance.provide()` method follows a singleton pattern with caching. 1. `checkUpgrade` executes and calls `Instance.provide()` (without `init`). 2. An `Instance` is created using default settings *without* executing configuration or event hooks, and this uninitialized instance is **cached**. 3. When the main TUI logic eventually calls `Instance.provide(init)`, the system detects the cached instance. 4. It returns the existing (poisoned) instance, effectively ignoring the provided `init` object. **Impact:** - Config hooks are skipped -> Custom agents defined on plugin are not registered. - Event hooks are skipped -> Plugins do not receive events. ## Solution Updated `checkUpgrade` in `packages/opencode/src/cli/cmd/tui/worker.ts` to accept and pass the `init: InstanceBootstrap` object. Now, regardless of whether `checkUpgrade` or the main TUI loop wins the race to create the `Instance`, the singleton is guaranteed to be initialized with the correct configuration and hooks. ## Reproduction 1. Run OpenCode TUI in a constrained environment (or inject artificial delay in TUI startup > 1s). 2. Observe that `checkUpgrade` runs. 3. Verify that custom agents defined in `config` are missing or event handlers are not triggering. ## Related Closes #4846
yindo added the pull-request label 2026-02-16 18:16:01 -05:00
yindo closed this issue 2026-02-16 18:16:01 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#11218
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?