How Can I Allow a Follow-up Action to Fail but Still Save the Work Item?

Nate Decker (378●1●40●59) | asked Dec 04 '15, 3:19 p.m.
edited Dec 04 '15, 4:23 p.m.

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

Most liked answers ↑|Newest answers|Oldest answers

permanent link

sam detweiler (12.5k●6●194●201) | answered Dec 05 '15, 7:56 a.m.

I'm sorry, I don't follow. follow-ups, run AFTER the save is complete.

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

Nate Decker commented Dec 14 '15, 10:06 a.m.

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.

sam detweiler commented Dec 14 '15, 10:11 a.m.

hm.. ok, I understood it differently. but you may be right. It would make more sense I guess.

Geoffrey Clemm commented Jan 05 '16, 8:57 p.m.

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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.

permanent link

Michele Pegoraro (1.8k●14●117●103) | answered Dec 14 '15, 11:00 a.m.

I think you have to catch the exception and then you can set a warning using the ParticipantCollector: you can add a message and then set the severity to warning. Generally I do the inverse thing, changing the severity in order to make it fails the participant. The only problem is that you have to prevent ANY exception catching them.

Comments

Nate Decker commented Dec 14 '15, 11:51 a.m.

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.

Michele Pegoraro commented Dec 14 '15, 11:59 a.m.

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?

Ralph Schoon commented Jan 06 '16, 5:09 a.m.

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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.

It's all about the answers!

Related questions

How Can I Allow a Follow-up Action to Fail but Still Save the Work Item?

2 answers

Your answer