[Bug]: `@encode(string)` int64 default becomes `null`, and numeric examples ignore the encoding

[Om-singhaI]

Describe the bug

With @encode(string) id: int64 = 9007199254740993, the OpenAPI output has "default": null, so the value is lost. Other defaults and @example values on @encode(string) int64 and decimal properties come out as JSON numbers, which don't match the type: string next to them.

serializeValueAsJson in packages/compiler/src/lib/examples.ts already resolves the property's @encode, but the NumericValue case returns asNumber() without checking it, and asNumber() gives null when a JS number can't hold the value exactly. Dates and durations already use the encoding in that function (#11731 fixed the milliseconds case). Happy to send a PR.

Reproduction

@example(#{ id: 42, balance: 1050.25 })
model Account {
  @encode(string) id: int64 = 9007199254740993;
  @encode(string) balance: decimal = 0;
}

OpenAPI 3.0.0 output on current main. 3.1.0 and 3.2.0 give the same defaults.

"properties": {
  "id": { "type": "string", "format": "int64", "default": null },
  "balance": { "type": "string", "format": "decimal", "default": 0 }
},
"example": { "id": 42, "balance": 1050.25 }

Expected "9007199254740993" and "0" for the defaults, and { "id": "42", "balance": "1050.25" } for the example.

[github-actions]

🎯 Issue Triage
@encode(string) is not honored when numeric defaults and examples are serialized, producing type-inconsistent JSON numbers and losing unsafe int64 values as null.
Category: Bug
Area: compiler:core

🔗 [Playground Reproduction]((typespec.io/redacted)

📋 Reproduction code

@example(#{ id: 42, balance: 1050.25 })
model Account {
  @encode(string) id: int64 = 9007199254740993;
  @encode(string) balance: decimal = 0;
}

🔍 Analysis

The shared compiler serializer in packages/compiler/src/lib/examples.ts resolves the target property encoding, but its NumericValue branch returns asNumber() without applying it. This yields JSON numbers for string-encoded numeric values and null when an int64 cannot be represented exactly as a JavaScript number. The issue affects OpenAPI 3.0, 3.1, and 3.2. Related #3856 introduced numeric-as-string encoding but does not cover this defect.

📝 Suggested next steps

• Honor the resolved @encode target during numeric serialization.
• Add regression tests for exact and unsafe int64 defaults and numeric examples.
• Confirm values remain strings across supported OpenAPI versions.

Generated by Agentic Triage