qa: Avoid checking reject code for now #13352

The node will often disconnect before sending a reject code. A more robust solution would be to read from the debug log. See #13006

I'm divided about this. Though obviously, if this causes frequent travis errors, it's the pragmatic short thing to do on the short term. utACK faac7a2db4f9f511c901cb1b4d4e7c599b92884f

It's more this that made me question:

A more robust solution would be to read from the debug log. See #13006

Shouldn't the race in the network code be fixed instead?

Shouldn't the race in the network code be fixed instead?

Imo, we shouldn't be nice to peers that send us invalid messages. The reject messages are only best-effort and not a guarantee.

Imo, we shouldn't be nice to peers that send us invalid messages. The reject messages are only best-effort and not a guarantee.

I agree on that, but the race itself is somewhat scary, I'm not sure it's easy to tell whether this doesn't affect anything else.

I agree with @laanwj that the underlying cause should be investigated.

Asserting on the reason for a transaction being rejected is a useful regression test. I don't think we should remove this check without a replacement like #13006

I agree with @laanwj that the underlying cause should be investigated.

I am not familiar with net, but a blind guess would be that we tear down the node (and message buffer) because of the disconnect without flushing it first. If this was the case, I doubt this wouldn't be intended behaviour. I am not aware of any guarantees in the protocol that we give to peers that are soon-to-be-disconnected, so I don't understand why this should be investigated. Mind to elaborate a bit more?

I don't think we should remove this check without a replacement like #13006

Note that the test were never in place until a few days ago. So there is no loss in restoring the previous state and fixing the travis failures.

I'm going to merge this to fix the travis failure, which seems to be really frequent.

Note that the test were never in place until a few days ago.

Ah. I hadn't realised that. utACK faac7a2db4f9f511c901cb1b4d4e7c599b92884f