Enum fields in query parameters return 'unsupported field type: enum'

[shavaizknz]

Description

When using a proto enum as a query parameter, the generated HTTP handler returns a validation error:

{
  "violations": [
    {
      "field": "timeframe",
      "description": "invalid value for query parameter timeframe: unsupported field type: enum"
    }
  ]
}

Reproduction

Given this proto definition:

enum Timeframe {
  TIMEFRAME_UNSPECIFIED = 0;
  TIMEFRAME_DAILY = 1;
  TIMEFRAME_WEEKLY = 2;
  TIMEFRAME_ALL = 3;
}

message GetPortfolioRequest {
  string account_id = 1;
  Timeframe timeframe = 2 [(sebuf.http.query) = { name: "timeframe" }];
}

service PortfolioService {
  rpc GetPortfolio(GetPortfolioRequest) returns (Portfolio) {
    option (sebuf.http.config) = {
      method: "GET"
      path: "/api/v1/accounts/{account_id}/portfolio"
    };
  }
}

A request like GET /api/v1/accounts/123/portfolio?timeframe=TIMEFRAME_ALL fails with the above error.

Root Cause

The convertStringToFieldValue function in internal/httpgen/generator.go handles string, int, uint, bool, and float kinds but has no case for protoreflect.EnumKind. Enum query parameters fall through to the default error case.

Expected Behavior

Enum query parameters should be accepted as:

• Enum name strings (e.g., TIMEFRAME_ALL) — resolved via the field's enum descriptor
• Numeric values (e.g., 3) — parsed directly as the enum number

Affected Components

• protoc-gen-go-http — HTTP handler generator
• Both path parameters and query parameters are affected

[SebastienMelki]

Hey @shavaizknz, thanks for the thorough write-up — clean repro, correct root-cause identification, and opening #152 alongside it is exactly the kind of contribution that makes maintaining this a joy. Much appreciated.

This is a real gap. Enum support in query and path params should match protobuf ecosystem conventions. Here's what I'd like the fix to look like:

Behavior

Accept either form for enum values:

• Enum value name — the full name as declared in proto (e.g. TIMEFRAME_ALL). Case-sensitive, matching protojson semantics.
• Numeric value — the enum number (e.g. 3).

Both forms should work for:

• Query parameters (sebuf.http.query)
• Path parameters — you noted both are affected, please confirm the fix covers both codepaths

Validation

• Unknown enum name → return the existing violations shape with a clear message, e.g. invalid value "FOO" for query parameter timeframe: unknown enum value for Timeframe
• Out-of-range number → same shape, e.g. invalid value "99" for query parameter timeframe: no enum value defined for number 99. I'd lean strict here rather than passing unknown numbers through for forward-compat — happy to revisit if you have a case for the other direction.
• UNSPECIFIED / 0 → accept as valid. Whether zero is "required" belongs to a different validation layer.
• Empty string → treat as field not provided (existing behavior).

Tests

Please add cases covering:

1. Query param, valid enum name → parsed correctly
2. Query param, valid numeric value → parsed correctly
3. Query param, UNSPECIFIED → accepted
4. Query param, unknown name → validation error
5. Query param, out-of-range number → validation error
6. Query param, wrong case (e.g. timeframe_all) → rejected — locks in case-sensitive behavior
7. Query param, empty value → treated as unset
8. Path param equivalents of 1, 2, and 4 at minimum

Example update

Please add an enum field to one of the request messages in examples/ that uses [sebuf.http.query] so the behavior is visible end-to-end. A Timeframe-style enum fits naturally on a portfolio or analytics-style example.

Docs update

In the HTTP annotations docs, add enums to the supported query/path parameter types with a one-line note on accepted forms (name or number) and a short example. If there's a "supported field types" table, add the enum row.

Out of scope for this PR — follow-ups welcome

• Repeated enum query params (?status=A&status=B) — if it doesn't already compose cleanly with the fix, let's track separately
• Enum aliasing or short-name acceptance — sticking with full names for now to match protojson

Let me know if any of this conflicts with what you've already done in #152 and we'll adjust from there. Happy to iterate on the PR.

[shavaizknz]

Changes in PR #152:

• Enum values accepted by name (case-sensitive) or number for both query and path parameters
• Unknown numbers accepted for proto3 forward-compat (matching protojson)
• Unknown names rejected with actionable error message including enum type
• Empty strings treated as unset
• 11 runtime test cases, integration example in examples/enum-params/, and docs update
• Fixed a pre-existing TS server generator gap: enum path params and repeated enum query params now have proper type casts

Co-authored-by: Claude Code