Fix PATCH /transactions success response code: 209 -> 200#34
Merged
bradymholt merged 1 commit intoJul 15, 2026
Merged
Conversation
The updateTransactions (PATCH /transactions) operation's spec declared its success response as HTTP 209, but the real API returns 200. Because 200 didn't match the generated _response_types_map, every real, successful call to update_transactions()/_with_http_info()/ _without_preload_content() silently deserialized to data=None instead of a SaveTransactionsResponse -- the mutation had already applied server-side, but callers had no way to observe the result and calling code that assumed a non-exception response is parseable (e.g. response.data.transactions) would crash with an AttributeError on a successful request. Fixes open_api_spec.yaml, the three generated TransactionsApi.update_transactions* methods, and the corresponding docs table entry. Adds a regression test that calls the real generated update_transactions_with_http_info() (not a hand-supplied response_types_map) against a mocked 200 response, confirmed to fail against the pre-fix code and pass after. Found via a downstream MCP server project that calls this endpoint for its "update multiple transactions" write tool.
6 tasks
bradymholt
approved these changes
Jul 15, 2026
bradymholt
left a comment
bradymholt
left a comment
Member
There was a problem hiding this comment.
Changes look good. Thanks for the fix! I'll get the fix made to our official OpenAPI spec as well so that regenerations of the client will continue work correctly.
|
The changes in this PR were just released in 4.3.0 🎉. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #33.
What's wrong
updateTransactions(PATCH /transactions) declares its success response as HTTP209inopen_api_spec.yaml, but the real API returns200. Since the generated_response_types_mapinTransactionsApi.update_transactions()/_with_http_info()/_without_preload_content()only has an entry for'209', every real successful call silently deserializes todata=Noneinstead of raising or returning the parsedSaveTransactionsResponse-- see #33 for the full repro and impact (a caller checkingresponse.dataafter a non-exception call gets anAttributeError, even though the mutation already applied server-side).Every other
TransactionsApiendpoint has a correctly-mapped status code; this is isolated to the one batch-update endpoint.What this changes
open_api_spec.yaml:"209"->"200"forupdateTransactions's success response (the only"209"in the whole spec).ynab/api/transactions_api.py: the three matching_response_types_mapentries (update_transactions,update_transactions_with_http_info,update_transactions_without_preload_content).docs/TransactionsApi.md: the corresponding status-code table row.tests/test_response_deserialize.py: a new regression test that calls the real generatedupdate_transactions_with_http_info()(not a hand-suppliedresponse_types_map, so it actually exercises the embedded map) against a mocked200response and assertsresult.data is not None. I verified this test fails against the pre-fix code (result.dataisNone) and passes after the fix.I don't have
openapi-generatoravailable locally, so this is a precise hand-patch of the single changed value rather than a full regenerate -- following the same pattern as #3.docs/, spec, and generated code all agree, and the full existing suite (161 tests) plus the new one (162 total) pass.One thing worth flagging for maintainers:
scripts/generate.shre-downloadsopen_api_spec.yamlfresh fromhttps://api.ynab.com/papi/open_api_spec.yamlon every regen, so this fix could get silently reverted by the nextGenerate from server specPR unless the same209->200correction also lands in YNAB's canonical spec. I don't have visibility into that system, so noted in #33 in case it needs a separate internal escalation.Testing