@tejas chakkarwar joined #fineract. They’re also new to Mifos.
#fineract 2026-03-02
@Vignesh joined #fineract. They’re also new to Mifos.
Hi everyone 👋
I’m Vignesh, a GSoC 2026 aspirant and glad to be part of the Mifos community.
I’m currently exploring Apache Fineract and working on the Frontend MVP (Customer Portal) under the FINERACT-2440 ticket as my initial contribution. My background includes full-stack development using React and Python Flask, and I’m also familiar with Java and MySQL. I’m particularly interested in contributing to scalable and user-focused financial systems.
As I’m new to open-source contributions, I would appreciate guidance on how to get started effectively within the Fineract project. Specifically, I would like to understand:
Thank you, and looking forward to collaborating with everyone!
I’m Vignesh, a GSoC 2026 aspirant and glad to be part of the Mifos community.
I’m currently exploring Apache Fineract and working on the Frontend MVP (Customer Portal) under the FINERACT-2440 ticket as my initial contribution. My background includes full-stack development using React and Python Flask, and I’m also familiar with Java and MySQL. I’m particularly interested in contributing to scalable and user-focused financial systems.
As I’m new to open-source contributions, I would appreciate guidance on how to get started effectively within the Fineract project. Specifically, I would like to understand:
- what contributors should focus on first,
- recommended beginner-friendly tasks or areas to explore,
- and best practices to follow while contributing to the project.
Thank you, and looking forward to collaborating with everyone!
For Fineract GSOC they have set up a matrix space. Note Fineract GSOC is not part of the Mifos Internship programs as its an independent organisation:
> Adam Monsen (meonkeys) [5:27 PM]
> replied to a thread:
>
>
> I'd like us to try Matrix. I've set up a space with three channels: general, gsoc, and random. If you want to give it a shot, first: Create a Matrix account or sign in to an existing account. Next, choose a client. I recommend the web client if you want to use a browser, Element X if you want to use a mobile device, or Element Desktop for a laptop/desktop. Finally, join the "general" channel, and also the others if you like.
>
> This is only an experiment. All channels are public and chat histories are public. This is hosted on matrix.org. You can also use other "home servers", but I'm not yet sure how that works. These channels are not bridged to any other chat/federation networks/platforms.
> Adam Monsen (meonkeys) [5:27 PM]
> replied to a thread:
>
>
> I'd like us to try Matrix. I've set up a space with three channels: general, gsoc, and random. If you want to give it a shot, first: Create a Matrix account or sign in to an existing account. Next, choose a client. I recommend the web client if you want to use a browser, Element X if you want to use a mobile device, or Element Desktop for a laptop/desktop. Finally, join the "general" channel, and also the others if you like.
>
> This is only an experiment. All channels are public and chat histories are public. This is hosted on matrix.org. You can also use other "home servers", but I'm not yet sure how that works. These channels are not bridged to any other chat/federation networks/platforms.
♥️ 1
@samruddhi Kasar joined #fineract. They’re also new to Mifos.
Hi everyone!
I’m a GSoC 2026 contributor interested in the Frontend MVP (POC) [FINERACT-2440] project. I’ve started going through the documentation and discussions, and I’m currently setting up my local environment while exploring the project structure and Self-Service APIs.
I wanted to confirm if this is the right first step, and whether there are any recommended starter tasks or areas I should focus on initially to begin contributing effectively.
Thanks in advance for any guidance!
I’m a GSoC 2026 contributor interested in the Frontend MVP (POC) [FINERACT-2440] project. I’ve started going through the documentation and discussions, and I’m currently setting up my local environment while exploring the project structure and Self-Service APIs.
I wanted to confirm if this is the right first step, and whether there are any recommended starter tasks or areas I should focus on initially to begin contributing effectively.
Thanks in advance for any guidance!
@Victor Romero and @nidhi bhawari, please see https://github.com/apache/fineract/pull/5564#pullrequestreview-3877945513
👀 1
Hi everyone! I just finished migrating the currenciesTest class to Feign and Cucumber as apart of Cucumber testing initiative. Could I kindly get a review when there is time? https://github.com/apache/fineract/pull/5570.
I also have these other tickets waiting for final review. Please take a look whenever is convenient! https://github.com/apache/fineract/pull/5437 https://github.com/apache/fineract/pull/5495 @Aman-Mittal @Adam Saghy @Victor Romero
I also have these other tickets waiting for final review. Please take a look whenever is convenient! https://github.com/apache/fineract/pull/5437 https://github.com/apache/fineract/pull/5495 @Aman-Mittal @Adam Saghy @Victor Romero
✅ 1
Anyone know why the build is breaking? @Adam Saghy? Cc: @Aira Jena
Hi @Adam Monsen (meonkeys)! I did some investigating and saw that at least some of the test failures were due to a timezone mismatch in the Savings tests. I started a PR with details and what should be a fix to the issue. https://github.com/apache/fineract/pull/5574.
Yes @Edward K is right, I checked mine and others failed checks logs and this is the common failure in most.
🙌 1
`develop` branch seems green now
👍 1
@Adam Saghy I think we might have to try again (UTC 7-12), or around 12am+ Asia/Kolkata, since thats when the dates mismatch should happen. If there's nothing my analysis could be wrong I think!
i believe there is some issues around midnight...
👍 1
Ah yes, I think I see what you mean. 3 builds that were ran last succeeded for some reason despite being after 12am Asia time. I'll investigate this too
I think I may have figured out the issue! this explains the original flakiness as well.
Our integration tests run on data from previous tests with @order of 1. however, some of these higher order tests use FeignClientHelper and some use ClientHelper.
SavingsAccountExternalIdTest notably only works when either ClientHelper is used or the date in FeignClientHelper is same day or before current date in UTC. which fails when we are in the 6:30pm-12am UTC time period.
The other issue is that our test shards move the FeignClientHelper around when integration tests are added or removed. there were integration tests added that reorganized our shards to produce this issue. when examined, this seems to map perfectly with when the build failures occurred.
I wrote a detailed writeup here. please take a look when you have time! https://github.com/apache/fineract/pull/5574
Our integration tests run on data from previous tests with @order of 1. however, some of these higher order tests use FeignClientHelper and some use ClientHelper.
SavingsAccountExternalIdTest notably only works when either ClientHelper is used or the date in FeignClientHelper is same day or before current date in UTC. which fails when we are in the 6:30pm-12am UTC time period.
The other issue is that our test shards move the FeignClientHelper around when integration tests are added or removed. there were integration tests added that reorganized our shards to produce this issue. when examined, this seems to map perfectly with when the build failures occurred.
I wrote a detailed writeup here. please take a look when you have time! https://github.com/apache/fineract/pull/5574
👀 1
wow, that is some awesome detective work there @Edward K! This looks good to me and seems low risk... all tests are passing and the patch only affects test code. Merged with thanks.
♥️ 1
Thank you for the kind words adam!! I think I'm definitely hitting my stride after working with the codebase for a while. Also thanks to @Adam Saghy for pinpointing the issue with his PR, which I needed to solve the problem!
right on. Keep an eye on the build for https://github.com/apache/fineract/commit/5bb0b3b387b00a753334e5f7a648eca012d9e167 , there may still be some stuff to figure out there...
👍 1
Yup I just saw that too. I'll take a look and see what I can find!
👍 1
So i made some progress! I was able to pinpoint the issue to an extra transaction being created. however, I have been trying to get more information on exactly what the transactions are.
I tried to replicate the issue locally to get those logs, and went through a few methods, but actually got every test to pass somehow, even after setting up local sharding and making sure i had all the latest changes.
Could I get the real CI/CD to check this test PR (https://github.com/apache/fineract/pull/5588) with some logging added to it? I think it would give me more information to solve the problem.
There is also a small writeup in there with some findings.
I tried to replicate the issue locally to get those logs, and went through a few methods, but actually got every test to pass somehow, even after setting up local sharding and making sure i had all the latest changes.
Could I get the real CI/CD to check this test PR (https://github.com/apache/fineract/pull/5588) with some logging added to it? I think it would give me more information to solve the problem.
There is also a small writeup in there with some findings.
👀 1
I approved workflows to run.
(also moved to Draft as an additional indication this is just an experiment and should not be merged)
👍 1
oh dangit, did that change cancel the build?
please wait while I scroll through tens of thousands of lines of garbage build output...
aborted. I just can't. I downloaded the logs instead and just found "canceled" at the end. I'm guessing the files in `.github/workflows/` are set up so drafts don't trigger checks, or maybe that's just a convention.
rant
I'm not a fan of these complex GH Actions workflows locking us into their platform and doing different things than we can easily/realistically/reliably do locally. ref1 ref2 ref3 . I think the issues run deeper than GH Actions vs. local, too (e.g. the tests got some jank).
/rant
aborted. I just can't. I downloaded the logs instead and just found "canceled" at the end. I'm guessing the files in `.github/workflows/` are set up so drafts don't trigger checks, or maybe that's just a convention.
rant
I'm not a fan of these complex GH Actions workflows locking us into their platform and doing different things than we can easily/realistically/reliably do locally. ref1 ref2 ref3 . I think the issues run deeper than GH Actions vs. local, too (e.g. the tests got some jank).
/rant
:melting_face: 1
it could have! i've been reading about it to make sure, but I think a retrigger might still be good.
will do
Thanks adam for the helpful reads.
The core issue still seems to be the fact that some tests still rely on each other. and then there’s github to be worried about. workers can be flaky and it becomes hard to test shards when local testing doesn't have sharding as far as I'm aware.
I was doing some brainstorming yesterday and thought of an idea to use a hash partitioning strategy for our integration test sharding. this would keep tests in the same bin whether we add or remove tests. It’s still a work in progress but might help as we migrate to Cucumber.
It definitely has its drawbacks, but I wonder if this is something that has been considered by the community?
The core issue still seems to be the fact that some tests still rely on each other. and then there’s github to be worried about. workers can be flaky and it becomes hard to test shards when local testing doesn't have sharding as far as I'm aware.
I was doing some brainstorming yesterday and thought of an idea to use a hash partitioning strategy for our integration test sharding. this would keep tests in the same bin whether we add or remove tests. It’s still a work in progress but might help as we migrate to Cucumber.
It definitely has its drawbacks, but I wonder if this is something that has been considered by the community?
so the idea is the shards chosen for a given commit would be replicable?
Yes exactly.
So for example if a test1 gets hashed and placed in shard1, it will stay in shard1 since the hash boundaries for it are fixed.
Currently when new tests are added or removed, they all get reassigned round robin to each shard. this strategy would stop that from happening.
The trade offs are that:
1) shards will get rearranged drastically at first.
2) when @order1 or other necessary items for state slowly get migrated to cucumber, a shard might stop working. my plan for this was to just combine with another shard if this happens.
3) when tests are added, they still get added somewhere in the middle of a shard, so state changes from other tests could still affect results. this means it's more useful in integration tests where tests are expected to decrease.
4) shard size might not be perfectly even as they are now.
So for example if a test1 gets hashed and placed in shard1, it will stay in shard1 since the hash boundaries for it are fixed.
Currently when new tests are added or removed, they all get reassigned round robin to each shard. this strategy would stop that from happening.
The trade offs are that:
1) shards will get rearranged drastically at first.
2) when @order1 or other necessary items for state slowly get migrated to cucumber, a shard might stop working. my plan for this was to just combine with another shard if this happens.
3) when tests are added, they still get added somewhere in the middle of a shard, so state changes from other tests could still affect results. this means it's more useful in integration tests where tests are expected to decrease.
4) shard size might not be perfectly even as they are now.
I like it if @Adam Saghy likes it. I'd wager he would
👍 1
On another note, it looks like the build actually passed this time. I think it may have just been a flaky test or github worker issue!
Also other merged builds seem to work now.
Also other merged builds seem to work now.
i liked the round robin because slowly but stadily the incorrectly codependent test were failing and we were fixing it.
my suggestion would be to use business date during all of the tests, so around midnight and timezone issues goes away
my suggestion would be to use business date during all of the tests, so around midnight and timezone issues goes away
👍 1
also if we introduce new shards, the tests are evenly redistributed.
ultimately we should avoid any codependence between tests and fix them to be independent and self configured and reset back to original state after execution
ultimately we should avoid any codependence between tests and fix them to be independent and self configured and reset back to original state after execution
Thanks @Adam Saghy! That makes sense to me. in my view the hashing method was just a bandaid fix anyways. the real problem is the codependent tests, and I agree if we fix that, none of this is a concern.
I'm happy to keep fixing issues as they come up like you said.
I'm happy to keep fixing issues as they come up like you said.
:thankyou: 1
👍 2
Thanks both. @Edward K, (1) does this conclude https://github.com/apache/fineract/pull/5588 then? (2) if you're able to find places to fix the code in the way Ádám S. describes, will you open specific JIRA issues (and PRs as well, if you're willing/able)
👍 1
I think yes on both points. I went ahead and closed the ticket since it is not reproducible (probably just a github worker or flakiness issue)
On the second point, I was personally working on a Savings module core for our Cucumber tests that would initialize/cleanup data to avoid this exact issue.
The blocker for me was FINERACT-2501: https://issues.apache.org/jira/browse/FINERACT-2501. But I believe I have permission to work on this now from @Adam Saghy, so I will make steady progress in the coming weeks/months!
If I see something that I am not able to work on as well, I'll be sure to raise tickets.
Also, from a long term perspective, I am happy to keep working on improving the project. Everyday I learn so much, so it is very exciting!
On the second point, I was personally working on a Savings module core for our Cucumber tests that would initialize/cleanup data to avoid this exact issue.
The blocker for me was FINERACT-2501: https://issues.apache.org/jira/browse/FINERACT-2501. But I believe I have permission to work on this now from @Adam Saghy, so I will make steady progress in the coming weeks/months!
If I see something that I am not able to work on as well, I'll be sure to raise tickets.
Also, from a long term perspective, I am happy to keep working on improving the project. Everyday I learn so much, so it is very exciting!