Aman-Mittal opened a new pull request, #359:
URL: https://github.com/apache/fineract-backoffice-ui/pull/359
The centre activation test failed on CI three attempts running while passing
on every local run. The cause was the wall clock.
## What was happening
Fineract stamps and validates dates in the **tenant's** timezone —
`m_tenants.timezone_id`, which its seed data sets to `Asia/Kolkata`. The
application fills date fields from the **browser's** clock. Between **18:30 and
24:00 UTC** those disagree by a day.
The CI job started at **18:35 UTC** — inside that window. So the browser
offered `15 August` as the activation date for a centre the platform had
already stamped `16 August`, and the platform refused it:
```
error.msg.group.submittedOnDate.after.activation.date
"Submitted on date cannot be after the activation date" args:
[{"value":"2026-08-16"}]
```
A machine already in `Asia/Kolkata` agrees with the tenant and **cannot**
reproduce it. That is why a full 46/46 local run — fresh volume, current image,
file order, one worker — said nothing was wrong, twice.
## The fix
Pin the browser timezone to the tenant's, so the suite is deterministic on
any machine rather than a function of when it starts.
Verified by running the centre spec under three timezones:
| Run | Before | After |
|---|---|---|
| `TZ=UTC` (CI's zone) | **fails** | passes |
| `TZ=America/New_York` | — | passes |
| Host `Asia/Kolkata` | passes | passes |
## What this does not fix
**The harness, not the behaviour.** Defaulting date fields from the browser
rather than the platform affects any deployment whose users are not in the
tenant's timezone — for about five and a half hours a day, real users get
refused for a date they never chose, or worse, get a record accepted with the
wrong day on it.
That is raised separately as **#358**, with this reproduction. The pin
carries a comment saying it should be removed when #358 lands, and that the
suite passing without it is the proof the fix is real. I did not want a harness
change to quietly make a product bug invisible.
## The diagnostic change
The activation step now captures the platform's response instead of only
checking the resulting badge.
A refused activation left the badge on `Pending`, and the assertion reported
nothing beyond `unexpected value " Pending "` — neither what was sent nor why
the platform objected. With the response captured, the very first run named the
validation error outright. That is what turned this from a flake into a
diagnosis, and it is why the change is worth keeping regardless of the timezone
fix.
## Things I ruled out along the way
Recorded because each looked plausible and each was wrong:
- **Caused by #356** — it changes no date, centre or e2e code; only
`config.json`, by adding a key.
- **A Fineract version difference** — CI pulls `apache/fineract:latest`,
which had moved to the 1.16.0-SNAPSHOT image while my local was 1.15.0-132. A
real difference, so I recreated the stack on the new image. Still passed.
- **`FINERACT_DEFAULT_TENANTDB_TIMEZONE_ID=UTC`** as an alternative fix —
not honoured; the tenant stayed `Asia/Kolkata`. Tested before proposing rather
than after.
- **Suite ordering or a polluted database** — the previous two CI-only
failures were both ambient-state problems, so this was the first suspect. A
faithful CI-conditions run passed 46/46.
## Verification
- Centre spec passes under `TZ=UTC`, `TZ=America/New_York` and host IST.
- Full backend suite: 46/46 on a fresh volume, one worker, file order.
- `lint` and `format:check` clean. No production code is touched — the
change is confined to `playwright.config.ts` and one spec.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
