Skip to content

feat: Tango API 5.11.0 parity with tango-python 1.18.0 - #26

Merged
vdavez merged 2 commits into
mainfrom
feat/api-5.11.0-catchup
Oct 19, 2026
Merged

vdavez merged 2 commits into
mainfrom
feat/api-5.11.0-catchup

Conversation

@makegov-mark

@makegov-mark makegov-mark Bot commented Oct 19, 2026 •

Copy link
Copy Markdown
Contributor

What

Brings the Node SDK to parity with tango-python 1.18.1 against Tango API 5.11.0.

Stacked on #25 → #21 → #22 → #23. This branch contains those four PRs' commits, so until they merge its diff against main includes them; the catch-up itself is the last commit. Merge it after #23.

  • Re-vendors contracts/filter_shape_contract.json at Tango API 5.11.0 and regenerates src/shapes/generatedOverlay.ts.
  • obligations_by_fiscal_year(fiscal_year, obligated) expand on contracts, IDVs, OTAs and OT IDVs: a new FiscalYearObligation model type and registered schema (fiscal_year int, obligated decimal), on CONTRACT_SCHEMA, IDV_SCHEMA, OTA_SCHEMA and OTIDV_SCHEMA, and on the Contract and IDV model interfaces.
  • attachments(extraction_status) on opportunities and notices, typed on OpportunityAttachment.
  • commercial_item_acquisition_procedures typed on ListContractsOptions and ListIdvsOptions (so also listIdvAwards() / listIdvChildIdvs()), not on OTAs or OT IDVs (Tango API 5.10.0).
  • PaginatedResponse.countType ("exact" / "approximate" / null) from each response's own X-Results-CountType header. The HTTP client stamps the parsed list body under a symbol key, which survives the object spreads the list methods do and stays out of JSON, so concurrent calls never see each other's value.
  • TangoAPIError for a non-2xx status with no dedicated error class now ends its message with the server's reason (API request failed with status 403: <reason>), read from detail, or error/message/detail on a structured body, flat or nested under detail (parity with tango-python 1.18.1). The parsed body stays on responseData; non-JSON bodies keep the bare message.
  • Docs: pipe-joined UEIs on recipient_uei / uei, the new expand and filter, countType, and the Federal Register and eBuy alert query types.

Parity notes

  • On the shaped methods, the client reads a null nested list as [] (existing behavior for every nested list), so the API's null for obligations_by_fiscal_year on IDVs arrives as [], where tango-python returns None. Changing that globally would change every nested list, so it is documented rather than special-cased.
  • The IDV pagination cursor bug fixed in tango-python 1.12.0 does not exist here; tests now pin cursor on listIdvs, listIdvAwards, listIdvChildIdvs and listIdvTransactions.

Testing

  • npm run lint, npm run typecheck, npm run build, npx vitest run (562 tests), npm run check-conformance, npm run check-shape-coverage, and the overlay regeneration check, all clean locally.
  • Error-reason cases in tests/unit/utils.http.test.ts: a JSON body with a reason, a tier gate's reason flat and nested, a JSON body without one, and a non-JSON body.
  • New tests/unit/client.obligations-by-fiscal-year.test.ts and tests/unit/client.count-type.test.ts; additions to client.shape-parity, client.typed-filters and shapes.schema.parity.
  • The extraction_status cases fail against the pre-5.11.0 overlay, so they test the re-vendor.

🤖 Generated with Claude Code

vdavez and others added 2 commits October 19, 2026 14:51
Re-vendors the API contract at Tango API 5.11.0 and regenerates the shape overlay.
Contracts, IDVs, OTAs and OT IDVs accept the `obligations_by_fiscal_year(fiscal_year, obligated)` expand, with a new `FiscalYearObligation` type and schema.
Opportunities and notices accept `attachments(extraction_status)`.
`listContracts()` and `listIdvs()` type the `commercial_item_acquisition_procedures` filter (Tango API 5.10.0); OTAs and OT IDVs do not, because the API does not offer it there.
`PaginatedResponse.countType` reports whether `count` is exact or approximate, read from each response's own `X-Results-CountType` header.
Documents pipe-joined UEIs on `recipient_uei` / `uei`, and that Federal Register and eBuy alerts are alertable query types.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A non-2xx response with no dedicated error class threw `TangoAPIError("API request failed with status 403")`, so the API's explanation was only reachable through `responseData`. The message now ends with the reason the API sent (`detail`, or `error`/`message`/`detail` on a structured body, flat or nested under `detail`), matching tango-python 1.18.1. Non-JSON bodies keep the bare message.

Also moves `COUNT_TYPE_KEY` above the `parseRetryAfter` doc comment it had been inserted under, so the function gets its doc back.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@vdavez
vdavez force-pushed the feat/api-5.11.0-catchup branch from 47253e9 to 18b4b2c Compare October 19, 2026 19:51
@vdavez
vdavez marked this pull request as ready for review October 19, 2026 19:51
@vdavez
vdavez merged commit 6d43b3c into main Oct 19, 2026
7 checks passed
@vdavez
vdavez deleted the feat/api-5.11.0-catchup branch October 19, 2026 20:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant