fix: propagate InstanceRef into ScopedCache lookup in InstanceState.get() - #25694

Thanks for updating your PR! It now meets our contributing guidelines. 👍

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

Thanks for updating your PR! It now meets our contributing guidelines. 👍

Is this already addressed by https://github.com/anomalyco/opencode/pull/28016/changes?

works for me in 1.15.4

@twhittock can you provide more info about what you mean by "allowing project-level skills to be resolved correctly in REST API sessions?

I've been unable to reproduce this. something is likely wrong so we should fix, it helps a lot to have more clear repro steps. This PR also doesn't add any tests (just changes some whitespace in a test file)

Yes I start a new session with the POST REST endpoint from an automation, the initial prompt says to use a project-level skill. When the LLM runs, it fails to detect the skill (it'll say things like "skill XYZ not found") and then if the LLM attempts to list skills, it also doesn't appear there.

I rebased onto dev to get the PR mergable when getting the PR ready, and messed up the test - I'll reimplement it, sorry for that.

I'm having trouble reproducing, I'm running a lot of different scenarios, and the skills all load for me. Is there something unique to your folder structure/project?

It's nice to understand the problem from a feature-level because it helps make sure the fix is the right one, we've been iterating on our Effect patterns and sometimes refactoring things differently once we understand it better

For your information, the steps I am using:

I have 9 skills in <projectdir>/.opencode/skills/<skillname>/SKILL.md. The one I'm hitting this on persistently is ops-cluster-alert. If I start a session through the web interface (my primary interface) it will immediately become available.

The failure mode I have is triggered through:

POST {OPENCODE_API_URL}/session?directory=<projectdir> with Basic Auth (OPENCODE_API_USER:OPENCODE_API_PASSWORD). Returns session_id successfully.

then immediately on receipt of the session_id:

POST {OPENCODE_API_URL}/session/<session_id>/prompt_async with JSON body {"parts": [{"type": "text", "text": "<prompt>"}]}

... where prompt explicitly says "use ops-cluster-alert to investigate XYZ" -> attempt to use the skill failed, attempts to find the skill failed. I just tried this again this afternoon and the model decided it was a phishing attempt(!) because of the reference to the "non-existent" skill.

@twhittock oh I think this is a problem with how you are hitting the endpoint. You need to pass the same directory param on all HTTP requests so it would be /session/<session_id>/prompt_async?directory=<projectdir>. Can you try that and see if that works?

If you use the SDK you can provide the project directly once when creating the client and then it automatically does that

I agree this is confusing, in the next iteration of our APIs we are fixing this so can you create a session in whatever context and you won't need to pass anything in future calls

OK thank you - the directory queryparam didn't help in my version of opencode, but I just updated to the latest and it started working without the directory param, so some other change in the meantime has fixed this.

It seems very implicit whether or not the instanceref is actually in the fibre or not... I guess the change was to ensure it's always present at the top level? In which case, this isn't necessary, or is only useful as a defense in depth.

Please feel free to close as fixed.

Oh good to hear! Yes, this context should be carried through, but there are cases where it interops with native JS-based promise code where it can get lost. We should need to manually carry it through like this. The fix it to remove all those cases where we use promises, or where we do, be careful and pass it manually there if needed. We are working on getting everything in Effect where we won't have to worry about this.