Message routing service is not working properly

Hello,

Over the past three days (up until today), we've observed inaccurate behavior in the Message Routing Service.
Specifically, we shut down our destination service during this period, yet the Message Routing Service dashboard incorrectly indicates that messages were successfully delivered, rather than marked as failed—as would be expected given the destination was unavailable. Today, the messages was marked as failed, as it was expected.

Is this feature considered production-ready for handling sensitive and business-critical client data?

Thank you in advance 

Parents
  • Hi Avgerinos Bakalidis,

    We have recently enhanced the retry logic and Dead Letter Queue (DLQ) handling in our Message Routing Service. Our updated system now attempts to deliver messages
    to your endpoint continuously for a period of 24 hours. Should these attempts fail, the messages are then securely stored in the DLQ for a duration of 30 days.
    During this period, you can access and retrieve these messages using our APIs, ensuring that no business-critical information is lost even if your endpoint is temporarily unavailable.

    We are in the a process of updating our user documentation to reflect these changes.
    Additionally, we have noted a minor discrepancy in the "Message Failures" section of our frontend, which should have DLQ message count instead.
    Also we might need to add additional status information in case of webhook is failing and we are still trying to retry.

    If you have any suggestions or improvement ideas, please don't hesitate to contact me directly via email.
    It is my [email protected]

    We plan to address and correct these in an upcoming releases.

    Best regards,
    Markku Lehto

Reply
  • Hi Avgerinos Bakalidis,

    We have recently enhanced the retry logic and Dead Letter Queue (DLQ) handling in our Message Routing Service. Our updated system now attempts to deliver messages
    to your endpoint continuously for a period of 24 hours. Should these attempts fail, the messages are then securely stored in the DLQ for a duration of 30 days.
    During this period, you can access and retrieve these messages using our APIs, ensuring that no business-critical information is lost even if your endpoint is temporarily unavailable.

    We are in the a process of updating our user documentation to reflect these changes.
    Additionally, we have noted a minor discrepancy in the "Message Failures" section of our frontend, which should have DLQ message count instead.
    Also we might need to add additional status information in case of webhook is failing and we are still trying to retry.

    If you have any suggestions or improvement ideas, please don't hesitate to contact me directly via email.
    It is my [email protected]

    We plan to address and correct these in an upcoming releases.

    Best regards,
    Markku Lehto

Children
No Data
Related