Yes, the requests are simply not
Yes, the requests are simply not connecting from either outside w/ Websockets or inside with RPC
19 Replies
Unknown User•2mo ago
Message Not Public
Sign In & Join Server To View
It's only happening with this specific DO
Unknown User•2mo ago
Message Not Public
Sign In & Join Server To View
I send you a DM already
sorry
@Tobias if I sent you an HTTP header, could you add that to a request so that we can get a trace?
(from the DO team)
bit difficult to reproduce that, i'm now pretty sure it's caused by a lot of load by some kind of "message recursion" (in my code), but CF should be blocking at some point and not hanging (it already did)
+ i can't really change something in the client code that quickly since it's all native apps (deployed in a restaurant on 10+ embedded devices lol)
i can send you a request ID when it first happened
Let me share what we are seeing on our side...
Looks like a WebSocket connection was established at 17:43... Then we get a few more invocations (RPC or HTTP) all successful until we see two requests cancelled at 17:46. There are two WebSocket messages which are sent before the requests are cancelled.
A trace would be helpful because we can see what is happening when you say it is unresponsive, but from our end it looks like nothing is actually happening...
This was the confusing part to me as well, I was looking through observability and nothing was visible.
The client called me a few minutes later and then were saying "nothing works", I immediately checked Observability - nothing. Then used a mounted Outerbase instance which uses the RPC connection - infinitely loading with a pending request.
I deployed a new version, this reset the DO and everything was back to normal.
For example, "939149b06c18fba1" is a request ID with a RPC connection to the DO, and it has a wall time of 400k ms
It's worth mentioning that your DO dropped the server side of the WebSocket connection at 17:45. When you say the DO was not responding was that to WebSocket messages? Could you have been sending them on a closed pipe?
At that point any new connections, no matter if websocket or RPC were failing
I deployed a new version, this reset the DO and everything was back to normal.When was this?
this was deploy 6f6bc01d-29f4-44c7-aa19-8a4846182203, around 18:15
Okay. I'll share this information with oncall. Thanks for the info.
Thank you
Was there ever any conclusion with this case? I have something that appears fairly similar, in this thread: https://discord.com/channels/595317990191398933/773219443911819284/1369400409386651670
I have not received an answer yet to my ticket, but I also downgraded its priority to normal, since in my case it was most certainly caused by an overload due to my code.
Stranglely enough, my problem was also resolved by deploying a new version of the worker containing the DO, only added a console.log statement, so it should have been something else than an implementation issue in our code