Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

change to using websocket hibernation API #32

Merged
merged 5 commits into from
Feb 28, 2024
Merged

Conversation

koeninger
Copy link
Contributor

No description provided.

@koeninger
Copy link
Contributor Author

ready for review - we definitely shouldn't merge before cloudflare/cloudflare-docs#7872 and an open question when we want to replace the default example after that

@koeninger koeninger changed the title WIP change to using websocket hibernation API, needs testing change to using websocket hibernation API May 11, 2023
// Create our session and add it to the sessions map.
let session = { limiterId, limiter, blockedMessages: [] };
// attach limiterId to the webSocket so it survives hibernation
webSocket.serializeAttachment({ ...webSocket.deserializeAttachment(), limiterId: limiterId.toString() });
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a dumb question but why are we deserializing webSockets attachment here? Considering it was only just accepted as hibernatable I would think deserializeAttachment() would be null, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If someone takes this example and adds more properties to the attachment, and this line was just overwriting whatever was already in the attachment with only the limiterId, then correctness would depend on whether they happened to add the new properties above or below this line.

Seems uglier but safer this way to always add another property to whatever was already in the attachment.

src/chat.mjs Outdated
webSocket.addEventListener("close", closeOrErrorHandler);
webSocket.addEventListener("error", closeOrErrorHandler);
async webSocketError(webSocket, error) {
this.webSocketClose(webSocket)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know why but it feels weird to me that we could call this (maybe because it's a custom event in the runtime and I hadn't thought of it).

Either way, might be better to take the stuff inside of webSocketClose(), put it in another function, and then invoke that function from webSocketClose()/webSocketError(). I'm also not sure what would happen as it stands because code, reason, wasClean aren't being passed in. I guess they'd be treated as undefined, which is probably okay since only webSocket is referenced?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to move it to another function, but if there's some reason people can't manually call handlers, we should probably find out and document it

@broccolihighkicks
Copy link

I get this error: cloudflare/workerd#736

Is the hibernation API ok to use?

@MellowYarker MellowYarker merged commit cf996e0 into master Feb 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants