Repository navigation
Conversation
|
Ran into this with a plugin tool that publishes progress mid-execution — can confirm the diagnosis and the fix still hold against current
The fork-not-await shape matches the |
|
Not sure how to get some attention from maintainers here. |
|
Two things that might help:
On getting attention: with ~6k open PRs the review queue doesn't seem to move on its own — the project Discord is probably the realistic channel for a ping with the PR link. |
|
It seems the first important step is to get good reactions to this PR to avoid getting closed automatically. The repo has .github/workflows/close-prs.yml running daily at 22:00 UTC, calling script/github/close-prs.ts --threshold 2 --age-months 1. It closes every open PR older than one month with fewer than 2 positive reactions. Positive means 👍, ❤️, 🎉 or 🚀 counted on the PR itself; reactions on comments don't count. This PR opened on Sep 5 with no reactions, so the first run that matches it is 2026-10-05 at 22:00 UTC. #18631 (#18631) fixed the same thing and was closed by exactly that cleanup on 2026-05-15. #38365 (#38365) fixed it again in July and was auto-closed two hours later because the template checkboxes weren't ticked. This is the third attempt and the first compliant one. Will create a new issue and send a small message to discord. |
The plugin API declares ToolContext.metadata() as a plain void call, but the host context returns an Effect. fromPlugin() bridged ask() and spread the rest, so a plugin calling context.metadata() built an Effect nobody ran and the update was dropped: clients only saw metadata once the tool returned it in its final result. Bridge metadata() the same way ask() is bridged, forking it because the public signature is synchronous and the host update is not.
433b15e to
f947562
Compare
|
This branch has been upgraded to V2. We're no longer taking PRs for V1. If you think this is still relevant, please port it over and open it for V2. — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊 |
Issue for this PR
Closes #50313
Type of change
What does this PR do?
ToolContext.metadata()is a plainvoidcall in the plugin API, but the host context returns an Effect.fromPlugin()bridgesask()and spreads the rest, so a plugin callingcontext.metadata()builds an Effect that nobody runs andthe update is dropped. Metadata only shows up once the tool returns it in its final result, which is too late for anything that wants to report progress, or publish a child session id while it is still working.
This bridges
metadata()the same wayask()is bridged. It is forked rather than awaited because the public signature is synchronous while the host update is not.How did you verify your code works?
Added a regression test in
packages/opencode/test/tool/registry.test.tsthat loads a real custom tool callingcontext.metadata()mid-execution and asserts the host callback receives the update before the tool returns. It fails ondevand passes with the fix.bun test test/tool/registry.test.tsinpackages/opencode: 16 passregistry.tschange reverted: 1 fail, so the test covers the bugbun test test/tool/: 342 passbun typecheckinpackages/opencode: cleanScreenshots / recordings
Not applicable, this is a server-side plugin bridge.
Checklist