This repository has been archived by the owner on Mar 30, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 80
RetryOn ignored due to wrong command order #3
Comments
Yes, the library is vulnerable to the order of abort/retry calls, unfortunately. Thank you for such complex examples, I'll make unit tests out of them and try to sort out how this can be improved. In general the order shouldn't matter, at all. |
I think both examples can be reduced to the "abortIf" and "retryOn(UploadResponseException.class)" lines. |
nurkiewicz
added a commit
that referenced
this issue
Jan 5, 2014
…y irrespective to order of declaration
nurkiewicz
added a commit
that referenced
this issue
Jan 5, 2014
nurkiewicz
added a commit
that referenced
this issue
Jan 5, 2014
nurkiewicz
added a commit
that referenced
this issue
Jan 5, 2014
nurkiewicz
added a commit
that referenced
this issue
Jan 5, 2014
nurkiewicz
added a commit
that referenced
this issue
Jan 5, 2014
Sorry for the delay, it's fixed and released under version |
That's right. The "workaround" is putting the statements in another order. |
# for free
to subscribe to this conversation on GitHub.
Already have an account?
#.
Hey Tomasz,
Throwing a "UploadResponseException with status code 503":
The abortIf predicate will return false
Tested in java7 backport.
Example order 1 (failing):
Example order 2 (working):
Seems like my retryOn is ignored if using the wrong order.
It'd be nice to have compile time check for correct order (like typeof) or to fix this bug.
The text was updated successfully, but these errors were encountered: