Summary

protoc-gen-openapiv3 emits incorrect OpenAPI 3.1 schemas for repeated string proto fields when they appear as query parameters. They are documented as schema: type: string, but the TS client (correctly) serializes them as repeated ?foo=a&foo=b params via params.append(...). Any SDK generator consuming the spec (openapi-generator, kiota, Stoplight, etc.) will produce single-string fields and generate broken requests.

Observed against sebuf v0.11.0 in WorldMonitor's unified OpenAPI bundle (koala73/worldmonitor#3341, flagged by Greptile review).

Current output

- name: symbols
  in: query
  required: false
  schema:
    type: string

Expected output (OpenAPI 3.1)

- name: symbols
  in: query
  required: false
  schema:
    type: array
    items:
      type: string
  style: form
  explode: true

Affected fields (examples from WorldMonitor)

airports, symbols, ids, coins, commodities, energySources, entities, airlines — any repeated string used as a query param.

Why it matters now

The bug pre-dates v0.11.0 in per-service specs, but v0.11.0's new unified bundle mode (bundle=true, #158) is explicitly intended for external consumers and SDK generators. Publishing the bundle externally would ship broken client generation.

Symmetric correctness note

The TS client/server codegen in v0.11.0 is already correct:

• client: arr.forEach(v => params.append(name, v))
• server: params.getAll(name)

Only the OpenAPI schema emitter is out of sync.

Scope

Likely also affects repeated <scalar> for numeric and bool types — worth auditing all non-message scalar repeated fields in the query-param path, not just strings.

Repro

Any service with a repeated string in a GET request message will show the issue. Happy to provide a minimal .proto if useful.