The fact that this was possible definitely made the API a lot cleaner
-
-
I should change the annotation from `#[swirl::background_job]` to `#[really_async]`
2 replies 0 retweets 1 like -
Or maybe `#[asyncer]`? Ooh or `#[there_is_no_await]`
1 reply 0 retweets 1 like -
No gods, No await, Only async
1 reply 0 retweets 3 likes -
Replying to @mgattozzi @Ivshti
Only async and a cron job to page whoever is on call if the jobs aren't running to completion*
1 reply 0 retweets 1 like -
Keep polling, maybe they'll finish
1 reply 0 retweets 1 like -
Replying to @mgattozzi @Ivshti
Ironically that monitor went off for the first time today and that's exactly what happened because the problem was the GitHub outage which was resolved 2 minutes after the page was sent.
1 reply 0 retweets 2 likes -
Lmao
1 reply 0 retweets 0 likes -
Replying to @mgattozzi @Ivshti
Listen that infra hadn't been tested in production yet and this all went down during work hours so as far as I'm concerned GH was just giving us a nice fire drill
1 reply 0 retweets 1 like -
I mean it's great it worked, but I hate when things failed cause somebody else messed up and now people are mad and you didn't do anything wrong. Always hugops though this is never fun
1 reply 0 retweets 0 likes
As far as I know the affected users didn't even notice (in part because of this system. We didn't reject the publish, index eventually gets updated no matter what).
-
-
It's mostly just funny because I've repeatedly said while building all this that the only reason these jobs should ever fail if our tests pass is a GH outage, but we still need to get paged so we can update the status page. And thus https://status.crates.io/incidents/xghhl2kqdftn … was born
0 replies 0 retweets 2 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.