feat(mesage-pickup): option for awaiting completion #1755
Conversation
Signed-off-by: Ariel Gentile <[email protected]>
| // message pickup process (Note: this is not optimal since we'll always doing an extra | ||
| // Batch Pickup. However, it is safer and should be faster than waiting an entire loop | ||
| // interval to retrieve more messages) | ||
| if (messages.length === 0) { |
There was a problem hiding this comment.
If messages.length is smaller than the batch size we can also assume the message pickup is complete right?
There was a problem hiding this comment.
Yes! The issue is that I cannot be 100% sure of the batch size requested in the originating batch message (I can assume it from agent config but user can actually override it)
I think you can still use PickUpV2LiveMode. The 0.4.2 agent will be unable to process the live delivery change but the socket will stay opened and it will forward the messages though it as they arrive. |
|
Okay makes sense! Maybe we should deprecate implicit mode in 0.6 and remove in 0.7 (or deprecate in 0.5.x and remove in 0.6). Maybe we should also deprecate pickup v1 then, as there's not really a lot of adoption, and also not really any reason not to use v2 |
Add a blocking mode for
MessagePickupApi.pickupMessages(), where the agent will wait until all messages have been effectively retrieved and therefore the message pickup process is completed.This tries to solve two main situations:
MediatorPickupStrategy.PickUpV2LiveMode. This allows supporting the case where the mediator does not supportlive-delivery-changemessage (which is the case of AFJ <= 0.4.2 and AFAIK ACA-Py's Pick-up v2 plug-in). In such case, mediator will send a problem report that will be logged in the recipient but should not prevent the pick-up flow from being startedI did not take too much effort on the tests yet as I see there are some improvements in #1754 so maybe I can incorporate them once it's reviewed and merged.