Aman-Mittal opened a new pull request, #825: URL: https://github.com/apache/fineract-backoffice-ui/pull/825
`main` is red. Four jobs fail on `741b3075`: Translation Check, Unit Tests, and real-Fineract E2E shards 1/3 and 3/3. This fixes the first two and diagnoses the other two. ## Not caused by what merged The first thing worth saying is that no merged change is at fault for three of the four. Lining the recent runs up by start time: | run start (UTC) | commit | result | | --- | --- | --- | | 19:07 | `741b3075` (#817 merge) | 4 failures | | 18:26 | `7f7e55bc` (#819 merge) | 4 failures | | 15:02 | `41201a01` | all green | | 14:23 | `c2cc7a13` (#816 merge) | all green | | 12:46 | `bce5f224` (#819 branch head) | all green | | 08:04 | `2f663f29` | all green | | 17:41 | `144f2880` | all green | Every run started before 17:45 UTC is green; both runs started after 18:26 UTC are red, with the same four jobs. `Asia/Kolkata` is UTC+5:30, so its date turns over at 18:30 UTC — and `AppConfig.tenantTimezone` defaults to it. ## 1. Translation Check — a clean merge of two correct changes (fixed) This one *is* a merge artefact, and a textbook one: both sides were green and git had nothing to conflict on. #816 renamed `ON_HOLD_TRANSACTIONS.REASON` to `LOAN`, because that column shows the loan the funds are held against and never held a reason. #819 was authored before that and translated the key as it then stood, in a file that did not exist on #816's branch. Different keys, different files, clean merge, broken catalogue — in both directions at once: ``` fr.json defines ON_HOLD_TRANSACTIONS.REASON, which en.json does not — remove it. fr.json covers 2746 keys, down from 2747. ``` `Motif` becomes `Prêt`: a retranslation, not a rename, since the column means something else now. The same merge left #817's sixteen password and access keys untranslated, for the same reason — that branch predated `fr.json`, so there was no French file to add them to. Translated here, which takes `fr` to **2763/2763**, with the coverage baseline refreshed so the ratchet holds the gain instead of the old floor. `app.language.fr` is added to `hi.json` as well: #819 registered French in the language pickers and labelled it for `en` and `fr`, so a Hindi user was offered the new language under a raw translation key. ## 2. Unit Tests — a latent flake, now deterministic (fixed) Two cases in `group-action-dialog.component.test.ts` asserted `component.actionDate()` against `toIsoDate(new Date())` — the *browser's* today. The dialog resolves the *tenant's* today, deliberately, because the platform validates `activate` against a date it stamped in the tenant's zone. For five and a half hours each evening those are different days: ``` AssertionError: expected '2026-10-20' to be '2026-10-21' ``` The component is right and the spec was wrong. The spec's own header claimed these cases "hold whatever time it is"; they now do, by pinning the platform's clock through `recordServerTime` rather than reading the real one — and pinning it *inside* the window that was breaking them (20:00Z on the 15th, already the 16th in `Asia/Kolkata`), so the cases assert the tenant's date against a browser that would say the 15th. That is the disagreement they exist for. `offsetFromToday` moved with it: it stepped the browser's clock with local getters, so the floor cases drifted on the same boundary. ISO arithmetic from the pinned date now, anchored at midday UTC so no offset can shift them. Verified green at `Asia/Kolkata`, `UTC`, `America/New_York`, `Etc/GMT-10`, `Etc/GMT+12` and `Pacific/Kiritimati`; full suite 314 files / 2589 tests green at both `UTC` and `Etc/GMT-10`. Reverting the component to the browser clock fails **4 of 5** cases — before this it caught that regression only between 18:30 and midnight UTC. ## 3. The two E2E shards — same cause, not fixed here Shard 1 holds `group-membership.spec.ts`, whose own comment reads *"this run is UTC in CI against a tenant on `Asia/Kolkata`, which are different days after 18:30"*. Shard 3 holds `tenant-date-defaults-backend.spec.ts`, which exists for precisely this defect and moves the browser clock a day forward to provoke it. Both sit in the shards that fail, both fail only in the evening window, and both are green on every daytime run above. They are left alone deliberately. Reproducing them needs a live platform inside that window, and whether the fault is in those specs or in a residual browser-clock path in the application is exactly what a reproduction would tell us — so a guess at an E2E spec is not worth making. Worth noting that if it is the application, the user-facing bug is real: forms refused between 18:30 and midnight UTC for a Kolkata tenant, the same class as #496 and #798. With this merged, `main` goes green on any run outside the evening window and loses two of the four evening failures. ## Also found, deliberately not touched `platform-date.service.test.ts` → *"prefers the platform clock over the browser clock"* fails at UTC+14 (`Pacific/Kiritimati`): with no tenant timezone configured the service falls back to local rendering, by design, and the case assumes an offset where `10:00Z` is still the 15th. CI runs at UTC, so this has never fired there and is not part of main being red. Left for its own change rather than folded in here. ## Checks - unit suite 314 files / 2589 tests green at `UTC` and at `Etc/GMT-10`; the dialog spec green across six zones - `i18n:check` clean (`fr` 2763/2763, `hi` 2748/2763), `format:check`, `lint` (0 errors), `tsconfig.app.json` type-clean 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
