"errors": Array [
         Object {
           "extensions": Object {
             "originalError": Object {
               "message": "Cannot perform I/O on behalf of a different request. I/O objects (such as streams, request/response bodies, and others) created in the context of one request handler cannot be accessed from a different request's handler. This is a limitation of Cloudflare Workers which allows us to improve overall performance. (I/O type: RefcountedCanceler)",
               "name": "Error",
               "stack": "Error: Cannot perform I/O on behalf of a different request. I/O objects (such as streams, request/response bodies, and others) created in the context of one request handler cannot be accessed from a different request's handler. This is a limitation of Cloudflare Workers which allows us to improve overall performance. (I/O type: RefcountedCanceler)
         at baseExecutor (index.js:82500:28)
         at index.js:83574:101
         at Promise.then (index.js:12222:30)
         at handleMaybePromise (index.js:12200:50)
         at index.js:83574:31
         at meshExecutor (index.js:90040:18)
         at executorWithSourceName (index.js:90019:18)
         at index.js:23723:39
         at Promise.then (index.js:12222:30)
         at DataLoader4.batchExecuteLoadFn [as _batchLoadFn] (index.js:23723:28)",
              },
            },
           "message": "Cannot perform I/O on behalf of a different request. I/O objects (such as streams, request/response bodies, and others) created in the context of one request handler cannot be accessed from a different request's handler. This is a limitation of Cloudflare Workers which allows us to improve overall performance. (I/O type: RefcountedCanceler)",
           "path": Array [
             "validateContactInformation",
           ],
          },
       ],

function isRequestAccessible(serverContext) {
    try {
        return !!serverContext?.request;
    }
    catch {
        return false;
    }
}

 // Is input a container object over Request?
        if (isRequestAccessible(input)) {
            // Is it FetchEvent?
            if (isFetchEvent(input)) {
                return handleEvent(input, ...maybeCtx);
            }
            // In this input is also the context
            return handleRequestWithWaitUntil(input.request, input, ...maybeCtx);
        }
        // Or is it Request itself?
        // Then ctx is present and it is the context
        return fetchFn(input, ...maybeCtx);

    const fetchFn = (input, ...maybeCtx) => {
        if (typeof input === 'string' || 'href' in input) {
            const [initOrCtx, ...restOfCtx] = maybeCtx;
            if (isRequestInit(initOrCtx)) {
                const request = new fetchAPI.Request(input, initOrCtx);
                const res$ = handleRequestWithWaitUntil(request, ...restOfCtx);
                return handleAbortSignalAndPromiseResponse(res$, initOrCtx?.signal);
            }
            const request = new fetchAPI.Request(input);
            return handleRequestWithWaitUntil(request, ...maybeCtx);
        }
        const res$ = handleRequestWithWaitUntil(input, ...maybeCtx);
        return handleAbortSignalAndPromiseResponse(res$, input._signal);
    };
``
The input is not a string or a href so `handleRequestWithWaitUntil` is called directly.

**Differences so far:**

Original version input is itself a Request object. New version input has a key called request which is a Request object

Original version in genericRequest handler isRequestAccessible returns false so `fetchFn` is called. New version `isRequestAccessible` is true so `handlRequestWithWaitUntil` is called directly with input.request as `handleRequestWithWaitUntil` requires a Request object as an argument.

Original version. `fetchFn` also calls `handleRequestWaitUnti`l but with input as in the original version input is the Request object

Original version. `handleAbortSignalAndPromiseresponse `is called additionally to `handleRequestWaitUntil`

 

handleRequestWaitUntil

The console.debug statements have been added to step through the function. The output is the same in both the original updated repos. On both successful and failed requests on the new version.

 

**Remaining difference**

`fetchFn` calls `handleAbortSignalAndPromiseresponseafter` it has called` handleRequestWaitUntil`. Contents of this function are:

This function waits for the response promise to resolve before returning the response - but only if it is a promise.

Logging the original version shows that all request responses are never promises. 

This means the only real difference between original and new version is the nested request object. 

 

**Deploying directly to CloudFlare**
 

To rule out the possibility of these issues only occurring locally the updated worker code was deployed directly the CloudFlare using wrangler deploy

 
Through logs the behaviour was observed to be very similar to what happens locally. Summarised as follows:

**Observed differences**

- Locally the error occurs on all requests after the first request

- Deployed to CloudFlare the same error does eventually occur but after approx 5 - 10 requests. Suggested theory to explain this behaviour is that more concurrent resources are available on CloudFlare which means it takes longer for a new request to hit the same worker thread/instance again.

**Observed similarities**

- The same code executes in the same order when deployed as it does locally

**Additional notable observations**

- When the I/O error occurs the downstream service does not receive an HTTP request. This means that the error occurs outside of the mesh code but before the request leaves CloudFlare - suggesting something is catching the error inside the CloudFlare workers run time

- The error is not a server error. The mesh error catching code is not run, the request runs correctly each time and returns a 200 status. It is just that the response payload contains the error message