MQTT catch-up missed messages, looking for feedbac

Question

I would like some feedback on this problem and my proposed solution to catching up after missed MQTT messages please:

---

[Update 1] Simplified problem diagram and added solution diagram. Added mention of QoS

---

Scenario:

Client A publishes messages that we wish Client B to receive, even if connections are temporarily dropped then restored.

Config

• Client A: connect with clean=false. Publish stateful messages with retain = true, non-stateful messages published with retain = false
• Client B: connect with clean=false

What will happen

Each time Client A publishes to topic "foo", previous messages are replaced on the broker. Ex. Client A publishes 111, 222, 333. Client B connects after the messages are published. Client B will receive only, 333. Thus, messages 111 and 222 were missed because each message replaced the previous one on that same topic (different topics do not replace each other).

Proposed solution

I envision two types of messages. Stateful and non-stateful. Stateful messages would be things like, voltage, temperature, gps location, pressure. Non-stateful messages would be things like a chat message where history is more likely to be important for context. Missed stateful messages are more likely to be tolerable while non-stateful messages might not be tolerable.

All messages are published with QoS 1 in my case.

For the stateful messages I am thinking Client A will publish with retain = true.

For the non-stateful messages, I am thinking Client A will publish with retain = false (because what good is the last message if we don't have the full historical context of previous messages). When Client B connects/reconnects, I will publish a catch-up (arbitrary name) message containing all the ids of the messages it received, which when Client A receives it, will respond by publishing the whole history of messages minus those in the id list (ids maintained in Client A db). This might work for me if the total aggregate message history isn't too big.

The alternative might be for Client B to send read receipts for each message received.

For me, these two solutions will require a database of messages and some custom logic

---

This is a follow-up question to this one which I tried answering but was asked to instead form it as an independent, follow-up question.