The translation-proxy MG test displays undeterministic behavior on CI.
The MG test does the following:
- launch a tProxy
- launch a SV1 CPU miner
- injects messages to tProxy while mocking an upstream
tProxy will establish a channel with the mocked upstream with some predefined difficulty target (via OpenExtendedMiningChannel)
once tProxy receives a NewExtendedMiningJob, it forwards it to the CPU miner (as Sv1 messages)
the lack of determinism comes from the fact that two different things could happen after NewExtendedMiningJob is sent:
- maybe CPU miner finds a share that is valid under the Channel difficulty target, therefore tProxy sends
SubmitSharesExtended to its upstream
- maybe tProxy finished its difficulty adjustment (by looking at SV1 shares submitted by the CPU miner), and it needs to change the difficulty target of the Channel via
UpdateChannel
it's impossible for us to know beforehand the nominal_hash_rate of the CPU miner (since it depends on the available system resources)
as a consequence, we often see the following error on the current MG CI:
WRONG MESSAGE TYPE expected: 27 received: 22
- 27 is decimal for
0x1b, which means SubmitSharesExtended
- 22 is decimal for
0x16, which means UpdateChannel
(ref: Message Types Spec)
that is because the MG test is fixed in a way that after sending NewExtendedMiningJob, it expects ONLY SubmitSharesExtended, so whenever the difficulty adjustment finishes BEFORE a valid share is found, CI breaks
#1059 was meant to add this kind of functionality to MG, which would allow it to assert that EITHER one specific message OR another arrived. Unfortunately, the trade-offs on the engineering effort for implementing this feature on MG didn't seem appealing.
hopefully the Integration Test framework will give us enough flexibility to avoid this kind of problem
The
translation-proxyMG test displays undeterministic behavior on CI.The MG test does the following:
tProxy will establish a channel with the mocked upstream with some predefined difficulty target (via
OpenExtendedMiningChannel)once tProxy receives a
NewExtendedMiningJob, it forwards it to the CPU miner (as Sv1 messages)the lack of determinism comes from the fact that two different things could happen after
NewExtendedMiningJobis sent:SubmitSharesExtendedto its upstreamUpdateChannelit's impossible for us to know beforehand the
nominal_hash_rateof the CPU miner (since it depends on the available system resources)as a consequence, we often see the following error on the current MG CI:
0x1b, which meansSubmitSharesExtended0x16, which meansUpdateChannel(ref: Message Types Spec)
that is because the MG test is fixed in a way that after sending
NewExtendedMiningJob, it expects ONLYSubmitSharesExtended, so whenever the difficulty adjustment finishes BEFORE a valid share is found, CI breaks#1059 was meant to add this kind of functionality to MG, which would allow it to assert that EITHER one specific message OR another arrived. Unfortunately, the trade-offs on the engineering effort for implementing this feature on MG didn't seem appealing.
hopefully the Integration Test framework will give us enough flexibility to avoid this kind of problem