I've tried sending the message with the same id, headers and content to db-using CAP-handler (transport - Kafka, db - MySql).
It was my intuitive expectation, that with db-backed inbox it is possible and reasonable to identify the same message sent more than once and skip a repeated execution, thus improving idempotence.
Is there any specific reason not to or is there some configuration parameter that I may have missed?
Why it seems reasonable:
Not all transports are transactional. If a message has been successfully dispatched to a transport, but then there's and error (e.g. network-caused) we wouldn't be able to save information about a dispatched message and (please, correct me if I'm wrong) once db is up and running again, hosted service will try to send the same message again.
I feel like we wouldn't want to have to process the same message again if we can avoid it via id checking.
yang-xiaodong
commented
2 months ago
I've tried sending the message with the same id, headers and content to db-using CAP-handler (transport - Kafka, db - MySql).
It was my intuitive expectation, that with db-backed inbox it is possible and reasonable to identify the same message sent more than once and skip a repeated execution, thus improving idempotence.
Is there any specific reason not to or is there some configuration parameter that I may have missed?
Why it seems reasonable: Not all transports are transactional. If a message has been successfully dispatched to a transport, but then there's and error (e.g. network-caused) we wouldn't be able to save information about a dispatched message and (please, correct me if I'm wrong) once db is up and running again, hosted service will try to send the same message again. I feel like we wouldn't want to have to process the same message again if we can avoid it via id checking.