fix(langgraph): graph nodes look up tools by the wrong names and always fail

[yakimoto]

createStreamMonitorNode and createClipNode look up their tool by name — but with the wrong names.

const monitorTool = tools.find((t) => t.name === 'monitor_stream');   // real name: wave_monitor_stream
const clipTool    = tools.find((t) => t.name === 'create_clip');      // real name: wave_create_clip

AgentToolkit.getTools() names every tool with a wave_ prefix, so neither lookup can ever succeed. Both nodes fall into their if (!tool) branch on every invocation, return an error object, and never make a network call. Anyone wiring createStreamMonitorNode into a LangGraph StateGraph gets a node that silently does nothing.

Proven against the built package on main:

$ node -e "import('./dist/index.js').then(async m => {
    console.log(JSON.stringify(await m.createStreamMonitorNode({apiKey:'x',streamId:'s1'})({})));
    console.log(JSON.stringify(await m.createClipNode({apiKey:'x'})({})));
  })"
{"error":"monitor_stream tool not found"}
{"error":"create_clip tool not found"}

After the fix the handler is actually reached — it now rejects the non-uuid streamId in zod, which is the tool running rather than the lookup failing:

createStreamMonitorNode now -> {"thrown":"[{ \"origin\": \"string\", \"code\": \"invalid_format\", …"}

The sibling LiveKit adapter already used the correct wave_monitor_stream, which is why this stayed isolated to the LangGraph adapter.

Why this shipped

src/__tests__/adapters.test.ts asserts the shape of createLangGraphTools, but nothing exercises the two graph-node factories. It would not have caught this either way: those tests do not run — vitest is absent from package-lock.json, there is no test script, and tsconfig.json excludes the test directory. Filed separately.

Verification

npm run type-check   # exit 0
npm run lint         # exit 0 (eslint --max-warnings 0)
npm run build        # ESM + CJS build success

Four-line change, no API surface change. Independent of #58 — either can merge first.

CI is hard-down org-wide on Actions billing (wave-av/wave-rig#174), so checks cannot run here.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

---

Note

Low Risk
Small string fixes in adapter internals; restores intended behavior with no security or data-model impact.

Overview
Fixes broken LangGraph graph nodes that never invoked WAVE tools because createStreamMonitorNode and createClipNode searched for monitor_stream and create_clip while AgentToolkit.getTools() registers wave_monitor_stream and wave_create_clip.

Both nodes now resolve the correct tool names (matching the LiveKit adapter) and run their handlers instead of returning { error: '… tool not found' } on every call. Error strings in the not-found branches are updated to the prefixed names. No public API or signature changes.

^{Reviewed by Cursor Bugbot for commit 63bf260. Configure here.}

---

Summary by cubic

Fix LangGraph nodes to use the correct wave_-prefixed tool names so they find their tools and run handlers instead of returning errors. createStreamMonitorNode now looks up wave_monitor_stream; createClipNode now looks up wave_create_clip.

^{Written for commit 63bf260. Summary will update on new commits.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: 63bf260

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_dd148f74-26d7-4203-93e3-a0975080425d)

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 44 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 746b38e9-cc4f-4366-98a0-4f1f8b3fb6b4

📥 Commits

Reviewing files that changed from the base of the PR and between eb79119 and 63bf260.

📒 Files selected for processing (1)

• src/adapters/langgraph.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/langgraph-tool-names

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch fix/langgraph-tool-names

---

_{Comment @coderabbitai help to get the list of available commands.}

[yakimoto]

Hold on merging this — it is correct, but it fixes a repo that does not publish.

While tracing where LangGraph is actually used, I found @wave-av/adk exists in three source copies, and this repo is not the one npm serves:

Location	Version	Publishes
wave-av/sdks → sdk-typescript/packages/adk	1.0.14	yes — matches the npm artifact
wave-av/wave-surfer-connect → packages/adk	1.0.14	pre-carve origin
this repo	1.0.2	12 versions behind

The published tarball contains ERROR-CODES.md and code-split dist/chunk-*.js. This repo has no ERROR-CODES.md and builds single-entry, which cannot emit chunks. The monorepo copies match on both counts.

The bug is genuinely live on npm — grep "monitor_stream tool not found" package/dist/index.cjs hits in @wave-av/adk@1.0.14 — but merging this PR would not change that.

The fix that actually reaches users is wave-av/sdks#41, which carries the same four-line change plus regression tests that I verified are non-vacuous (reintroducing the old names fails 2/10; the fix passes 10/10). This repo's test suite cannot run at all — see #60 — so no equivalent test is possible here.

The fork problem is filed as wave-av/sdks#42. Whether this PR merges or closes depends on which repo becomes the home:

• If sdks is the home → close this, and feat(tools): fleet, dispatch and payment toolkits (#72) #58 needs re-basing there too.
• If this repo is the home → merge this, but it needs syncing forward from 1.0.14 first, or merging it re-buries the other 12 versions of work.

Leaving it open pending that call rather than merging something that would read as "fixed" while npm stays broken.