I was testing repeat step for a special case and came across this amusing situation.
In Case 1, I had given the step that would throw an exception as the last step in the repeat step (retries 2 times, with backoff 2 sec’s on failure) and the flow moves smoothly after the third try to catch block.
In Case 2, The step that throws the exception is the first step, or a step in the middle, the third repeat step (ie retry 2nd time) throws an exception instead of going to error handle case.
Repeat objects will repeat on error or on success. I have used repeat functions when trying to reach systems and when failing to do so, would sleep the thread for five minutes and then “repeat”.
This will put the code in an endless loop unless you put in an exit after “n” number of times (of which you have to count).
In your case, the repeat object is probably set to repeat on failure until you reach the specified number of times.
Keep in mind, that the number you set is n + 1. So, if you set it to repeat 999 times, the repeat will run 1000 times. The original + 999.
Thanks for the mail. Infact I understand how ‘repeat’ works theoretically. But i thought this might be amusing to know about this ‘feature’ or the ‘bug’.
Well it did not shed any light to me on why it goes to the catch block ONLY when the ‘fail able’ flow is the last flow. Should it not be going to the catch block ‘after all the retries’ is exhausted irrespective of its position in the flow ‘ideally’. Or would it throw an exception immaterial of the presence of a catch block after the last try. (Foolish thoughts, what I am talking…)
Otherwise how would I position the flows, I might need five simultaneous repeat steps to try five flows.
The developer behaves differently when you are “running” the code by pressing the arrow button, versus stepping through the code.
Ideally, it should repeat on error and not display the message box.
What are the results when you run the code outside of developer? You can run it via http invoke using a browser, or you can schedule a one-time event through the scheduler as possibilities. This will take the developer out of the picture.
I had seen many times that developer behaves differently while stepping and it is always better to execute the flows from the browser when things are not working the way it should.
But you know you forget to check the basics when things go wrong.
That was perfect answer Ray. It did work the proper way when I stopped stepping thru it.
Little things like this takes a lot of time till you are on the right track. Thank you for solving this cute mystery for me. I wish to say I would be more careful next time, but I know me better than that.
In a flow service, where you have used LOCAL_TRANSACTION for a JDBC connection, stepping through the service will throw an error. You will need to run it rather than step through it.
An undocumented workaround: Specify the connection as local_transaction, but do not use the start transaction/commit or rollback. You can disable the calls in your flow service.
Once you have disabled, then you can step through. It treats the connection as a no_transaction and auto-commits. This will allow you to step through to determine if/where/whatever may be wrong.
