Hi All, I’ve created a pull request to clean-up the retryable error codes. https://github.com/apache/fineract/pull/3592 FINERACT-2000: Clean-up retryable error codes by marta-jankovics · Pull Request #3592 · apache/fineract github.com
The goal was that based on the response HTTP code, the caller should be able to decide if the requests worth trying again. Failed requests, that the caller can retry with a NEW idempotency key will return 409 Conflict from now on. Fineract also retries these requests internally (how many times, is configured by resilience4j.retry.instances) In case the internal retry runs out of options, the request will fail with response code 409. What are these cases: Optimistic locking. Use-case: more than one thread is trying to modify the same entity concurrently and the entity is versioned (technically, it has a @Version annotated property). The save process may fail with a JPA, or with a database error, both cases are handled. Previously, this returned 500 Server Error. Pessimistic locking. Use-case: Closure of Business jobs are running and the entity is explicitly hard locked by the framework. Currently implemented for Loan only. For this special case, the response code was 409 before, so no change here. But now any existing or upcoming use-case of pessimistic locking scenarios will be handled. Deadlock. Use-case: for example, two batches try to perform operations on the same entities but in different order so the two threads are waiting for each other. This case was not handled at all, so the response code was unpredictable, 500 Server Error or 403 Forbidden or something else. There is another type of retryable use-cases, for which the caller should retry the request with the SAME idempotency key, will now return 425 Too Early (RFC 8470). Fineract also retries this type of failure internally, depending on the configuration. Use-case: the process - with the same idempotency key - was already started by a different thread and the status of the command is currently IN PROGRESS. It can especially occur for jobs and other async requests (or for any process if more than one instance can send the same request simultaneously). Note: this was returning 409 before, which has been changed now, to differentiate from the ’retry with new idempotency key’ response. For more details, please read the story description: https://issues.apache.org/jira/browse/FINERACT-2000. I hope, that this change will help you to design your Fineract environment more efficiently. Thank you for your constructive feedbacks, Marta Jankovics
