@Shourya742 @plebhash @GitGab19 I took a different approach here:
Instead of starting a miner and waiting for share submission and then success share submission message and altering it to error share submission, I just altered one of the previous messages(MINING_SET_NEW_PREV_HASH in this case). This is inspired by a discussion I had yesterday with @Shourya742 .
LMKWYT please.

can you elaborate on why SetNewPrevHash should consist a meaningful trigger for fallback?

it feels like we're trying to take a shortcut (while deviating from the original MG test scenario), and I'm not sure I'm convinced with the trade-offs

I see how the original message flow could seem overly complex (and verbose) at first, and I understand the impulse to try to abstract away this extra complexity, but I feel we could be in a bad direction here

ITF have a lot of benefits over MG, and decreased definitely verbosity (Rust vs JSON) is one of them... but unfortunately we cannot make it perfect, and at some point, we also have to stick to the original flow of protocol messages so that we are asserting the right protocol behavior instead of trying to optimize for reduced test complexity

we have to be careful here because that would be missing the forest for the trees

for reference, the original MG test was introduced here: #617

IMHO the functionality added by #617 should be our north star when deciding what we want to assert on this specific Integration Test

if we shift strategy and assert for something different, we would be giving up on some valuable test coverage on our CI, and part of the motivation for migrating is to still rely on it for these

finally, fallback is a very essential "selling-point" of JD, and the rejected share trigger is the most obvious feature that a SRI implementation would have (and ideally enforced by CI)

Hmm, it is not about verbosity or complexity. It is more about the miner code that we need to either keep tuning or change it to expose some API from it to use in test env, something to be done with sv1 and 2 miners.
There is no specific reason why to choose SetNewPrevHash, it could be SetupConnectionSuccess or any other message from the upstream. I dont see that #617 is asserting anything really? the integration test does assert the JDC connected to the second pool in the vec.

Generally I would be against mocking stuff, but here we are really mocking(or eliminating) the miner behavior which is not part of the SRI project.

The trick about changing the prev_hash was found by me months ago just to quickly trigger the fallback. But it was slightly different though. The prev_hash which was randomly changed/faked was the one sent in the SetCustomMiningJob to the Pool. But again, it was a very dirty and tricky way to trigger the fallback, and it's not the right way to test it. Maybe in the future we are gonna change something in how Pool or JDC manages the prev_hash and this test won't be affordable anymore. We don't want that, so I would really suggest to do it in the most accurate way, which is by altering the SubmitSharesExtended.Success message into a SubmitSharesExtended.Error.

I dont see that #617 is asserting anything really?

the MG test we're aiming to migrate on #1207 (which is the motivating issue for this PR) was introduced on #617

asserting for SetNewPrevHash, SetupConnectionSuccess or any message other than SubmitSharesExtended.Success / Error is working around this goal, and I really don't understand the motivation for that.

It is more about the miner code that we need to either keep tuning or change it to expose some API from it to use in test env, something to be done with sv1 and 2 miners.

if this is a blocker, we should focus on making it work and then come back to this

but IMHO hacking around it by modifying the nature of the test that we're aiming to migrate completely misses the point