infinite_looping_in_forward_transaction_#931

[apoorv-2204]

Description

Fixes

• Infinite looping in forward transaction  #931

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Test A
• Test B

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[Neylix]

Looks good to me, can your rebase to solve conflict and not override new changes ?

[bchamagne]

To make the test work I had to hardcode a network patch, because there is a randomness in local development that breaks this feature.

I tested this scenario:

✔️ 3 nodes, I modified the code of 2 nodes to mark them as invalid for processing (to force the forward). I then sent a transaction to A that forward it to B that forward it to C.

• When you remove the task.async, we now have A that wait until timeout, and when the timeout occur, A will try to send to C (in the same scenario as above), which I believe is not good.

ps: please keep commit history

[apoorv-2204]

To make the test work I had to hardcode a network patch, because there is a randomness in local development that breaks this feature.

I tested this scenario:

✔️ 3 nodes, I modified the code of 2 nodes to mark them as invalid for processing (to force the forward). I then sent a transaction to A that forward it to B that forward it to C.

• When you remove the task.async, we now have A that wait until timeout, and when the timeout occur, A will try to send to C (in the same scenario as above), which I believe is not good.

ps: please keep commit history

Hi, we are relying on timeout to notifiy user. I updated geo patch for null patch for localhost

[samuelmanzanera]

To make the test work I had to hardcode a network patch, because there is a randomness in local development that breaks this feature.
I tested this scenario:
✔️ 3 nodes, I modified the code of 2 nodes to mark them as invalid for processing (to force the forward). I then sent a transaction to A that forward it to B that forward it to C.

• When you remove the task.async, we now have A that wait until timeout, and when the timeout occur, A will try to send to C (in the same scenario as above), which I believe is not good.

ps: please keep commit history

Hi, we are relying on timeout to notifiy user. I updated geo patch for null patch for localhost

Indeed, I wasn't against to spawn a process it's just the Task.async expected to await something, maybe a start_child would be sufficient. (But QUID of the error network_issue then ?)
Otherwise we will have cascading timeout.

[bchamagne]

Maybe I got it wrong, but I believe my last comment is still relevant. We talked about an ACK msg no?

[apoorv-2204]

Maybe I got it wrong, but I believe my last comment is still relevant. We talked about an ACK msg no?

Replay back a message?

[Neylix]

Maybe I got it wrong, but I believe my last comment is still relevant. We talked about an ACK msg no?

The ack message is returned in the process function of the message NewTransaction