Skip to content

fix(dataset): compare on-the-wire bytes so gzip responses aren't flag…#17

Merged
ethan-scitix merged 2 commits into
scitix:mainfrom
Mea1Ma:fix/url-gzip-truncation
Jun 29, 2026
Merged

fix(dataset): compare on-the-wire bytes so gzip responses aren't flag…#17
ethan-scitix merged 2 commits into
scitix:mainfrom
Mea1Ma:fix/url-gzip-truncation

Conversation

@Mea1Ma

@Mea1Ma Mea1Ma commented Jun 28, 2026

Copy link
Copy Markdown
Contributor

Type

  • fix — bug fix or alignment correction

Summary

  • url: gzip truncation fix — the download verifier compared bytes
    written against Content-Length, but when the server sends
    Content-Encoding: gzip, Content-Length is the compressed size while the
    decoded body is larger, so valid downloads were falsely flagged as truncated.
    Now compares against num_bytes_downloaded (on-the-wire bytes).

Related Issues

Test Plan

Automated

  • Lint/format clean (ruff check && ruff format --check)
  • Type check clean (ty check)
  • Unit tests pass (pdm run pytest)

Checklist

Required (all PRs)

  • PR title follows conventional format (type(scope): description)
  • No internal paths, credentials, or personal info in committed files
  • AI-generated code has AI-Generated Code - <model> (<provider>) in module docstring
  • No new upper-layer dependencies added to core/
  • Deleted code verified — no remaining call sites depend on it

@ethan-scitix

Copy link
Copy Markdown
Collaborator

Heads-up: I'm pushing two small maintainer-edit cleanups directly onto this branch (thanks for leaving "Allow edits by maintainers" on). The gzip fix itself is correct and approved — these are just polish:

  1. Reword the size-check error. The guard rejects any num_bytes_downloaded != Content-Length mismatch — including an over-read (received > expected) — so "truncated download" was a slight misnomer for that direction. Changed to "size mismatch on download from …"; the test match= is updated to suit.

  2. Pin the gzip test docstring to the file RULER actually downloads. test_download_accepts_compressed_response cited train-v2.0.json (Content-Length=9551051, ~42MB), but feat(ruler): add RULER long-context benchmark (datasets + tasks) #11 fetches dev-v2.0.json. Both are gzip-served; I verified the dev figures (Content-Length=800683, decoded ~4.4MB) so the Regression: note now describes the real download path.

One follow-up for #11: it currently carries a copy of this same docstring with the old train-v2.0.json wording. Once this lands, please rebase #11 so it picks up the dev-v2.0.json correction (otherwise it'll reintroduce the stale numbers).

Mea1Ma and others added 2 commits June 29, 2026 16:59
…ged as truncated downloads

The truncation check in url.py compared bytes *written to disk* against
Content-Length. That breaks for Content-Encoding responses: when the
server sends gzip, Content-Length is the compressed size while
iter_bytes() yields the larger decompressed body, so written bytes
always exceed Content-Length and the download is falsely rejected.

Compare r.num_bytes_downloaded (raw on-the-wire bytes, before httpx
decompresses) against Content-Length instead — the two are now measured
on the same, compressed scale, so gzip-served files pass while genuinely
truncated transfers still fail.

Regression: SQuAD's train-v2.0.json is gzip-served; Content-Length=9551051
but the decoded body is ~42MB, which the old written-bytes check rejected.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…s dev-v2.0.json source

The byte-count guard rejects any num_bytes_downloaded != Content-Length
mismatch, including an over-read, so "truncated download" was a misnomer
for that direction — reword to "size mismatch".

Also align test_download_accepts_compressed_response's docstring to the
file RULER actually fetches (dev-v2.0.json: Content-Length=800683,
decoded ~4.4MB) instead of train-v2.0.json, so the Regression note
describes the real download path.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@ethan-scitix
ethan-scitix force-pushed the fix/url-gzip-truncation branch from b0bd8a1 to 7b96904 Compare June 29, 2026 08:59
@ethan-scitix
ethan-scitix merged commit e747f31 into scitix:main Jun 29, 2026
9 checks passed
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.

2 participants