Open alexjhawk opened 1 year ago
If time permits or later down the line, possibly pull up functionality into the abstract framework to simplify connector-level implementation
The framework itself is working as expected, but there is a significant limitation in the connector-level implementation:
The retry counter on associated message objects is successfully incremented when a message fails, but the value is lost/reset to 0 during regular operation. The connector manages data using payload objects, separate from the message objects that are built at each request. As such, failed messages will be retried as expected, but the fail/retry counter will always be 0 since a fresh message object was created for the specific attempt/try.
Due to this limitation, the connector cannot accurately track the number of times a payload/message has been retried. This means there is no upper limit on retries and no time-based backoff mechanism. While it has not been encountered during testing, it is reasonable to assume that an infinite retry condition could be experienced, where the connector would be unable to recover without restart.
Note: This condition has existed since v1.0.0/v1.0.1 of the connector and is not introduced by any ongoing development changes for v1.0.2.)
Take note of the status and error-handling functionality. The framework is there, but we just need to double-check the retry and error handling of all endpoints/requests.