Re: Hello Everyone!! Interested in open source contribution

[Praveen Kumar]

Can anyone please help in providing the starting point? Also, how can I
know which all issues and stories do I need to contribute?

Praveen Kumar,

Software Engineer



On Sun, 17 Dec 2023 at 9:43 AM, Praveen Kumar 
wrote:

> Hi All,
>
> I am Praveen having around 8 years of software development experience in
> fintech and e-commerce domain. Was looking for open source contributions.
> Let me know the good point to start with.
>
> Thanks
>
> Praveen Kumar,
>
> Software Engineer
>
>

Re: http response codes

[VICTOR MANUEL ROMERO RODRIGUEZ]

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 ()
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
> 
> 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
>
>

http response codes

[Márta Jankovics]

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

Quarterly report and our roadmap

[James Dailey]

All - Happy New Year

As PMC chair I will be submitting a quarterly report on Jan 8th or so.  If
you have ideas for that, please discuss them here or on the wiki site…
See draft —>
https://cwiki.apache.org/confluence/display/FINERACT/Fineract+PMC+Reports+to+Apache+Software+Foundation+%28ASF%29+Board

last Quarterly report is here
https://cwiki.apache.org/confluence/display/FINERACT/2023-10+October+Fineract+Report+to+ASF+Board


**Looking back at 2023:

Whilst our technology solution is gaining strength, we have several gaps in
both a collective understanding of a shared roadmap and a model where
multiple significant “contributor groups” are actively developing.  Being a
‘fan’ of the project is very welcome but insufficient for an healthy open
source project.

We also need to do better w our release cycle and keeping dependencies up
to date, to follow code styles and all of the other good practices we’ve
previously noted in our code acceptance.

**Currently:
We are still working on releasing 1.9 and including important improvements
made over the past 15 months.

We are anticipating a release… hopefully very soon.

**Looking forward:
If our ambition was merely a system for microfinance operations serving
less than 1 million clients, then we would still need some small team of
funded devs to maintain it, but since our ambition has greatly expanded
since leaving Mifos, we need much more attention to the architecture and to
the roadmap, and people w enough time to work on this growing and complex
code base.

In early 2024, wearing my other hat as CEO of BaaSFlow, I will convene a
gathering of Community leaders at companies using Fineract and staying
upstream on the latest. I mention that here for transparency.  If there are
other company leaders who wish to be included, please reach out. This is
partly in response to a suggestion by an ASF Board member to create a
"Guild".

We want to solve for having a virtuous cycle, contributors from at least a
few different commercial entities.

Please note the existing roadmap, and make suggestions on list for very
significant code changes.

Wishing you a Happy New Year,

James