Match request bodies with equivalent datetime timezone notations#3750
Draft
fpighi wants to merge 1 commit into
Draft
Match request bodies with equivalent datetime timezone notations#3750fpighi wants to merge 1 commit into
fpighi wants to merge 1 commit into
Conversation
The Python client serializes tz-aware datetimes via datetime.isoformat(), producing a "+00:00" UTC offset, while recorded cassettes use "Z". Both denote the same instant, but the VCR replay body matcher compared them as differing strings, so replay-only scenarios that send a datetime in the request body (e.g. DORA ListDORADeployments) fail to match their cassette. The matcher also only recognized "text/json", so "application/json" bodies skipped JSON-aware comparison entirely and fell back to a raw byte compare.
fpighi
force-pushed
the
fpighi/python-vcr-datetime-tz-matcher
branch
from
2d1d169 to
a84b26c
Compare
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
1 participant
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.
Motivation
Replay-based BDD scenarios that send a datetime in the request body can fail to match their recorded cassette, even when the request is correct. The Python client serializes timezone-aware datetimes with
datetime.isoformat(), which emits a+00:00UTC offset, while cassettes record the same instant asZ. These are equivalent RFC 3339 representations, but the VCR body matcher compared them as differing strings and reported a body mismatch.This surfaced on the new DORA
ListDORADeployments"date-time timestamps" scenario generated for datadog-api-spec#6101 (generated PR #3746), whosetest / testjobs fail with abody - assertion failure. It is a general gap in the harness rather than anything specific to that endpoint: any replay-only scenario that puts a datetime in the request body is exposed. A contributing factor is that the matcher only treatedtext/jsonas JSON, so the usualapplication/jsonbodies bypassed JSON-aware comparison and fell back to a raw byte compare.Overview of changes
Updates the VCR request-body matcher in the test harness so that it recognizes
application/jsonin addition totext/json, and canonicalizes ISO-8601 datetime strings (normalizing timezone-aware values to UTC) before comparing bodies, so equivalent timezone notations compare equal. Non-datetime strings and JSON numbers are left unchanged, and a body that is not valid JSON falls back to a raw comparison.Validation
Ran the full v1 and v2 replay scenario suites (
RECORD=false): all pass (v2 1330 passed, v1 309 passed, 0 failed). Confirmed the previously-failing DORA date-time scenario now matches its cassette, and that genuinely different request bodies still fail to match.