Skip to content

tool/loadartifactstool: return error instead of panic when artifact service is not configured - #1390

Merged
wolo-lab merged 5 commits into
google:mainfrom
GerardGao:fix/loadartifacts-nil-panic
Aug 28, 2026
Merged

tool/loadartifactstool: return error instead of panic when artifact service is not configured#1390
wolo-lab merged 5 commits into
google:mainfrom
GerardGao:fix/loadartifacts-nil-panic

Conversation

@GerardGao

Copy link
Copy Markdown
Contributor

Fixes #283

What changed

  • loadartifactstool now returns a descriptive error ("load_artifacts tool requires an artifact service to be configured") from ProcessRequest when no artifact service is configured, instead of panicking with a nil pointer dereference.
  • agent.NewToolContext and agent.NewCallbackContextWithArtifactTracking no longer wrap a nil Artifacts in trackedArtifacts, so "no artifact service configured" remains observable as a nil Artifacts instead of panicking on the first promoted method call.

Why

When the load_artifacts tool is registered but no artifact service is configured, the agent panics during request preprocessing (nil pointer dereference in trackedArtifacts.List, previously internalArtifacts.List — see #283). A configuration error should be reported as an error instead of crashing the process.

Testing plan

  • Added TestLoadArtifactsTool_ProcessRequest_NilArtifacts: constructs a context with no artifact service and asserts ProcessRequest returns an error mentioning the artifact service (this test panicked before the fix).
  • go test ./agent/... ./tool/... ./runner/... — all pass.
  • gofmt -l clean.

@google-cla

google-cla Bot commented Aug 23, 2026

Copy link
Copy Markdown

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@GerardGao

Copy link
Copy Markdown
Contributor Author

I signed it!

@GerardGao
GerardGao force-pushed the fix/loadartifacts-nil-panic branch from ef62a47 to e538345 Compare August 25, 2026 13:39
@wolo-lab
wolo-lab self-requested a review August 27, 2026 12:18
Comment thread tool/loadartifactstool/load_artifacts_tool.go
Per review: the guard lived in appendInitialInstructions, so the
ctx.Artifacts() read in processLoadArtifactsFunctionCall was only
protected by call ordering. Move the check to the top of
ProcessRequest so both paths are covered in one place, and add a test
that exercises the function-call path through the public entry.
@GerardGao

Copy link
Copy Markdown
Contributor Author

Addressed in 455d4be: the guard now lives at the top of ProcessRequest, covering both appendInitialInstructions and processLoadArtifactsFunctionCall in one place, instead of relying on call ordering. Added TestLoadArtifactsTool_ProcessRequest_NilArtifacts_WithFunctionCall to pin the function-call path through the public entry.

@wolo-lab wolo-lab left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, LGTM

@wolo-lab
wolo-lab merged commit 3774587 into google:main Aug 28, 2026
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Panic when Artifact tool is not properly setup

2 participants