Fix Tavily tool SecretRef runtime config#78610
Conversation
|
Codex review: needs maintainer review before merge. Summary Reproducibility: yes. Current main can be source-reproduced by resolving Tavily plugin tools with raw source config containing an Real behavior proof Next step before merge Security Review detailsBest possible solution: Merge the Tavily-owned factory binding fix with its regression coverage and changelog once required checks pass. Do we have a high-confidence way to reproduce the issue? Yes. Current main can be source-reproduced by resolving Tavily plugin tools with raw source config containing an Is this the best way to solve the issue? Yes. The patch uses the existing plugin-tool factory context ( What I checked:
Likely related people:
Codex review notes: model gpt-5.5, reasoning high; reviewed against a74b459f7a74. |
byungskers
left a comment
There was a problem hiding this comment.
Nice catch on the SecretRef resolution path. The fallback chain in resolveTavilyToolConfig (getRuntimeConfig → runtimeConfig → config → api.config) is exactly the right priority order for runtime config resolution.
One small suggestion: if there's already a test exercising the tool registration path via the plugin entry point, it might be worth adding an assertion that verifies the ctx object is actually passed through to the factory. Otherwise this looks ready to go.
f6ea284 to
1555165
Compare
Resolve Tavily dedicated tool credential lookup against the active runtime config snapshot. PR: #78610
Resolve Tavily dedicated tool credential lookup against the active runtime config snapshot. PR: openclaw#78610
Resolve Tavily dedicated tool credential lookup against the active runtime config snapshot. PR: openclaw#78610
Summary
tavily_searchandtavily_extractcredentials from the active runtime config snapshot when availableexecSecretRef source config plus resolved runtime configReal Behavior Proof
Behavior or issue addressed: Dedicated Tavily tools were created from plugin-load
api.config, so a configuredexecSecretRef could remain raw even when the active runtime snapshot already had the resolved Tavily API key.Real environment tested: Separate temp OpenClaw worktree at
/tmp/openclaw-tavily-secretref.ILwex2, Node 25.9.0, pnpm 10.33.2, branchtavily-secretref-runtime-config, using the realresolvePluginToolspath with a raw source config and a resolved runtime config snapshot.Exact steps or command run after this patch: Ran the real plugin tool resolver with
env -u TAVILY_API_KEY pnpm exec tsx -e ..., where source config containedplugins.entries.tavily.config.webSearch.apiKey = { source: "exec", provider: "default", id: "printf resolved-key" }and runtime config containedapiKey: "resolved-key"plusbaseUrl: "https://api.tavily.test".Evidence after fix: Copied terminal output from the after-fix probe:
Observed result after fix: The previous unresolved SecretRef exception no longer occurs. The dedicated
tavily_searchtool reads the resolved runtime snapshot, including the runtime-only fake Tavily base URL, and advances to the request path; the DNS error is expected becauseapi.tavily.testis deliberately not a real host.What was not tested: A live Tavily API request was not run because
TAVILY_API_KEYis not present in~/.profilein this environment.Before evidence optional: Before the fix, the same resolver path failed before making any request:
Verification
pnpm test extensions/tavily/src/tavily-tools.test.ts -- --reporter=verbosepnpm exec oxfmt --check --threads=1 extensions/tavily/index.ts extensions/tavily/src/tavily-extract-tool.ts extensions/tavily/src/tavily-search-tool.ts extensions/tavily/src/tavily-tools.test.tsgit diff --checkpnpm check:changedpnpm test:changed