You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the gRPC session terminates for some reason while the image transfer is in progress, and the server never receives the "TransferEnd" request, should the server clean up by deleting the file which had been transferred upto that point and stop expecting the next set of bytes? This seems logical, as the alternative - setting up a new session, will require a method to synchronize state.
Another scenario to consider is when transfer is completed and client has sent transfer end, but device has not yet sent "Validated" message, but the gRPC session has gone down.
Perhaps add a clarification to the proto through a comment as well to standardize the behavior?
The text was updated successfully, but these errors were encountered:
The expectation is that any transfer which doesn't complete successfully will be cleaned up. Currently there is no defined "resume" functionality in the spec so there shouldn't be any expectation on server side for a client to be able to resume
If the gRPC session terminates for some reason while the image transfer is in progress, and the server never receives the "TransferEnd" request, should the server clean up by deleting the file which had been transferred upto that point and stop expecting the next set of bytes? This seems logical, as the alternative - setting up a new session, will require a method to synchronize state.
Another scenario to consider is when transfer is completed and client has sent transfer end, but device has not yet sent "Validated" message, but the gRPC session has gone down.
Perhaps add a clarification to the proto through a comment as well to standardize the behavior?
The text was updated successfully, but these errors were encountered: