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
MethodInvocation has an Iterator for interceptors.
If you call invocation.proceed(), then the iterator is queried for the next interceptor which is then invoked.
So if you call invocation.proceed() a second or further time, all subsequent iterators for that method invocation are not invoked.
MethodInvocation is pretty thin state-wise.
For most things it is just a data-holder.
The only things that are directly stateful are when setArguments(...) is called and when proceed() is called.
I guess the most proper solution would be to replace this.arguments = arguments; by System.arraycopy(arguments, 0, this.arguments, 0, arguments.length); and getting rid of the iterator for interceptors, but instead having an own MethodInvocation for each interceptor that knows the next interceptor to call.
This should be a backwards compatible change and fix all extensions that might do something similar to what @Retry does.
To Reproduce
Have a global extension (don't forget to register it in META-INF/services) like
Make sure the specification fails so that it is retried
Now either set breakpoints in the RetryIterationInterceptor and TempDirInterceptor, or check in the feature the presence of the temp dir, or similar.
Expected behavior
Retrying (and any interceptors doing something similar) should properly invoke subsequent interceptors each time.
Actual behavior
With non-suspending breakpoints that do some logging on the two mentioned interceptors, one on the proceed() line and one on the following line for each, you get output like:
retry try
temp dir: .../spock_build_should_fail_i_0_rootDir6715396349974787942
temp dir destroy:.../spock_build_should_fail_i_0_rootDir6715396349974787942
retry after try
retry try
retry after try
retry try
retry after try
retry try
retry after try
Dependencies
Spock 2.3-groovy-3.0
The text was updated successfully, but these errors were encountered:
Describe the bug
MethodInvocation
has anIterator
forinterceptors
.If you call
invocation.proceed()
, then the iterator is queried for the next interceptor which is then invoked.So if you call
invocation.proceed()
a second or further time, all subsequent iterators for that method invocation are not invoked.MethodInvocation
is pretty thin state-wise.For most things it is just a data-holder.
The only things that are directly stateful are when
setArguments(...)
is called and whenproceed()
is called.I guess the most proper solution would be to replace
this.arguments = arguments;
bySystem.arraycopy(arguments, 0, this.arguments, 0, arguments.length);
and getting rid of the iterator for interceptors, but instead having an ownMethodInvocation
for each interceptor that knows the next interceptor to call.This should be a backwards compatible change and fix all extensions that might do something similar to what
@Retry
does.To Reproduce
META-INF/services
) like@TempDir
fieldNow either set breakpoints in the
RetryIterationInterceptor
andTempDirInterceptor
, or check in the feature the presence of the temp dir, or similar.Expected behavior
Retrying (and any interceptors doing something similar) should properly invoke subsequent interceptors each time.
Actual behavior
With non-suspending breakpoints that do some logging on the two mentioned interceptors, one on the
proceed()
line and one on the following line for each, you get output like:Dependencies
Spock 2.3-groovy-3.0
The text was updated successfully, but these errors were encountered: