PR to track down CI failures #501
Conversation
|
Passes locally. |
An additional layer which protects us against edge cases with Zeroizing (objects which don't support it or don't miss it).
|
The most recent commit I believe was a mis-diagnosis on my end (we claim we're re-attempting completed items, we just don't preprocess for them). |
|
The most recent two commits had their CI passed despite the past three commits not supposed to be enacting change. Likely just shows how spotty the setup failures are? |
|
Third run passed https://github.com/serai-dex/serai/actions/runs/7382274375. |
|
It could be a fluke with the re-attempt extension resolving it? |
|
Local run failed. There are no logs of any errors in the message-queue client. The message-queue client seems to be connecting without issue, just never yielding a message. The message-queue logs do note the messages being queued though. I really have no idea what's up. |
|
The message-queue should be rewritten to automatically send messages upon their occurrence. I could work on such a rewrite and see if that happens to fix this? |
|
The recent |
|
There's definitely been mis-diagnoses here. My local logs have "couldn't connect to message-queue server" due to a lookup failure, yet it doesn't seem to retry. On error, it should continue, sleep 5 seconds, and retry... |
Fixes observed CI failures.
This reverts commit 3723530.
|
c0f42ef resolves it. A couple of commits of work I was doing was placed here for my personal convenience, to be clear (the zalloc commit, for instance). |
For some reason, some processors (12.5-25%) aren't deciding to start the key gen. The only potential candidate I have right now is the hyper update performed.