Closed shadeofblue closed 6 years ago
to reproduce, you can run: ./tests/test_force_download.py
from the concent_node_tests
suite
ok, I believe it's because the timestamp of FRCT equals the timestamp of RCT ... I think it should still be legal to send the FRCT (almost) immediately after having received RCT (after some critical download failure) but as far as tests are concerned, adding a short wait in the test fixes the issue
@dybi this may be of interest to you. The inequalities are back :)
I think it should still be legal to send the FRCT (almost) immediately after having received RCT (after some critical download failure)
You mean FGTR, right?
The spec does not say anything about it so we had to make assumptions. In Concent the time intervals are left-open, right-closed. So the provider is safe from FGRT until RCT.timestamp. Only after that point we start accepting FGTR.
It's not set in stone and we can change it but let's do it consistently everywhere.
@cameel yes, FGTR, sorry
@cameel would it result in any negative consequences for the time intervals to to be closed on both ends? ...
I wanted to avoid the possibility of overlap. The one negative consequence would be that if we had two intervals next to each other we would have a point of overlap where the result would not be deterministic (it would depend on which message comes first). For example interval [1, 2] where we expect message A and interval [2, 3] where we expect B if we did not receive A. Receiving both A and B at 2 would be a problem.
But after looking at the timing diagram I don't see any case of this so changing time intervals to closed on both sides is doable. But there's still a small risk that something like this will come up due to a future changes in the spec.
I'm closing this one since we now know the cause.
After discussing this on Rocket the consensus is that we can safely remove the lower time limit in the result transfer use case. I have created a separate issue for that: #532.
When sending a
ForceGetTaskResultRejected
message to the Concent, Golem Client receives:The
ForceGetTaskResult
message:and the SVT here is ~4 hours whereas the message was sent after a few seconds from the reception of the RCT, after the Requestor node failed to download the results from the Provider