WebSocket Serialization Error in Durable Objects RPC

[naporin0624]

When attempting to use DurableObjects RPC with a WebSocket, an error is encountered during serialization. The error message indicates that objects of type WebSocket cannot be serialized. This issue is blocking the use of WebSockets in Durable Objects, which is critical for real-time applications.

Error Message

DOMException {
    code: 25,
    name: 'DataCloneError',
    message: 'Could not serialize object of type "WebSocket". This type does not support serialization.',
    stack: 'DataCloneError: Could not serialize object of type "WebSocket". This type does not support serialization.\n' +
        '    at null.<anonymous> (async file:///home/user/project/.wrangler/tmp/dev-xyz/index.js:5827:15)\n' +
        '    at async dispatch (file:///home/user/project/node_modules/hono/dist/compose.js:29:17)\n' +
        '    at async dispatch (file:///home/user/project/node_modules/hono/dist/compose.js:29:17)\n' +
        '    at null.<anonymous> (async file:///home/user/project/.wrangler/tmp/dev-xyz/index.js:1099:25)\n' +
        '    at async jsonError (file:///home/user/project/node_modules/wrangler/templates/middleware/middleware-miniflare3-json-error.ts:22:10)\n' +
        '    at async drainBody (file:///home/user/project/node_modules/wrangler/templates/middleware/middleware-ensure-req-body-drained.ts:5:10)'
}

Reproduction Steps

1. Set up a Cloudflare Worker with DurableObjects.
2. Implement a Durable Object that utilizes WebSocket.
3. Attempt to serialize and return the WebSocket as part of a response.

Sample Code

Here is a simplified version of the code that reproduces the issue:

export class ShareEventService extends DurableObject<Env["Bindings"]> {
    async create() {
        const pair = new WebSocketPair();
        const client = pair[0];
        const server = pair[1];

        this.ctx.acceptWebSocket(server);

        return new Response(null, { webSocket: client, status: 101 });
    }
}

Expected Behavior

WebSocket objects should be serializable, or there should be a documented alternative method for handling WebSockets within Durable Objects RPC.

Actual Behavior

Serialization fails with a DataCloneError, making it impossible to use WebSockets within Durable Objects RPC.

Additional Information

• wrangler version: 3.61.0
• Durable Objects used for real-time applications

Relevant Code Reference

The issue seems to be related to the following code in workerd:

workerd/src/workerd/jsg/ser.c++

Lines 54 to 63 in bd09e5b

	void Serializer::throwDataCloneErrorForObject(jsg::Lock& js, v8::Local<v8::Object> obj) {
	// The default error that V8 would generate is "#<TypeName> could not be cloned." -- for some
	// reason, it surrounds the type name in "#<>", which seems bizarre? Let's generate a better
	// error.
	auto message = kj::str(
	"Could not serialize object of type \"", obj->GetConstructorName(), "\". This type does "
	"not support serialization.");
	auto exception = js.domException(kj::str("DataCloneError"), kj::mv(message));
	js.throwException(jsg::JsValue(KJ_ASSERT_NONNULL(exception.tryGetHandle(js))));
	}

Suggested Fix

Please provide support for WebSocket serialization or offer a workaround for handling WebSockets in Durable Objects.

Thank you for your attention to this issue.

[MellowYarker]

Please provide support for WebSocket serialization or offer a workaround for handling WebSockets in Durable Objects.

I believe we do plan on supporting serializing WebSockets, but in the meantime you'll need to use fetch() as is shown in our examples.

[naporin0624]

I'm very pleased that serialization for WebSocket might be supported in the future, as it means we won't have to rely on fetch anymore. It would be great if this feature were implemented.

I believe we do plan on supporting serializing WebSockets, but in the meantime you'll need to use fetch() as is shown in our examples.

I understand that we should continue using fetch as usual. I also thought this was the only method. Thank you for your response.

[naporin0624]

@MellowYarker

I understand that, for now, as a workaround, we should use fetch. I am satisfied with this solution, so it's fine to close this issue. However, I think it might be helpful to keep this issue open for anyone who encounters this problem in the future.

What do you think about keeping it open until WebSocket serialization is implemented?

[MellowYarker]

@naporin0624 that sounds reasonable, and thank you for the report.

[jasnell]

Marking this as a feature request /cc @kentonv

[jasnell]

One way that you may be able to workaround this is to wrap the websocket with a ReadableStream and WritableStream pair, which can be shared over the jsrpc connection.

[kentonv]

Yeah this is an unfinished TODO for RPC. I'm not sure exactly when I'll get to it, probably some time in the next few months.

Using fetch() is the appropriate work-around until then.

[04041b]

a feature like this will be really helpful 👍