# Changelog of Parallel Bulk File Downloader – Fast URL Downloads (`automa-flow/parallel-bulk-file-downloader`) Actor

- **URL**: https://apify.com/automa-flow/parallel-bulk-file-downloader/changelog.md
- **Full Actor documentation**: https://apify.com/automa-flow/parallel-bulk-file-downloader.md

## Changelog

### 2026-10-07: File price includes platform usage

#### Pricing

- A stored file is `$0.004` and includes the first 10 MiB. Each further started 10 MiB is `$0.003` (`stored-10mib`). Platform usage is included in those prices, so there is no separate usage charge on top.
- Failed URLs, retries, redirects and rejected files are still not charged.
- `stored-10mib` is charged only when the active Store price lists that event. Until the new price is active, a run charges `file-downloaded` only.
- If the acknowledgement for that size charge is lost, the run stops for a charge check. It does not report the file price as the whole bill.
- The smallest run cap stays `$0.00405`, enough for one small file. A larger file needs room for its size units in `maxTotalChargeUsd`.

### 2026-09-29: Fewer failed runs for long and chained batches

#### Fixes

- If Apify restarts or migrates a run, the run now continues instead of failing.
  Files already stored and charged are reused without another file event, and
  rows already in the Dataset are not added twice. If a charge was in progress
  at that moment, the run checks it against Apify's own charge record and still
  stops for review when Apify cannot confirm it.
- Dataset imports no longer fail when the source Dataset changes while it is
  being read, for example when the upstream Actor is still adding rows or its
  final update arrives a moment late. The rows already read are downloaded, and
  `NEXT_INPUT` covers any rows added later. `RUN_SUMMARY.datasetChangedDuringRead`
  shows when this happened.
- A spending limit too low for even one file no longer produces a failed run.
  Every URL gets a `BUDGET_EXCEEDED` row, and `RETRY_INPUT` is ready for a new
  run with a higher limit.
- Runs that fail because a charge could not be confirmed, or because of an
  internal error, now end with a clear status message and `RUN_SUMMARY`.
  Previously the summary was rejected and the run stopped without explaining why.

### 2026-09-26: More reliable requests and spending checks

#### Fixes

- Spending checks and billing receipts use the effective event prices supplied for your run, including discounts and zero-priced events.
- Compressed HTTP responses are limited while they are decoded, so a small compressed download cannot expand past the response limit in memory.
- Retry-After is treated as the server's minimum wait. If it exceeds the retry budget, the request ends with an explicit failure instead of retrying early.

### 2026-09-26: Dataset imports and resumable batches

#### Features

- Read file URLs from another Actor using `datasetId` and `urlField`, including
  nested fields. Preserve selected `productId`, `sku` and `SKU` values in each
  output row, with the original Dataset ID and row index.
- Process up to 10,000 source rows per batch in bounded pages. `NEXT_INPUT`
  supplies the next range. Pasted and JSON URL lists still support 500 URLs.
- Use `CONTINUE_INPUT` from a stopped run to retry unfinished files. Confirmed
  downloads keep their original storage links and are not charged a second file
  event. Keep earlier run storages and continue from the latest stopped run.
- Uncertain charges and missing previous files stop continuation for review.
  The existing pricing and legacy URL input remain unchanged.

### 2026-09-26: Paste URL lists and retry unsuccessful files

#### Features

- Paste public file URLs one per line using `urlsText`. Blank lines and extra
  spaces are ignored. A non-empty text list takes priority over `urls`; existing
  JSON integrations and custom file names still work when the text field is blank.
- After a batch with failed files, `RUN_SUMMARY` links to `RETRY_INPUT`: ready
  JSON for a new run containing only unsuccessful URLs, with your file names and
  download settings preserved. Successful files are excluded and no new run
  starts automatically. Review permanent errors and set a fresh spending limit.
- Retry input is withheld if a charge has an unknown outcome, pending
  reconciliation. Runs pinned to an older build must switch to the updated build.

### 2026-09-23: More reliable downloads and file names

#### Improvements

- Redirected downloads now share the destination server's concurrency limit.
  Repeated HTTP 429/503 responses also slow requests that are already waiting.
- Files can take their names from `Content-Disposition`, including encoded
  `filename*`. Your explicit `fileName` still takes priority. Without a usable
  header, the final URL supplies the name.

#### Fixes

- Incomplete HTTP 206 responses and HTTP 204/205 responses without a file now
  return `HTTP_ERROR` instead of a successful download. They are not stored as
  files. A valid zero-byte file returned with HTTP 200 still works.
- Malformed redirect URLs return a per-file failure so other downloads can finish.
- `timeoutSeconds` bounds the entire source-download attempt, including DNS,
  redirects and slowly arriving data. Increase it for intentionally slow sources.
  Queue time, retry backoff and storage upload are excluded.

#### Security

- Standard HTTP request logging no longer exposes signed URL query values.
  Dataset URL fields still preserve the original links for retries and provenance.