Add Spector cases for serializing lossy duration encodings as integers by Copilot · Pull Request #10835 · microsoft/typespec

Copilot · 2026-05-29T02:15:40Z

Existing encode/duration scenarios only used whole-number payloads, so they couldn't catch the bug from #10831 where a duration with a fractional sub-second component was serialized as a floating point number (e.g. 123.45) instead of an integer.

These tests target the lossy encode case, where the source duration carries more precision than the target integer encoding can represent. The client must still serialize the value using the target number type (an integer), discarding the extra precision, rather than emitting a floating point number. This is distinct from arbitrary type mismatches, which are already covered by the existing round-trip scenarios.

Changes (`packages/http-specs/specs/encode/duration/`)

main.tsp: New dedicated Lossy namespace (routed under /encode/duration/lossy/...) containing the lossy-encode scenarios, instead of placing them under the regular Query/Property/Header encoding categories. For each transport (query, property, header) it adds:

int32-seconds: a 36.25-second duration encoded as int32 seconds (sub-second source precision).
int32-milliseconds: a 36250.25-millisecond duration encoded as int32 milliseconds (sub-millisecond source precision).

@route("/int32-seconds")
@scenario
@scenarioDoc("""
  ...The duration is 36.25 seconds, e.g. TimeSpan.FromSeconds(36.25) in C#.
  The client must serialize the value as an integer (not a floating point
  number such as `36.25`), discarding the sub-second precision.
  Because emitters may floor, round, or ceil when discarding that precision,
  the expected query parameter is `input=36` or `input=37`.
  """)
op int32Seconds(
  @query @encode(DurationKnownEncoding.seconds, int32) input: duration,
): NoContentResponse;

mockapi.ts: New handlers (createLossyBodyServerTests, createLossyQueryServerTests, createLossyHeaderServerTests) verify that the received value is serialized as an integer (rejecting float/double/decimal output). They accept an allow-list of integers covering floor, round, and ceil results (36/37 for seconds, 36250/36251 for milliseconds), so the test verifies the core contract ("serializes as an int") without taking a position on an emitter's rounding mode.
spec-summary.md: Regenerated.

Note

The mock validation accepts floor/round/ceil results rather than a single exact value, so it remains agnostic to an emitter's rounding mode while still failing on floating point output.

Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

timotheeguerin · 2026-06-01T14:37:45Z

from discussion on the issue I don't think we can add a test for this as floor vs round is not something TypeSpec should have an opinion here and it more of an emitter implementation detail

The test can still validate that the proper number type is serialized (e.g. integer rather than double/decimal).

Updated the scenarios to validate only the number type. The mock handlers reject a floating point value and assert an integer is serialized, without checking an exact value. I also reworded the scenarioDocs to state that floor vs. round is an emitter implementation detail and that the test only validates that an integer is sent (e.g. 35 or 36). Done in 4b13fac.

@copilot actually we can just use input data such that the rounding vs truncating decision wouldn't matter - e.g. 36.25.

by that logic should we have a test to make sure you don't somehow send a string instead of a int as well? It just feels like this is one case you caught here but there is an infinite number of potential failures here

an emitter could also very well here decide that is this an error (crash) so can never get this test to work

by that logic should we have a test to make sure you don't somehow send a string instead of a int as well?

These type violations are already covered by every round trip test. This case is special because the source type carries more precision than the target encoding. This is a lossy encode scenario - not arbitrary type mismatch.

an emitter could also very well here decide that is this an error (crash) so can never get this test to work

The contract is "encode this duration as int32 seconds," so crashing is non-conformant behavior.

hhm alright fair enough, though do we need the same for milliseconds encoding?

…ding Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

…t value Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

pkg-pr-new · 2026-06-01T18:44:48Z

Open in StackBlitz

npm i https://pkg.pr.new/@typespec/http-specs@10835

commit: a96701d

JoshLove-msft · 2026-06-01T18:53:00Z

@copilot run chronus add

Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

Copilot · 2026-06-01T18:58:25Z

@copilot run chronus add

Added a changeset for @typespec/http-specs (changeKind: internal). chronus verify --since main now passes. Done in b9a6161.

azure-sdk-automation · 2026-06-01T18:59:56Z

You can try these changes here

🛝 Playground	🌐 Website	🛝 VSCode Extension

JoshLove-msft · 2026-06-01T19:32:56Z

@copilot add a line to the test description clarifying that this is specifically exercising the lossy encode scenario and not about arbitrary type mismatches.

Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

Copilot · 2026-06-01T19:36:37Z

@copilot add a line to the test description clarifying that this is specifically exercising the lossy encode scenario and not about arbitrary type mismatches.

Added a line to each of the three scenario docs (Query, Property, Header) clarifying that this specifically exercises the lossy encode case where the source type carries more precision than the target encoding, and is not about arbitrary type mismatches. Done in the latest commit.

timotheeguerin · 2026-06-01T19:41:02Z

hhm alright fair enough, though do we need the same for milliseconds encoding?

timotheeguerin · 2026-06-01T19:42:27Z

+    This scenario specifically exercises the lossy encode case where the source type carries more precision than the target encoding; it is not about arbitrary type mismatches, which are already covered by other round-trip scenarios.
+    The value is chosen so that rounding and truncating both yield the same integer, so the expected query parameter is `input=36`.
+    """)
+  op int32SecondsFractional(


Can we move this (and potentially the milli test) to another category, this doesn't feel like this belongs under query encoding. Maybe we can have a loosy encoding test file dedicated to those kind of tests)

The problem with doing this is that we still want to have header/query/property variants for the lossy encoding tests to exercise all code paths.

I don't think we need all 3 I would just keep a single in a body.

timotheeguerin · 2026-06-01T19:43:40Z

+          value,
+        );
+      }
+      if (value !== 36) {


probably unlikely but an implementation could also choose ceil so we might want to allow 37 to be explicit that all of this is allowed.
An option for those kind of tests would also be to have a 2-phase test, first part you get a value(randomly generated for that server instance) maybe duration encoded as float then you got to send back that value.

JoshLove-msft · 2026-06-01T19:52:03Z

@copilot please apply the feedback

…liseconds, allow ceil Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

Copilot · 2026-06-01T20:02:41Z

@copilot please apply the feedback

Applied the feedback:

Moved the lossy-encode scenarios out of Query/Property/Header into a dedicated Lossy namespace (/encode/duration/lossy/...), so they no longer live under the regular query encoding category.
Added matching int32-milliseconds scenarios (source value 36250.25 ms, sub-millisecond precision) alongside the int32-seconds ones (36.25 s), for query, property, and header.
The mock handlers now accept floor, round, or ceil results (e.g. 36/37 for seconds, 36250/36251 for ms) while still rejecting floating-point output, so the test doesn't take a position on an emitter's rounding mode.

Regenerated spec-summary.md and updated the changeset. validate-scenarios, validate-mock-apis, and client-server validation all pass.

JoshLove-msft · 2026-06-01T22:40:22Z

Error: test/e2e/http/encode/duration/main.test.ts(13,25): error TS2339: Property 'default_' does not exist on type 'QueryClient'.
Error: test/e2e/http/encode/duration/main.test.ts(18,25): error TS2339: Property 'iso8601' does not exist on type 'QueryClient'.
Error: test/e2e/http/encode/duration/main.test.ts(28,25): error TS2339: Property 'floatSeconds' does not exist on type 'QueryClient'.
Error: test/e2e/http/encode/duration/main.test.ts(33,25): error TS2339: Property 'float64Seconds' does not exist on type 'QueryClient'.
Error: test/e2e/http/encode/duration/main.test.ts(38,25): error TS2551: Property 'int32SecondsArray' does not exist on type 'QueryClient'. Did you mean 'int32Seconds'?
Error: test/e2e/http/encode/duration/main.test.ts(53,45): error TS2339: Property 'default_' does not exist on type 'PropertyClient'.
Error: test/e2e/http/encode/duration/main.test.ts(59,45): error TS2339: Property 'iso8601' does not exist on type 'PropertyClient'.
Error: test/e2e/http/encode/duration/main.test.ts(71,45): error TS2339: Property 'floatSeconds' does not exist on type 'PropertyClient'.
Error: test/e2e/http/encode/duration/main.test.ts(77,45): error TS2339: Property 'float64Seconds' does not exist on type 'PropertyClient'.
Error: test/e2e/http/encode/duration/main.test.ts(83,45): error TS2339: Property 'floatSecondsArray' does not exist on type 'PropertyClient'.
Error: test/e2e/http/encode/duration/main.test.ts(97,26): error TS2339: Property 'default_' does not exist on type 'HeaderClient'.
Error: test/e2e/http/encode/duration/main.test.ts(102,26): error TS2339: Property 'iso8601' does not exist on type 'HeaderClient'.
Error: test/e2e/http/encode/duration/main.test.ts(107,26): error TS2339: Property 'iso8601Array' does not exist on type 'HeaderClient'.
Error: test/e2e/http/encode/duration/main.test.ts(117,26): error TS2339: Property 'floatSeconds' does not exist on type 'HeaderClient'.
Error: test/e2e/http/encode/duration/main.test.ts(122,26): error TS2339: Property 'float64Seconds' does not exist on type 'HeaderClient'.

@copilot

…y ops @post Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

Copilot · 2026-06-01T22:50:34Z

Error: test/e2e/http/encode/duration/main.test.ts(13,25): error TS2339: Property 'default_' does not exist on type 'QueryClient'.
Error: test/e2e/http/encode/duration/main.test.ts(18,25): error TS233...

Fixed. The failure was a client-name collision: the Lossy namespace nested sub-namespaces named Query/Property/Header, and the http-client-js emitter derives client names from the namespace leaf name, so the duplicate QueryClient/PropertyClient/HeaderClient exports overwrote the originals (leaving only the lossy ops). I flattened Lossy into a single namespace with distinct operation names (queryInt32Seconds, propertyInt32Seconds, headerInt32Seconds, plus the milliseconds variants) so it generates one LossyClient and the existing clients keep all their operations. I also added @post to the lossy property ops so the endpoint method matches the mock. Regenerated spec-summary.md; validate-scenarios, validate-mock-apis, and the client/server knock all pass.

timotheeguerin · 2026-06-02T12:23:46Z

+    The client must serialize the value as an integer (not a floating point number such as `36.25`), discarding the sub-second precision.
+    Because emitters may floor, round, or ceil when discarding that precision, the expected query parameter is `input=36` or `input=37`.
+    """)
+  op queryInt32Seconds(


I am not sure we really need for header, property, query, etc.

I think we should just need 2 tests

interface Lossy { op intSeconds( @query @encode(DurationKnownEncoding.seconds, int32) input: duration ): void; op intMilliseconds( @query @encode(DurationKnownEncoding.milliseconds, int32) input: duration ): void; }

with the http route matching

Initial plan

f1ccfbe

Copilot AI assigned Copilot and JoshLove-msft May 29, 2026

Copilot started work on behalf of JoshLove-msft May 29, 2026 02:15 View session

Copilot AI linked an issue May 29, 2026 that may be closed by this pull request

Add Spector Case for Serializing Duration encoded as integer #10833

Open

Add fractional duration int32-seconds spector scenarios

fa48c47

Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

microsoft-github-policy-service Bot added the lib:http-specs For issues/prs related to the @typespec/http-specs package label May 29, 2026

Copilot AI changed the title ~~[WIP] Add Spector case for serializing duration as integer~~ Add Spector case for serializing fractional duration encoded as integer May 29, 2026

Copilot finished work on behalf of JoshLove-msft May 29, 2026 02:28

Copilot AI requested a review from JoshLove-msft May 29, 2026 02:28

timotheeguerin reviewed Jun 1, 2026

View reviewed changes

Copilot started work on behalf of JoshLove-msft June 1, 2026 18:20 View session

Clarify fractional duration scenarios validate integer type, not roun…

9aabc3f

…ding Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

Copilot finished work on behalf of JoshLove-msft June 1, 2026 18:26

Copilot started work on behalf of JoshLove-msft June 1, 2026 18:29 View session

Use 36.25s duration so rounding/truncating both yield 36, assert exac…

fa87ef4

…t value Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

Copilot finished work on behalf of JoshLove-msft June 1, 2026 18:35

JoshLove-msft marked this pull request as ready for review June 1, 2026 18:42

JoshLove-msft requested review from bterlson, catalinaperalta, iscai-msft, markcowl and witemple-msft as code owners June 1, 2026 18:42

Copilot started work on behalf of JoshLove-msft June 1, 2026 18:53 View session

Add chronus changeset for http-specs fractional duration scenarios

b9a6161

Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

Copilot finished work on behalf of JoshLove-msft June 1, 2026 18:59

Copilot started work on behalf of JoshLove-msft June 1, 2026 19:33 View session

Clarify lossy encode scenario in duration test docs

7a11acd

Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

Copilot finished work on behalf of JoshLove-msft June 1, 2026 19:37

timotheeguerin reviewed Jun 1, 2026

View reviewed changes

Copilot started work on behalf of JoshLove-msft June 1, 2026 19:52 View session

Move duration lossy-encode tests to dedicated Lossy category, add mil…

bd267b1

…liseconds, allow ceil Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

Copilot AI changed the title ~~Add Spector case for serializing fractional duration encoded as integer~~ Add Spector cases for serializing lossy duration encodings as integers Jun 1, 2026

Copilot finished work on behalf of JoshLove-msft June 1, 2026 20:03

Copilot started work on behalf of JoshLove-msft June 1, 2026 22:40 View session

Flatten Lossy namespace to avoid client name collisions; mark propert…

a96701d

…y ops @post Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

Copilot finished work on behalf of JoshLove-msft June 1, 2026 22:51

timotheeguerin reviewed Jun 2, 2026

View reviewed changes

Conversation

Copilot AI commented May 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes (packages/http-specs/specs/encode/duration/)

Note

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jun 1, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pkg-pr-new Bot commented Jun 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JoshLove-msft commented Jun 1, 2026

Uh oh!

Copilot AI commented Jun 1, 2026

Uh oh!

azure-sdk-automation Bot commented Jun 1, 2026

Uh oh!

JoshLove-msft commented Jun 1, 2026

Uh oh!

Copilot AI commented Jun 1, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JoshLove-msft commented Jun 1, 2026

Uh oh!

Copilot AI commented Jun 1, 2026

Uh oh!

JoshLove-msft commented Jun 1, 2026

Uh oh!

Copilot AI commented Jun 1, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Copilot AI commented May 29, 2026 •

edited

Loading

Changes (`packages/http-specs/specs/encode/duration/`)

pkg-pr-new Bot commented Jun 1, 2026 •

edited

Loading