Skip to content

fix(server): return 204 from registerUser when no auth is issued - #7042

Merged
otavio merged 1 commit into
masterfrom
fix/api/register-user-no-content
Sep 4, 2026
Merged

fix(server): return 204 from registerUser when no auth is issued#7042
otavio merged 1 commit into
masterfrom
fix/api/register-user-no-content

Conversation

@luizhf42

@luizhf42 luizhf42 commented Sep 4, 2026

Copy link
Copy Markdown
Member

What

POST /api/register now returns 204 (no body) for open registrations and 200 with userAuth credentials for invitation-based registrations. The OpenAPI spec documents both paths.

Why

The handler returned 200 for both cases — with a UserAuthResponse body on the invitation path and an empty body on the open-registration path. The spec declared no response schema at all, so codegen tools (hey-api, Orval) typed the return as void. The invited-user flow that auto-logs in after signup relied on reading token and tenant from the response, which the generated type said didn't exist.

This surfaced during the Orval migration (#7023): customInstance calls response.json() on every non-204 response, so an empty 200 body throws a SyntaxError instead of succeeding silently like hey-api did.

Changes

  • server/api/routes/invitation.go: RegisterUser returns http.StatusNoContent instead of http.StatusOK when authInfo is nil (open registration, no credentials to return)
  • openapi/spec/paths/api@register.yaml: split the 200 response into 200 (with userAuth schema) and 204 (no body), so codegen produces the correct return type

Testing

Register via both paths and verify the status codes:

  • Open registration (no sig): should return 204
  • Invitation registration with a valid sig where the user is auto-confirmed: should return 200 with token and tenant in the JSON body
  • Invitation registration where the user still needs admin approval: should return 204

The handler returned 200 with an empty body for open registrations
(no invitation `sig`). The OpenAPI spec declared no response schema,
so codegen tools typed the return as `void`. The invited-user path
that does return `UserAuthResponse` was undocumented.

Split into 200 (with `userAuth` schema, invitation flow) and 204
(no body, open registration) so the generated client carries the
correct return type and `customInstance` handles the empty response
through its existing 204 path.
@luizhf42
luizhf42 requested review from a team as code owners September 4, 2026 20:23
@otavio

otavio commented Sep 4, 2026

Copy link
Copy Markdown
Member

/review

@github-actions

github-actions Bot commented Sep 4, 2026

Copy link
Copy Markdown

Claude finished @otavio's task in 1m 15s —— View job


Code Review Complete

Reviewed 2 files across code quality, security, testing, language patterns, and architecture — no new issues found. The code looks good as-is.

A few notes confirming the change is sound:

  • server/api/routes/invitation.go: returning 204 when authInfo == nil is correct and matches the handler's existing branch structure.
  • openapi/spec/components/schemas/userAuth.yaml exists and its shape matches the returned *models.UserAuthResponse (includes token and tenant), so codegen will type the 200 path correctly.
  • No Community Edition consumers of POST /api/register rely on the old 200-with-empty-body behavior.

If you push additional changes and want a new review, tag @shellhub-io/admin and a team member can trigger it.

@otavio
otavio merged commit bbaf84c into master Sep 4, 2026
43 checks passed
@otavio
otavio deleted the fix/api/register-user-no-content branch September 4, 2026 20:54
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.

2 participants