Add option to end LRA only at the service that started it

[xstefank]

We could add an option to the LRA annotation that would prohibit different services to which the LRA is propagated to close the LRA (and thus it can be invalidated anywhere). In this sense, only when the calls return responses to the initiating service the LRA can be ended and thus it gives a guarantee to the initiating service that the LRA is still active. The name of such a possible parameter is up for discussion.

[mmusgrov]

This is too restrictive. For example if the initiator crashes then it is not possible to close the LRA. It also adds unnecessary coupling between services.

[mmusgrov]

Can we close this issue?

[xstefank]

This is too restrictive. For example if the initiator crashes then it is not possible to close the LRA. It also adds unnecessary coupling between services.

If any service which is intended to close the LRA (even now if it's closed elsewhere) crashes, it can be restarted so I don't understand this argument. And LRA itself introduces coupling because of the transaction that is propagated so services need to be aware that they are participating in the particular LRA. And after all, this would be optional opt-in on the developer side if there is a use-case for it. So I would prefer to not close it yet unless everyone thinks that it's not a good idea.

[tomjenkinson]

I can't recall the exact details but does the spec allow new participants to be added that can reduce the timelimit of the LRA? If that is the case wouldn't users just register dummy participants with very minimal timelimit to work around any restriction? Even if not it might decide to hold processing indefinitely to trigger the cancellation.

[xstefank]

@tomjenkinson yes, that is possible now but I don't understand how it relates to this issue. I am proposing the opposite, to disallow other participants to end the LRA (up to the timelimits -> that's a good point).

[rdebusscher]

If we would allow such restriction, then it needs to be configurable for each LRA separately.

But I'm not sure what should happen if some other participant tries to close the LRA or what happens when there is an 'exception' or status 500 is thrown. Just ignore or close the LRA?

So more details are required, I guess.

[xstefank]

it would be configurable for each LRA in the LRA annotation. And I agree that this would need to be clarified but I am bringing this up for a discussion now whether or not it is a useful idea.

[tomjenkinson]

@tomjenkinson yes, that is possible now but I don't understand how it relates to this issue. I am proposing the opposite, to disallow other participants to end the LRA (up to the timelimits -> that's a good point).

That was really the main part of my point. That if we impose a way to prevent services closing the LRA (and perhaps I am thinking to the point where we have a client API) then any restriction on that method could be circumvented by a sleep (I expect bad for performance of the system I assume something we do not want to encourage) or affecting the timelimit.

More details will help but no urgency from my side if it can wait to 1.x (which I assume it can as you added that milestone). Thanks