fix(observability): avoid error status for expected pkgsite results

[garrettladley]

• keep expected pkgsite tool results from setting span codes.Error
• preserve observability.ResultAttrs status-code attributes for handled pkgsite errors
• add coverage for unexpectedPkgsiteStatus across expected 4xx and unexpected 5xx results

[greptile-apps]

Greptile Summary

This PR fixes a noisy observability footprint where expected pkgsite 4xx responses (404, 400, 429) were incorrectly marking OTel spans as codes.Error. The new unexpectedPkgsiteStatus helper gates that status transition on statusCode >= 500, preserving the ErrorStatusCode attribute on ResultAttrs for all error cases regardless.

• register.go: Wraps span.SetStatus(codes.Error, …) in unexpectedPkgsiteStatus, so 4xx pkgsite responses keep the span's default OK status while still recording the status-code attribute.
• register_test.go: Adds a parallel table-driven unit test for unexpectedPkgsiteStatus covering representative 4xx (false) and 5xx (true) inputs.

Confidence Score: 5/5

Safe to merge; the change is narrowly scoped to the OTel span-status path and does not alter any data returned to callers.

The diff is small and correct: 4xx responses from pkgsite are expected client-side outcomes and should not flip span status to Error. The unexpectedPkgsiteStatus helper is straightforwardly expressed and well-tested. The only gap is the absence of a statusCode=0 test case, which is a documentation concern rather than a runtime defect.

No files require special attention.

Important Files Changed

Filename	Overview
internal/mcpserver/tools/register.go	Guards span.SetStatus(codes.Error) behind a new unexpectedPkgsiteStatus check (statusCode >= 500), so expected 4xx responses from pkgsite no longer pollute trace error counts.
internal/mcpserver/tools/register_test.go	New parallel table-driven tests for unexpectedPkgsiteStatus covering 400, 404, 429 (false) and 500, 503 (true); missing a case for statusCode=0.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[s.result called] --> B{Go-level error?}
    B -- yes --> C[return nil, nil, err]
    B -- no --> D{result.Error != nil?}
    D -- no --> E[set ResultAttrs attributes on span]
    D -- yes --> F[set ErrorStatusCode on ResultAttrs]
    F --> G{unexpectedPkgsiteStatus\nstatusCode >= 500?}
    G -- yes --> H[span.SetStatus codes.Error]
    G -- no --> I[4xx: span stays OK]
    H --> E
    I --> E
    E --> J{result.Items > 0\nor Pagination != nil?}
    J -- yes --> K[return paginatedEnvelope]
    J -- no --> L[return singleEnvelope]

Loading

_{Reviews (1): Last reviewed commit: "fix(observability): avoid error status f..." | Re-trigger Greptile}

[greptile-apps]

The test suite doesn't include statusCode = 0. An APIError with a zero-valued StatusCode (e.g. constructed without setting the field) would return false from unexpectedPkgsiteStatus, silently skipping the error span. Adding a 0 case makes the boundary explicit and documents the intended treatment of that sentinel value.

Suggested change

	tests := []struct {
	status int
	want bool
	}{
	{status: 400, want: false},
	{status: 404, want: false},
	{status: 429, want: false},
	{status: 500, want: true},
	{status: 503, want: true},
	}
	tests := []struct {
	status int
	want bool
	}{
	{status: 0, want: false},
	{status: 400, want: false},
	{status: 404, want: false},
	{status: 429, want: false},
	{status: 500, want: true},
	{status: 503, want: true},
	}