mirror of
https://github.com/KumoCorp/kumomta.git
synced 2026-08-19 00:01:07 +00:00
Wez Furlong
f53ed1aeae
Ordinarily, the logic that calls the requeue_message event is responsible for increasing the number of attempts, computing the revised due time, and processing message expiration. When using XFER to move a message to another node, we capture the scheduling state at the point that the xfer was initiated. If we do this inside the requeue_message event callback then we will capture the scheduling information *prior* to the normal adjustments that would happen later. This commit adds kumo.xfer.xfer_in_requeue to handle this case; you pass through the scheduling information parameters that were added to the requeue_message event in the prior commit, and it will compute any revised scheduling for the message before wrapping the message up in the XFER encapsulation and moving the message to the xfer queue. This adjusted process ignores message expiration, so if the message is on its last retry it will be xfer'd to the target host which then might choose to perform the expiration. We can't handle the expiration in the context of `requeue_message` because the event handler doesn't own the message and has no way to signal that it has reached the end of its life. Folks doing xfer in requeue_message will generally be moving the message well in advance of it being expired, so this minor limitation is not expected to be a practical problem.