[MarketDataDev03]

Generated by sdk-auto-sync for API release 1.4.0 (commit f19c2d4).

Changes in the API surface

Snapshots 9c18fbb1f58e → 72b3d15f59ad:

~ GET /v1/options/chain/{underlying}/ ?dte: string  (was integer)

What the agent did

tests: Only the test file was touched, as required.

Summary

The API delta changes ?dte= on GET /v1/options/chain/{underlying}/ from integer to string, mirroring the existing ?strike= parameter which already accepts a dashed range as a string (StrikeFilter.range). I added three tests to src/test/java/com/marketdata/sdk/OptionsResourceTest.java that specify the new ExpirationFilter.dte(int minDays, int maxDays) range overload, alongside the existing single-value dte(int):

• chainExpirationFilterDteRangeTranslatesToDashedDteParam — asserts ExpirationFilter.dte(30, 60) serializes the chain request query string as ?dte=30-60.
• expirationFilterDteRangeRejectsNegativeMin — asserts dte(-1, 30) throws IllegalArgumentException ("dte must be non-negative").
• expirationFilterDteRangeRejectsMinGreaterThanMax — asserts dte(60, 30) throws IllegalArgumentException ("min must be <= max").

Confirmed gradle test --no-daemon --console=plain fails at compilation (the two-arg dte overload doesn't exist yet), as expected for this tests-only phase. No production code or docs were touched.

implement: All changes fall within src/main/java/**, src/test/java/**, and docs/**, as required. No commits made.

Summary

Implemented ?dte= widening to string on GET /v1/options/chain/{underlying}/ by adding a days-to-expiration range alongside the existing single-value filter:

• ExpirationFilter.DteRange — new sealed-interface variant (minDays, maxDays), added to the permits list.
• ExpirationFilter.dte(int minDays, int maxDays) — new overload of the existing dte factory, validating non-negativity and min <= max (mirrors StrikeFilter.range's validation style).
• OptionsResource.applyExpirationFilter — serializes DteRange as ?dte=min-max (e.g. dte=30-60), matching the dashed-range convention already used for ?strike=.
• docs/options/chain.md — added the new dte(minDays, maxDays) builder call to the request-shape listing.

Fixed one Spotless formatting violation in the phase-1 test (line wrap on the range test) — no assertions were weakened. gradle test and gradle build both pass.

changelog: Added a ### Changed entry under [Unreleased] documenting the new ExpirationFilter.dte(int, int)/DteRange range filter (API 1.4.0's dte param widening to a string), flagged BREAKING with migration guidance for exhaustive switch consumers.

Files

• CHANGELOG.md
• docs/options/chain.md
• src/main/java/com/marketdata/sdk/OptionsResource.java
• src/main/java/com/marketdata/sdk/options/ExpirationFilter.java
• src/test/java/com/marketdata/sdk/OptionsResourceTest.java

Version

Public-surface change computed by the pipeline: major — next version 2.0.0 (from 1.0.0).

• added: ExpirationFilter.dte(int, int) — New static factory overload returning ExpirationFilter.DteRange; validates minDays/maxDays non-negative and minDays <= maxDays, translates to wire form ?dte=min-max. Distinct arity from the existing dte(int) overload, so no overload-resolution conflict for existing callers.
• added: ExpirationFilter.DteRange — New public record type implementing ExpirationFilter, with accessors minDays() and maxDays(); added as a new permitted subtype of the sealed interface.
• changed: ExpirationFilter.permits — Sealed interface's permits list now includes ExpirationFilter.DteRange alongside OnDate, Dte, Between, MonthYear, All. Any consumer code that exhaustively switches over ExpirationFilter (relying on compiler-enforced exhaustiveness) will fail to compile until it adds a DteRange case.

Reviewer notes

• [minor] src/test/java/com/marketdata/sdk/OptionsResourceTest.java — The new expirationFilterDteRangeRejectsNegativeMin test only exercises the minDays < 0 branch of ExpirationFilter.dte(int, int)'s validation. There is no corresponding test for a negative maxDays with a non-negative minDays (e.g. dte(5, -1)), leaving that branch of the minDays < 0 || maxDays < 0 condition unverified.

Job log

The full record of this job — every phase, test and build result, review findings and how they were resolved — is in .sdk-sync/1.4.0-f19c2d4.md on this branch.

---

3 coder run(s) · 2 review(s) · 51 turns · 2,398,386 tokens · US$ 1.43 · item da2a4be2-d8d2-454b-b73f-cf4ff129365b

Agent runs

• coder · claude-haiku-4-5-20251001, claude-sonnet-5 · 950,333 tokens (939,677 in, 10,656 out) · 22 turns · US$ 0.42
• coder · claude-sonnet-5 · 974,788 tokens (970,820 in, 3,968 out) · 15 turns · US$ 0.28
• reviewer · claude-haiku-4-5-20251001, claude-sonnet-5 · 64,892 tokens (56,064 in, 8,828 out) · 2 turns · US$ 0.32
• security · claude-haiku-4-5-20251001, claude-sonnet-5 · 113,651 tokens (112,635 in, 1,016 out) · 4 turns · US$ 0.25
• analyst · claude-haiku-4-5-20251001, claude-sonnet-5 · 76,526 tokens (74,375 in, 2,151 out) · 5 turns · US$ 0.09
• coder · claude-sonnet-5 · 218,196 tokens (217,473 in, 723 out) · 3 turns · US$ 0.06