15 Replies
Gonna start a thread!
This is odd, what page were you on?
looks like it resolved now.
I think these are just transient errors during your deployment rollouts.
Usually see a few 503s followed by 404s before things come back online
I've been noticing this as well, I'll see if there's something we can tweak in our config to make this better
The 404s might be related to the build system building pages for the first time after a deploy
This is what the web admin was showing though while it was erring.
Ah thanks, that specific error should be resolved now. Bit of a timing mismatch on deploying the backend and frontend... also perhaps a bit of a hint on what we're on next 😮
ha i was hoping so. Was just working on a self-scheduling action this morning.
So yeah, two different issues here! The error in your screenshot shouldn't happen again. The 404s may happen transiently on rebuild, but we can likely make this experience better
I'm sure websockets make this trickier than your typical green/blue strategy accounts for
we do use convex under the hood to power the dashboard views! The websocket protocol didn't have much to do with the error you saw - in this case the new feature UIs were hidden correctly behind a feature flag, but the data loading code was still being called on page load before the related functions were available
Understood. I was referring to the 503/404 issue.
I see those on the websocket reconnection attempts within my app console output
Ah gotcha, thanks for clarifying. 503 on websockets likely has more to do with when we deploy the backend (perhaps related to your conversation with @sujayakar a few days ago) but 404s in the dashboard in these cases is something I'll need to do some more digging on
gotcha. for clarity though, the websocket 404s for about ~30sec after the 503 resolves during post-deploy reconnection routines.
Ohhh, gotcha. The 503s and 404s are both on the websocket connection
yup. i saw a 404 on the web and assumed it was just manifesting in a different way but same underlying issue -- sounds like perhaps there are two distinct 404 problems
Sounds right! The dashboard doesn't redirect if a websocket connection fails, so if you see 404 pages in the dashboard (that weren't legitimately invalid URLs / missing resources), it would be a different issue