How Can I Allow a Follow-up Action to Fail but Still Save the Work Item?
This is similar to a question I have asked in the past, but there is an important distinction to my current situation that I'll try to distinguish.
I have a follow-up action that modifies the parent of the work item being saved. If the parent cannot be modified, I want the current follow-up action to display a warning, but allow the save operation to succeed for the current work item. I've been able to do something similar to this in the past where a follow-up action would not prevent the work item from saving if I caught the exception thrown by the work item's save operation. However, this time that technique isn't working. The only thing I can think that is different is that previously the exception was being thrown by the save operation on the work item that triggered the follow-up action. By contrast, in my current scenario the parent work item's save operation is the one throwing the exception. In this instance, catching the exception doesn't seem to allow the follow-up action to save the child.
Does anyone know how to do what I am trying to do?
Ideally, I'd like to know whether the save operation on the parent is going to succeed without actually trying to do it. I think I've asked about that capability in the past though without success.
Edit: Evidently I've asked this question almost word-for-word before. https://jazz.net/forum/questions/201697/server-side-java-api-how-can-i-determine-at-runtime-if-a-work-item-can-be-saved-without-trying-to-save
I had convinced myself that I could do this by catching the exception. However, even if that is true it doesn't seem to be a valid solution for my current situation so I need another solution.
2 answers
if, in the followup, you invoke save again, then another entire sequence is run, advisors, then followups on THAT workitem (even if it is the same workitem)
one workitem at a time.
Comments
Follow-ups run after, but if they fail they prevent the initial save from completing. I don't see entries in the revision history which indicate a change was committed and rolled back, so there must be some sort of soft-commit under-the-hood. If you have a chain of operation behaviors that modify X work items and then work item X-1 fails to save for some reason, all X work items will remain unchanged.
I think I've noticed that if a follow-up action tries to create a new work item and then that follow-up action has to be rolled back, the work item's unique identifier is consumed, but no work item exists possessing that identifier. So on at least some level, changes are made on a preliminary basis. They just don't stick unless everything succeeds.
hm.. ok, I understood it differently. but you may be right. It would make more sense I guess.
It takes a bit of searching (:-), but in: https://jazz.net/wiki/bin/view/Main/TeamProcessDeveloperGuide#Adding_New_Operation_Participant , it says:
"On the server, participants are run in the same transaction as the operation in which they are participating. If a participant throws an exception or reports a serious problem, subsequent participants will not be run. On the server, this will cause the entire operation transaction to be rolled back."
So the "roll-back on failure" behavior Nate is seeing is what is expected. But I don't know why you cannot catch the exception to prevent the failure.
1 vote
Comments
Actually, this is exactly what I was trying to do. I catch the TeamRepositoryException and then add a warning to the collector (explicitly setting the severity level exactly as you describe). Unfortunately, it still doesn't seem to matter. I see my custom warning message displayed in the Team Advisor window in the eclipse client, but then the error message that was supposed to be caught is also displayed and the work item does not save. I wonder if it is because the work item that is throwing the exception is different from the one that is being modified? I haven't tested to see whether it would have worked if it was the same work item though.
It seems that catching the exception is too late to stop the save operation from being prevented. I need to know not to attempt the operation in the first place.
It sounds strange: if you catch the exception I don't think that it should be propagate, or it should be for every kind of exception, and I have already catch IOException in this situation without problem.. do you return the follow-up action after the catching? Are you sure there is no other exceptions?
If you catch, the exception is gone, unless you throw it or a new one again. You might want to catch Throwable and not Exception.