[BUG] File Stash URL returns 400 when passed to Dropbox “Upload Multiple Files” action

**Describe the bug**

While transferring files between two Pipedream-powered MCP tools, files downloaded by the Google Drive **Download File** action were successfully stored in Pipedream File Stash and returned as `PipedreamStashFile` objects with signed `get_url` values.

I then passed those URLs to the Dropbox **Upload Multiple Files** MCP action through its `filesPaths` input. Pipedream processed the first two URLs but received an HTTP 400 response while fetching the third URL from Pipedream’s own File Stash S3 bucket.

The error occurred inside Pipedream’s `getFileStream()` implementation, before Dropbox reported any API request or error.

The affected URL was generated at `2026-07-16T12:22:54Z` with `X-Amz-Expires=1800`. Pipedream attempted to fetch it approximately two minutes later, so it should not have expired.

Relevant error, with the signed URL removed:

```text
Error: Failed to fetch [PIPEDREAM FILE STASH URL]: 400 Bad Request
at getFileStream (.../@pipedream/platform/dist/file-stream.js:23:19)
at async Object.run (.../dropbox/actions/upload-multiple-files/upload-multiple-files.mjs:95:24)
```

The error metadata identified the failed request as:

```text
origin: upstream_api
client: undici
method: GET
host: pipedream-file-stash-production.s3.us-east-1.amazonaws.com
status: 400
```

The stack trace referenced `@pipedream/platform@3.4.0`.

**To Reproduce**

This occurred through Pipedream actions exposed as MCP tools, rather than inside a manually created Pipedream workflow.

1. Connect Google Drive and Dropbox as Pipedream-powered MCP apps.
2. Invoke the Google Drive **Download File** MCP action for multiple MP4 files, supplying a `/tmp/...` destination for each file.
3. Confirm that every action reports a successful download and returns a `PipedreamStashFile` under `$filestash_uploads`.
4. Collect the signed `get_url` value from each returned File Stash object.
5. Invoke the Dropbox **Upload Multiple Files** MCP action with:

* the File Stash URLs in `filesPaths`;
* the desired destination names in `filenames`;
* `autorename: true`;
* `mute: true`;
* `mode: add`.
6. Observe that Pipedream’s file-stream layer returns HTTP 400 while resolving one of the File Stash URLs.

The execution involved ten MP4 files ranging from approximately 22 MB to 58 MB. The failing third file was `30,174,955` bytes, so it was not the largest file in the batch.

All ten Google Drive download actions reported success. The failing File Stash URL belonged to the third downloaded file.

Before using File Stash URLs, I also attempted to pass the original `/tmp/...` paths to the Dropbox action. That failed with:

```text
File not found: /tmp/[filename].mp4
```

This appears to happen because the Google Drive and Dropbox MCP actions execute in separate environments. File Stash URLs therefore appeared to be the available handoff mechanism between the two actions.

**Expected behavior**

Every signed `get_url` returned for a successfully created `PipedreamStashFile` should remain retrievable throughout its declared validity period.

The Dropbox MCP action should be able to resolve every supplied File Stash URL and upload the files.

If the underlying S3 request fails, the execution log should expose the response body or AWS error code—such as `SignatureDoesNotMatch`, `InvalidToken`, or `NoSuchKey`—instead of only returning `400 Bad Request`.

**Screenshots**

I can provide sanitized execution logs if needed. I have not included or screenshotted the complete signed URLs because this issue is public and those URLs contain temporary credentials.

**Additional context**

The overall MCP execution began at approximately `2026-07-16T12:19:56Z`.

The available connected-app tools included:

```text
google-drive-download-file
dropbox-upload-multiple-files
dropbox-upload-file
```

The error came from Pipedream’s File Stash S3 host, not from Google Drive or Dropbox.

The first two File Stash URLs in the same Dropbox action appear to have been retrieved before the third URL returned HTTP 400. All three URLs were generated only seconds apart.

The reported network-call count is consistent with Pipedream resolving the supplied File Stash URLs before starting the Dropbox uploads. No Dropbox API error was reported.

This appears to be an intermittent File Stash object or signed-URL problem rather than:

* a Dropbox API failure;
* an expired URL;
* a general MP4 file-size limit;
* an unsupported URL input, since the action advanced to the third URL;
* or a Google Drive download failure.