Controlling for pymupdf version in test_pdf_reader_match_doc_details VCR
#538
Conversation
dosubot
bot
added
the
size:S
| @@ -45,7 +47,6 @@ def fixture_vcr_config() -> dict[str, Any]: | |||
| ANTHROPIC_API_KEY_HEADER, | |||
| "cookie", | |||
| ], | |||
| "match_on": ["method", "host", "path", "query"], | |||
There was a problem hiding this comment.
@mskarlin do you know why we overrode the default match_on here? The default has 6 entries, why did we down-specify to 4?
There was a problem hiding this comment.
Huge win here lol, a latent bug was captured in this
jamesbraza
force-pushed
the
pinning-pymupdf
branch
from
7ceee38
to
c3f32ab
Compare
There was a problem hiding this comment.
It has me slightly concerned that the version of pymupdf is in the name of this cassette
Will it break on the next version?
the others don't seem to have the same
There was a problem hiding this comment.
What happens is when a future dev/Renovate runs uv.lock (and assuming a new pymupdf version is out), CI will break until you regenerate this cassette
You're right that other tests don't have this naming special case, but it's because other tests were unaffected by the pymupdf version
jamesbraza
force-pushed
the
pinning-pymupdf
branch
from
c3f32ab
to
1696135
Compare
As we see in this CI run,
test_pdf_reader_match_doc_detailshas failed again. But it has a VCR, so why was it failing?I traced it to going from
pymupdf==1.24.10topymupdf==1.24.11invalidating the VCR. So we can fix this now-failing test in one of two ways:pymupdfin dev dependenciespymupdfto VCR key for this testIn this PR, I did the folowing:
test_pdf_reader_match_doc_details's VCR name to includepymupdf.__version__in the namematch_onconfiguration from ourconftest, and regenerated all VCR cassettes