Skip to content

Raise zip entry cap to 16 GiB - #4

Merged
MiniCodeMonkey merged 1 commit into
masterfrom
fix/zip-entry-cap-16gib
Oct 5, 2026
Merged

MiniCodeMonkey merged 1 commit into
masterfrom
fix/zip-entry-cap-16gib

Conversation

@MiniCodeMonkey

Copy link
Copy Markdown
Member

Why

gb/countrywide (ChopChop source 2900) has failed every run since at least 2026-09-23. AddressBase Core ships as one CSV in a zip, and that entry declares 9,043,535,569 bytes, which is over the 8 GiB per-entry cap from #3:

openaddr.conform.DecompressionError: Refusing to extract AddressBaseCore_FULL_2026-06-01_001.csv - declared size 9043535569 bytes exceeds 2147483648 byte limit, possible zip bomb

(The log shows the old 2 GiB cap because the deployed image predates #3. The 8 GiB cap would still refuse it.)

Change

  • Default MAX_ZIP_ENTRY_BYTES goes from 8 GiB to 16 GiB. BATCH_MACHINE_MAX_ZIP_ENTRY_BYTES still overrides it.
  • The default-limit test now also asserts the AddressBase entry size fits.

Testing

python3 -m unittest openaddr.tests.conform.TestZipDecompressTask in the Docker image: 10 tests pass.

Rollout

Build amd64, push registry.geocod.io/geocodio/batch-machine:latest, docker pull on the proxy host, then re-run source 2900.

https://claude.ai/code/session_01M9dZ4UWYaMwr9e9cwwKpyS

gb/countrywide ships AddressBase Core as a single CSV whose zip entry
declares 9,043,535,569 bytes, over the 8 GiB per-entry cap, so every run
of the source fails. The default cap is now 16 GiB.

Claude-Session: https://claude.ai/code/session_01M9dZ4UWYaMwr9e9cwwKpyS
@MiniCodeMonkey
MiniCodeMonkey merged commit e436bf8 into master Oct 5, 2026
1 check 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.

1 participant