Although mainly a theoretical possibility, the server may send a candidate with nonces := []. If so, we need to request new nonces before populating the workers.
Although mainly a theoretical possibility, the server may send a candidate with `nonces := []`. If so, we need to request new nonces before populating the workers.
Would it be reasonable for the client to proceed, but on his own randomly picked nonce? The search space is quite enormous.
Then again, that might require some logic on the leader to track random nonce(s) that some client submitted.
Would it be reasonable for the client to proceed, but on his own randomly picked nonce? The search space is quite enormous.
Then again, that might require some logic on the leader to track random nonce(s) that some client submitted.
uwiger
merged commit 5bc0fc5ff8 into master2025-08-21 03:42:38 +09:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Although mainly a theoretical possibility, the server may send a candidate with
nonces := []. If so, we need to request new nonces before populating the workers.I see uw-reset-worker is being merged in here too - but both changes look reasonable.
@@ -117,0 +114,4 @@%% Nonces may be [], in which case we need to request new nonces first.#st{candidate = Cand1} = S1 = maybe_request_nonces(S#st{candidate = Cand}),{Workers2, Cand2} = assign_nonces(Workers, Cand1),#st{candidate = Cand3} = S2 = maybe_request_nonces(S1#st{candidate = Cand2}),If assign_nonces took a single nonce from the list, will this second request immediately fire? I guess that is fine?
Would it be reasonable for the client to proceed, but on his own randomly picked nonce? The search space is quite enormous.
Then again, that might require some logic on the leader to track random nonce(s) that some client submitted.