[miniflare] fix: make sure the magic proxy can handle multiple parallel R2 stream reads

[dario-piotrowicz]

What this PR solves / how to test

Currently trying to read multiple R2 streams in parallel (via Promise.all for example)
generates a deadlock which prevents any of the target streams to be read, this is caused
by the magic proxy underlying implementation only allowing a single HTTP connection to the
workerd process at a time.

This PR fixes such issue by instead allowing any number of parallel HTTP connections at the same time.

Fixes #5360

Author has addressed the following

• Tests
  • TODO (before merge)
  • Included
  • Not necessary because:
• Changeset (Changeset guidelines)
  • TODO (before merge)
  • Included
  • Not necessary because:
• Public documentation
  • TODO (before merge)
  • Cloudflare docs PR(s): https://github.com/cloudflare/cloudflare-docs/pull/...
  • Not necessary because: this is a bug fix

[changeset-bot]

🦋 Changeset detected

Latest commit: e808dd9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
miniflare	Patch
@cloudflare/pages-shared	Patch
@cloudflare/vitest-pool-workers	Patch
wrangler	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

A wrangler prerelease is available for testing. You can install this latest build in your project with:

npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/8538794734/npm-package-wrangler-5491

You can reference the automatically updated head of this PR with:

npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/5491/npm-package-wrangler-5491

Or you can use npx with this latest build directly:

npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/8538794734/npm-package-wrangler-5491 dev path/to/script.js

Additional artifacts:

npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/8538794734/npm-package-create-cloudflare-5491 --no-auto-update

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/8538794734/npm-package-cloudflare-kv-asset-handler-5491

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/8538794734/npm-package-miniflare-5491

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/8538794734/npm-package-cloudflare-pages-shared-5491

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/8538794734/npm-package-cloudflare-vitest-pool-workers-5491

Note that these links will no longer work once the GitHub Actions artifact expires.

---

wrangler@3.44.0 includes the following runtime dependencies:

Package	Constraint	Resolved
miniflare	workspace:*	3.20240329.0
workerd	1.20240329.0	1.20240329.0
workerd --version	1.20240329.0	2024-03-29

Please ensure constraints are pinned, and miniflare/workerd minor versions match.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.37%. Comparing base (bd00dc8) to head (e808dd9).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5491      +/-   ##
==========================================
+ Coverage   72.27%   72.37%   +0.09%     
==========================================
  Files         331      331              
  Lines       17000    17000              
  Branches     4327     4327              
==========================================
+ Hits        12287    12303      +16     
+ Misses       4713     4697      -16     

see 8 files with indirect coverage changes

[RamIdeas]

LGTM

I would wait for @mrbbot to review before merging – there may have been a reason to limit to 1 HTTP connection or not

[dario-piotrowicz]

LGTM

I would wait for @mrbbot to review before merging – there may have been a reason to limit to 1 HTTP connection or not

@mrbbot came up with the solution, so hopefully he should be cool with it 😁

but yeah I'm happy to wait for his approval 🙂

[mrbbot]

Looks good! ✅ I've made a couple suggestions to the changeset.

Dario and I paired on fixing this. To elaborate on this issue here, attempting to access R2ObjectBody#body causes a synchronous network request via fetch-sync.ts to get the body ReadableStream. Whilst the stream itself is returned synchronously, the chunks are not. When another get() request is sent, and R2ObjectBody#body is accessed again, this Atomics.wait() call is hit:

workers-sdk/packages/miniflare/src/plugins/core/proxy/fetch-sync.ts

Line 130 in bd00dc8

Atomics.wait(this.#notifyHandle, /* index */ 0, /* value */ 0);

This blocks the main thread that the stream from the 1st request has been transferred to, preventing it from being read. Because we were using a single-connection Client, undici had to wait for the response to be read before sending the next request. This meant the Atomics.wait() call never unblocked, as we were blocking the response being read, so had cyclic dependencies and deadlock.