The ZIP Opens After a Proxy Download: Are All Export Files Really There?

A market-data export downloads through the proxy, the ZIP opens, and two CSV files are visible. Is the export complete? Not if the approved job expected three files, or if two entries share a name and your importer silently picks one.

This guide proposes an acceptance workflow for small, owned or explicitly authorized ZIP exports. It separates downloaded bytes, readable archive structure, expected members and business content. It is not a report of executed tests or a guarantee that every archive format or compression method works with a particular proxy.

1. Define the export manifest independently

Before requesting the export, prepare an approved manifest containing a fixture or job ID, expected member names, permitted directories, per-file content expectations and whether extra files are allowed. For an owned deterministic fixture, include exact member-byte digests and sizes. Do not build the expected list by simply listing the received archive.

Use a harmless three-file fixture: one small CSV, one small JSON document and one small image, each with a known marker or digest. Treat the chosen names and contents as test data, not as a claim that a destination uses those names. Define whether an empty export is valid; a readable empty ZIP is not automatically a failure or a success.

For changing production exports, use a documented server-provided manifest tied to the same job or snapshot where available. If there is no independent completeness reference, report the checks you can perform and leave business completeness unproven. Do not invent an expected count from a previous day's export.

2. Finish the download into a separate artifact

1. Use a fixed client and an approved baseline route to retrieve the owned fixture with bounded requests and time.
2. Check the final response identity and actual artifact. A login page saved with a .zip suffix is not an archive export.
3. Write to a new per-attempt staging file. Record byte count, job ID and a digest of the representation actually saved.
4. Repeat through the approved proxy route using the same deterministic fixture version.
5. Keep attempts separate; do not append a full retry to an earlier partial file or mix members extracted from different jobs.

The 98IP dynamic residential IP page is relevant when selecting a product for authorized export-route checks. Confirm current connection methods and account options through the API configuration page. These pages do not define the destination's export manifest or guarantee a specific archive decoder.

Compare whole-archive digests only when the fixture contract makes archive bytes deterministic. Two valid archives with identical member contents can differ in metadata or packaging. A different outer digest is a reason to inspect the declared layer, not immediate proof of proxy corruption.

3. Inventory members before importing them

Use an archive library to enumerate every entry, preserving names and duplicates. Python's zipfile documentation provides member-information APIs and notes that archives can contain duplicate names. Do not reduce the inventory to a name-keyed map before counting duplicates, since that can erase the very fault under test.

Compare the received inventory against the independent manifest. Report missing, unexpected and repeated members separately. Define whether directory entries count; three file members plus a directory is not the same as four business files. Preserve exact names until an explicitly approved normalization rule is applied.

For a fixture requiring one CSV, one JSON file and one image, three entries consisting of two CSV copies and one JSON file still fail completeness. A total count alone cannot prove the required set is present.

4. Check readability and payload identity separately

Read each approved small fixture member fully with a compatible decoder and verify its own digest or marker. Record archive-open failure, member-read failure and unsupported compression separately. A decoder limitation does not establish that network bytes changed.

Python documents testzip() as checking member CRCs and file headers. That check is not an independent proof that every expected file exists, nor does an archive's self-contained CRC establish that its business contents are the intended snapshot. Keep archive consistency and manifest correctness as different columns.

After the bytes match, validate each fixture's business contract: the CSV's expected IDs, the JSON's schema and marker, and the image's expected digest. A well-formed but stale CSV is not corrected merely by a successful archive check. Tie all expected content to the same fixture or snapshot ID.

5. Bound processing and publish output once

Set limits for downloaded bytes, entry count, declared uncompressed sizes, actual decompressed bytes and total processing time before reading members. Enforce actual streamed limits rather than trusting metadata alone. For this acceptance test, small synthetic archives are sufficient; deliberately huge archives are unnecessary.

Inspect and read members without extracting them into a shared working folder. If extraction is part of the real importer, use an isolated destination, approved relative names and explicit collision handling. Reject unexpected paths or types under the import contract. Do not let a repeated name overwrite a prior member silently.

Stage derived output until the complete acceptance gate passes. If partial imports are intentionally supported, record the partial state and downstream consumers explicitly. Never describe a provisional two-file import as a completed three-file export.

6. Run a small failure and recovery matrix

• Approved fixture: every expected member appears once and matches its content contract.
• Readable archive missing one member: the independent manifest detects the gap.
• Duplicate name with different content: inventory flags ambiguity before import or overwrite.
• Truncated archive or damaged member: structure or member reading fails, with no completed output.
• Readable archive containing stale fixture content: payload or snapshot checks reject it despite internal consistency.
• Budget exceeded or decoder unsupported: stop with an explicit incomplete or unsupported result, rather than silently skipping the member.

These are proposed cases, not measured outcomes. After correcting a controlled fault, obtain or reuse the exact authorized fixture artifact as appropriate, validate it from a clean staging state and commit output once. For a live job, follow the destination's recovery policy and do not assume a newly generated export is the same snapshot.

FAQ and completion checklist

Does opening the ZIP prove completion? No. Required member identities and contents need an independent reference.

Does an outer digest difference prove the proxy changed data? Only a same-artifact comparison supports that question; nondeterministic packaging needs member-level evidence.

• The manifest is independent and tied to one job or fixture.
• Missing, extra and duplicate members are distinct outcomes.
• Structure, member readability and business content each pass.
• Archive metadata and actual processing limits are enforced.
• Retries and derived output never mix attempts.
• Use authorized endpoints and synthetic files; redact credentials, signed links and personal export contents from reports.