[johnworth]

The bug

GET /users/{username}/usages returned 500 for any user with no subscription. Reported by the resource-usage-api merge work, which reads that route to decide whether a first data-usage reading exists — it could not tell "none recorded" from a genuine fault, so affected users never got a first reading at all. Roughly half of a probe of random DE users hit it in QA. It predates that merge.

Root cause

db.GetActiveSubscription discarded the not-found flag from its scan:

if _, err = query.Executor().ScanStructContext(ctx, &result); err != nil {

On a miss that leaves result zeroed and returns &Subscription{} with ID == "" and a nil error. Callers passed that empty string to queries comparing it against a uuid NOT NULL column, and PostgreSQL rejected the statement:

pq: invalid input syntax for type uuid: ""

Nothing recognizes that error, so it fell through to a 500 and the generic message.

Blast radius

One defect, three broken routes:

Route	Before	After
GET /users/{u}/usages	500	200 {"usages":[]}
PUT /users/{u}/usages	500	200, subscribes the user
PUT /user/{u}/updates (quotas)	500	200, subscribes the user
PUT /user/{u}/updates (usages)	200	unchanged

Only ProcessUpdateForUsage guarded against it, which is why usage updates worked while everything around them did not.

Commit 1 — the fix

GetActiveSubscription now honors the flag and returns nil when there is no active subscription — matching GetSubscriptionByID beside it and the QMS-side implementation, both of which already got this right. Write paths move to a new GetOrCreateActiveSubscription, which also replaces the two hand-copied subscribe-to-default-plan blocks in summary.go and updates.go.

Behavior worth reviewing: reading the usage list reports the empty list rather than subscribing anyone — a GET that quietly enrolled whoever was named in the URL is a side effect callers have already been surprised by on /summary. The write paths do enrol an unsubscribed user, matching what the usage-update path has always done.

Commit 2 — the logger bug that hid this

Chasing why the failure was hard to place turned up a separate defect. Five handlers built their per-request logger by assigning to the package-level one instead of shadowing it:

log = log.WithFields(logrus.Fields{"user": username})

The username then stuck to every line the process logged afterwards:

uri=/users/bob/usages   user=alice
uri=/addons             user=alice

So anyone triaging by username was pointed at the wrong user — the line naming this uuid failure carried an unrelated caller's name. Concurrent requests also raced on the variable; the race detector confirms it. Three of the five sites never logged anything at all, so their only effect was on other requests' output; those are removed.

Commit 3 — put the user back on the request log

Removing those assignments took user= off the access log entirely, since the request logger never set it itself. It now reads the name from the route it matched, so the field is present on every request that names a user, is always that request's own subject, and is absent (rather than stale) on requests that matched no route.

Testing

New coverage in apitest/ against a real PostgreSQL (testcontainers):

• all four routes above for a user with no subscription
• listing usages creates no subscription; recording usage does
• a username from one request does not appear in the next request's logs, sequentially and concurrently
• the request log names the request's own user, for both route parameter spellings

Both new test files were verified to fail against the pre-fix code. Full suite passes under -race, golangci-lint reports 0 issues, and every pre-existing golden still matches — nothing on the wire changed for the working cases.

Verified in QA

Built from this branch and deployed to the qa namespace (sha256:fa44976f…):

GET /users/zzznewuser99@iplantcollaborative.org/usages   → 200 {"usages":[]}   (was 500)
GET /users/wregglej@iplantcollaborative.org/usages       → 200, full usage list intact
GET /users/{u}/overages                                  → 200, unchanged

Log lines each carry their own correct user, and /addons carries none.

🤖 Generated with Claude Code