fix: log underlying errors when /account/limits returns HTTP 500

[cursor]

Summary

Sentry issue 7504868852 reports an HTTP 500 /account/limits event captured at level info by the captureHTTPError middleware in pkg/public/middleware/logging.go. That middleware only attaches the URL and status (CaptureMessage("HTTP %d %s", status, path)), so the Sentry event by itself has no information about what actually failed.

The /account/limits endpoint is served by getOrganizationCreationStatus in pkg/public/server.go, which delegates to describeOrganizationCreationStatus. That function can fail at several distinct stages:

• models.CountOrganizationsByBillingAccount (DB query)
• usage.Service.CheckAccountLimits (gRPC to the usage service)
• usage.Service.SetupAccount (lazy provisioning, called on a codes.NotFound)
• the second CheckAccountLimits call after lazy provisioning

The handler previously collapsed all of these into a single log.Errorf("Error loading organization creation status for account %s: %v", ...). Because of %v on a wrapped error the underlying cause was technically printed, but the entry was unstructured and didn't expose which stage failed or the gRPC status code — neither in the application logs nor (via correlation) in Sentry.

Changes

pkg/public/server.go

• describeOrganizationCreationStatus: emit a structured log.WithError(err).WithField("account_id", ...).WithField("stage", ...) entry at each failure point, identifying the stage (count_organizations, check_account_limits) so future Sentry occurrences can be filtered, alerted on, and triaged from logs.
• checkAccountOrganizationCreationLimits: log the SetupAccount failure and the retry-CheckAccountLimits failure separately, both with account_id and grpc_code fields, instead of silently returning the raw gRPC error.
• getOrganizationCreationStatus / createOrganization: drop the redundant top-level log.Errorf (the cause is now logged from the call site with structured fields) and replace with a short tagged Error line, so we don't double-log the same chain.

pkg/public/server_test.go

• Extend fakePublicUsageService with a checkAccountErr field so tests can simulate gRPC failures.
• Add Test__GetOrganizationCreationStatus/returns 500 with diagnostic context when the usage service is unavailable: when the usage service returns codes.Unavailable, the endpoint must still respond with HTTP 500 (no panic, no nil dereference) — exercising the previously-untested gRPC failure path that drives the Sentry alert.

Why diagnostic-only

This mirrors the same pattern used to triage prior HTTP 500 ... Sentry issues:

• PR fix: log underlying errors when canvas dashboard returns HTTP 500 #4810 — fix: log underlying errors when canvas dashboard returns HTTP 500 (Sentry 7483010621)
• PR fix: log underlying errors when agent chat endpoint returns HTTP 500 #4929 — fix: log underlying errors when agent chat endpoint returns HTTP 500 (Sentry 7495744767)

The handler still returns the same HTTP 500 response when the upstream dependency really is broken, but the next occurrence of this Sentry issue will have the actual underlying error (DB failure / gRPC Unavailable / DeadlineExceeded / etc.) in the application logs with structured fields, so the root cause can be acted on directly.

Validation

The dev environment requires Docker (unavailable in this VM), so the full make test / make lint / make check.build.app chain was not run. As a substitute:

• go build ./pkg/public/... ./pkg/models/... ./pkg/usage/... ./pkg/public/middleware/... — clean
• go vet ./pkg/public/... — clean
• gofmt -s -w / goimports -w on the touched files — no further diff

Refs

• Sentry issue 7504868852
• Prior precedents: PR fix: log underlying errors when canvas dashboard returns HTTP 500 #4810, PR fix: log underlying errors when agent chat endpoint returns HTTP 500 #4929

  

[superplanehq-integration]

👋 Commands for maintainers:

• /sp start - Start an ephemeral machine (takes ~30s)
• /sp stop - Stop a running machine (auto-executed on pr close)