Let's say I want to handle all cases of when a forward message is received, and I want to split that into two groups:
Delivered
Queued
What would be the current best way to do that? I think previously we always tried to send the message in the forward message, so we could listen to the MessageSentEvent and look at the status. But now it seems like it's going through the MediatorService and based on the forwarding strategy it will add it to queu/ try to deliver / etc.. But there's no way I've found that I can get the result of how the message was handled.
Thoughts on that, have you tried to solve this?
Basically in our mediator API in Paradym we want to emit a delivered/queued event. Mostly the queued is important because it allows users of Paradym to send push notifications to the wallet
Discussed on WG call: if you use DirectDelivery mode you know it was queued when the message is stored in the message repository. But for other approaches this won't work as the message will always be queued. Maybe this is just something you need to build on top of Credo, e.g. check after 10 seconds if the queued message has been removed from the queue.
Let's say I want to handle all cases of when a forward message is received, and I want to split that into two groups:
What would be the current best way to do that? I think previously we always tried to send the message in the forward message, so we could listen to the MessageSentEvent and look at the status. But now it seems like it's going through the MediatorService and based on the forwarding strategy it will add it to queu/ try to deliver / etc.. But there's no way I've found that I can get the result of how the message was handled. Thoughts on that, have you tried to solve this?
Basically in our mediator API in Paradym we want to emit a delivered/queued event. Mostly the queued is important because it allows users of Paradym to send push notifications to the wallet
Discussed on WG call: if you use DirectDelivery mode you know it was queued when the message is stored in the message repository. But for other approaches this won't work as the message will always be queued. Maybe this is just something you need to build on top of Credo, e.g. check after 10 seconds if the queued message has been removed from the queue.