Hello Marta, This change targets Transactions executed on Savings Accounts? Question is raised because I see that Test Case is for Savings. What about repayments on Loans?
Regards Victor Romero El mar, 2 ene 2024 a las 22:07, Márta Jankovics (<marta.jankov...@dpc.hu>) escribió: > Hi All, > > I’ve created a pull request to clean-up the retryable error codes. > [image: 3592.png] > > FINERACT-2000: Clean-up retryable error codes by marta-jankovics · Pull > Request #3592 · apache/fineract > <https://github.com/apache/fineract/pull/3592> > github.com <https://github.com/apache/fineract/pull/3592> > <https://github.com/apache/fineract/pull/3592> > > 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 > >
