What I meant wasn’t that the subscriber is moving the confirmed LSN backward, nor was I suggesting we fix it by persisting the LSN on the subscriber side. My point was: the fact that the subscriber is sending an LSN older than one it has already sent, does that indicate a bug on the subscriber side? And if so, should the logic be fixed there?
In my experience, client applications do a lot of surprisingly not smart things.
However, it doesn't mean that the server should be blindly accepting whatever LSN client sends.
I tend to agree with Amit, we shouldn't allow confirmed_flush_lsn to move backwards.
