Subscription catchup / state delta

You’re quite right that that would in fact work for the example I gave. In retrospect, I should have given something slightly more complex, so replace it with a chat channel where you need:

a) The initial state (all messages up to this point), and
b) Notification of all changes to that state (when a new chat message is sent).

In this case you have to have the client de-duplicating chat messages that might have arrived on the subscription and also be in the state, and the Absinthe architecture doesn’t really make it easy to fix that. Again, in principle it’s easy enough to do on the client, but it feels like it shouldn’t be required.