PostgresSubscribableChannel initial message polling dies due to exception

[joshiste]

Currently, on the first subscribe of a MessageHandler, notifyUpdate() is called to process messages already in the message store.
The problem with notifyUpdate() is that the try-catch block is outside the loop, so the loop will die on an exception, leaving further messages unprocessed.
When it receives notifications for inserted messages, this is not a problem because those notifications will submit a new task to poll further messages.

We could move the try-catch inside the loop to prevent it from dying. (If we don't do this, we might as well remove the try-catch, as it's good for nothing)
This would be fine for non-transactional usage. Messages are all processed and removed, and eventually, the loop stops.

This solution is a problem for transactional usage: The loop will never terminate, and the same message will be read repeatedly. For incoming notifications, we'd start further tasks that will go looping and exhaust the thread pool.
As of today, with transactional usage and without any other measures, messages producing an exception will also effectively block the channel (but not exhaust the thread pool)

Here is a reproducing test case and the mentioned solution. I'm not very lucky with that solution but currently have no better idea.

[joshiste]

Hmm maybe add to option to set a recovery callback that we pass to the retry template?

[artembilan]

I think I agree that we don't need that try..catch in that notifyUpdate(): the message would be already removed from DB anyway, so we are good to move on to the next one in the queue.
I also think that you are right and we have to expose a RecoveryCallback<T> recoveryCallback option to mitigate retry exhaust.
By default the error log should be enough.
It also looks like that RecoveryCallback must always return something to make our loop to continue working.

I think I'll revert my recent change to the askForMessage() since with just status.setRollbackOnly() we don't re-throw an exception to the RetryTemplate 🤷

[artembilan]

No, I'm taking that back.
My logic is like this:

		.filter(message -> {
											if (!this.hasHandlers) {
												status.setRollbackOnly();
												return false;
											}
											return true;
										})

So, that applies as an optimization in case we don't have subscribers to dispatch message any more.