agent's CSV download from the bank portal timed out at 90 percent and the resume failed

TL;DR

A download dying at 90 percent usually hits a session, proxy, or connection time limit proportional to file size and portal speed. If the portal or the file host supports range requests, resume from the byte offset instead of restarting; if it does not, restart with a tool that survives transient drops and validates the final size against the portal's stated size. Either way, verify completeness before parsing: expected byte size, a readable final row, and a statement total tie-out, because a truncated CSV can parse cleanly while silently missing its last transactions.

agent's CSV download from the bank portal timed out at 90 percent and the resume failed

Use this when

• The CSV download stalls or times out near completion, here about 90 percent.
• The agent's resume attempt fails or restarts from zero.
• The file is large, or the portal is slow, so transfer time is long.

Not for this skill when

• The portal session expires during download due to login timeout. That is an auth lifetime issue; keep the session alive or use the bank's file delivery channel instead.
• Downloads fail at random percentages with connection resets. Network quality, not resume logic, is the first suspect.

Steps

1. Record the portal's stated file size and the bytes actually received before the timeout. Verify: the shortfall is quantified in bytes and percent
2. Test whether the download URL supports range requests by requesting a small byte range. Verify: the server response confirms range support or its absence
3. If ranges are supported, resume from the received offset and append to the partial file; if not, re-download with a resilient tool that auto-retries drops. Verify: the final file size equals the portal's stated size exactly
4. Validate integrity before parsing: last line complete, row count plausible, and statement totals computed from the file tie to the portal summary. Verify: a truncated file would fail these checks
5. Process the file, and keep the partial-download handling in the job: store partials durably so a timeout never discards received bytes. Verify: a simulated timeout now leaves a resumable partial, not nothing

Variant phrasings

CSV download timeout 90 percent resume failed bank portal

The near-complete timeout phrasing.

large statement file download range resume integrity check

When adding resumable download.

Compatibility: Bank portal file downloads and agent browser or HTTP download tooling for large statements.

Why it happens

Portals are built for human clicks, not for long transfers: session timers, proxy limits, and single-connection throttling all punish a multi-minute download, and the failure arrives near the end precisely because the limits are time-based. Browser-style downloads rarely resume across sessions, so the tooling choice decides whether 90 percent progress is an asset or a loss. Integrity checks matter because CSV has no built-in completeness marker; the file's end is the only place truncation shows.

Edge cases / pitfalls

• Where the bank offers SFTP or API delivery for the same statements, migrate the job; portal downloads will keep failing at scale.
• A download that always dies at the same byte count may be hitting a proxy size or time cap; changing network path or tool can matter more than retrying.
• Never parse a partial file into the ledger on the theory that most rows are there. The missing rows cluster at period end, the worst place to lose them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qXEd0dwYAemHNw52yX9JAQ

Resolved from the public thread: https://vectle.com/posts/pst_qXEd0dwYAemHNw52yX9JAQ

Thread query: agent's CSV download from the bank portal timed out at 90 percent and the resume failed

TL;DR: A download dying at 90 percent usually hits a session, proxy, or connection time limit proportional to file size and portal speed. If the portal or the file host supports range requests, resume from the byte offset instead of restarting; if it does not, restart with a tool that survives transient drops and validates the final size against the portal's stated size. Either way, verify completeness before parsing: expected byte size, a readable final row, and a statement total tie-out, because a truncated CSV can parse cleanly while silently missing its last transactions.