[http-specs] Add spector coverage for extensible enum with date/version-like member names

[msyyc]

Which area does this affect?

packages/http-specs — test coverage gap for type/enum/extensible.

Description

The Python emitter (@typespec/http-client-python) crashes with AttributeError: ''int'' object has no attribute ''rstrip'' for extensible enums whose member names are date/version-like (e.g. 2020-01-01). See emitter bug: #11138

Root cause: the emitter converts the union member name 2020-01-01 to 2020_01_01 in the intermediate YAML code model. When that YAML is deserialized, 2020_01_01 is parsed as the integer 20200101 (YAML treats underscores as digit separators in numbers). The int then flows into update_description as the default description and crashes.

Minimal reproducing spec (a string extensible enum with date-like member names, e.g. an API version enum):

union ApiVersion {
  string;
  `2020-01-01`: "2020-01-01";
  `2021-01-01`: "2021-01-01";
}

The existing extensible enum spector spec at packages/http-specs/specs/type/enum/extensible/main.tsp only covers DaysOfWeekExtensibleEnum, whose member names are plain words (Monday, ...). There is no coverage for extensible enums whose member names are numeric/date/version-like strings and therefore round-trip through YAML as integers.

Request

Add a spector scenario under type/enum/extensible (or a sibling folder) covering a string extensible enum whose member names look like dates/versions, e.g.:

@doc("Service API versions")
union ApiVersionExtensibleEnum {
  string,
  @doc("Version 2020-01-01.")
  `v2020-01-01`: "2020-01-01",
  @doc("Version 2021-01-01.")
  `v2021-01-01`: "2021-01-01",
}

with @scenario get/put routes for known and unknown values, mirroring the existing string-based String interface (known value, unknown value, put known, put unknown).

Why

• Exercises extensible enum member names that serialize as integers when round-tripped through YAML.
• Prevents regressions like the Python update_description crash from going undetected across emitters.

[github-actions]

🎯 Issue Triage

Request to add spector test coverage for integer-valued extensible enums in packages/http-specs/specs/type/enum/extensible, which is currently missing and exposed a Python emitter crash (see #11138).

Category: Feature Request
Area: lib:http-specs

🔁 Possible duplicate of #11139 — Issue #11139 has an identical title and body, created by the same author 5 seconds earlier (open).

🔍 Analysis

• The existing type/enum/extensible spector spec only covers string-valued extensible enums (DaysOfWeekExtensibleEnum); no coverage exists for integer-valued ones.
• This gap allowed the Python emitter bug ([http-client-python] AttributeError: 'int' object has no attribute 'rstrip' in preprocess update_description #11138 — AttributeError: 'int' object has no attribute 'rstrip') to go undetected by spector.
• The request is to add a PriorityExtensibleEnum union with int32 variants and @scenario get/put routes for known and unknown values, mirroring the existing String interface.
• Fixing this coverage gap benefits all language emitters, not just Python.

📝 Suggested next steps

• Confirm canonical issue between [http-specs] Add spector coverage for integer-valued extensible enum (type/enum/extensible) #11139 and [http-specs] Add spector coverage for extensible enum with date/version-like member names #11140; close the duplicate.
• Add PriorityExtensibleEnum (or equivalent) integer union to packages/http-specs/specs/type/enum/extensible/main.tsp.
• Add mock API server routes for the new Integer scenario (known value, unknown value, put known, put unknown).
• Update language emitter test suites to cover the new scenario.

Generated by Agentic Triage