[BUG]: Remote synchronization fails
felsweg-iota opened this issue · comments
Bug description
Synchronizing state for remote Peers fails here, but with an ambiguous error ( "Failed" ).
Rust version
latest ( 1.61.0 )
Stronghold version
latest ( 0.7.1 )
Steps To reproduce the bug
Explain how the maintainer can reproduce the bug.
- Run the test mentioned above.
Expected behaviour
The Client state from the first Client should be fully synchronize to the second Client
Actual behaviour
Execution fails / Test fails.
@elenaf9 do you think you can give some insight here?
Are you able to pin it down a bit more to where exactly it fails? Unless this was changed, the sync consists of multiple steps. Do you know at what step exactly the failure occurs and if it occurs on the local or the remote side?
Hello @elenaf9, yes that the sync consist of multiple steps is clear. The exact location of failure is shown in this error trace
'tests::network_tests::test_synchronize_snapshots' panicked at 'Failed to get remote hierarchy: Err(Inner("Connection was closed before a response was received"))', client/src/types/client.rs:532:9
which should be this location. Getting the remote hierarchy fails. Maybe this is just a stupid error, that can easily be fixed. Please keep in mind, that handling requests has changed and now goes through a select/loop. Handling Client and Snapshot requests are now being handled separately. Maybe even this specialization may be lifted in the future. I hope this information may be sufficient, otherwise feel free to ask for more details, and i'll try to provide if i can :)
Okay thanks, will look into it. As an aside: why do you panic there instead of returning the error?
There is no reason to panic!, but returning an error would be more sensible.
If that helps, here is an old diff for the synchronization code.
Okay thanks, will look into it.
Just as an heads up: I am currently rather busy and it might take a while until I get to it. Please don't block anything on this.
There is no reason to panic!, but returning an error would be more sensible.
Not sure I understand what you mean. I probably phrased my question a bit misleading. So to rephrase: the current assert! causes the program to panic if the previous line returned an error. Was there a specific reason for it this way?
@elenaf9 it's already enough that you support us in this matter 😊
Not sure I understand what you mean. I probably phrased my question a bit misleading. So to rephrase: the current assert! causes the program to panic if the previous line returned an error. Was there a specific reason for it this way?
No. There is no reason for it. it should return an error.
with the removal of the p2p crate, this issue is now obsolete.