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
I noticed the following behaviour; when I first get the onError, then the state change to FAILURE and when I then delete the transferrecord it state again changes to CANCELED. I would have expected that FAILED was an end-state of the state machine.
It would be very good to have a state transition diagram, at least from the point of view of the SDK-user to see what actions are allowed in what state.
The text was updated successfully, but these errors were encountered:
That's because TransferUtility.delete(int) always calls cancel before actually removing it from database. From what you described, it looks like you tries to delete a transfer in onError. At this moment, the transfer (Future) is probably not done yet. When delete is called, it cancels the ending transfer and changes its state to CANCELED. Probably we can add some smart logic not to cancel any transfer in a final state: PAUSED, CANCELED, FAILED, COMPLETE.
I do not agree that PAUSED is a final state. You should be able to CANCEL a PAUSED transfer. It would just mean that you change the state to CANCELED, so you would not be able to RESUME.
I noticed the following behaviour; when I first get the onError, then the state change to FAILURE and when I then delete the transferrecord it state again changes to CANCELED. I would have expected that FAILED was an end-state of the state machine.
It would be very good to have a state transition diagram, at least from the point of view of the SDK-user to see what actions are allowed in what state.
The text was updated successfully, but these errors were encountered: