Repository navigation
Fix main: the French catalogue, the evening clock flake, and the router advisory - #825
Conversation
`main` has been red on Translation Check since apache#819 merged, and neither apache#819 nor the change it landed beside was wrong on its own — both were green. apache#816 renamed `ON_HOLD_TRANSACTIONS.REASON` to `LOAN`, because the column shows the loan the funds are held against and never held a reason. apache#819 was authored before that and translated the key as it then stood. Git merged the two cleanly: they touch different keys in different files, so there was nothing to conflict. The result is a catalogue that disagrees with `en.json` 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. So `Motif` becomes `Prêt` — a retranslation rather than a rename, since the column means something else now. The same merge left the sixteen keys from apache#817's password and access work untranslated, for the same reason: that branch predated `fr.json` existing, so there was no French file for it to add them to. They are translated here, which takes `fr` to 2763/2763, and the coverage baseline is refreshed so the ratchet holds the gain rather than the old floor. `app.language.fr` is added to `hi.json` too. apache#819 registered French in the language pickers and gave `en` and `fr` a label for it, so a Hindi user was offered the new language under a raw translation key.
Unit Tests and two of the three real-Fineract E2E shards have been failing on `main`, and
not because of anything that merged. They fail on the clock. Every run started before
17:45 UTC is green; both runs started after 18:26 UTC are red, with the same four jobs:
19:07Z apache#817 merge 4 failures
18:26Z apache#819 merge 4 failures
15:02Z all green
14:23Z apache#816 merge all green
12:46Z all green
`Asia/Kolkata` is UTC+5:30, so its date turns over at 18:30 UTC. `AppConfig.tenantTimezone`
defaults to it, which is the zone the dialog resolves today in — deliberately, because the
platform validates `activate` against a date it stamped in the tenant's zone, not the
browser's. Two cases here asserted `component.actionDate()` against
`toIsoDate(new Date())`, the browser's today. For five and a half hours each evening those
are different days, the component answers the tenant's and the assertion wants the
browser's, and the job goes red:
AssertionError: expected '2026-10-20' to be '2026-10-21'
The spec's own header claimed these cases "hold whatever time it is". They now do, by
pinning the platform's clock through `recordServerTime` instead of reading the real one.
It is pinned 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, which is the disagreement they exist for. Verified green at
`Asia/Kolkata`, `UTC`, `America/New_York`, `Etc/GMT-10`, `Etc/GMT+12` and
`Pacific/Kiritimati`, and failing 4 of 5 when the component is reverted to the browser
clock — before this it caught that regression only between 18:30 and midnight UTC.
The relative dates move with it: `offsetFromToday` stepped the browser's clock with local
getters, so the floor cases drifted on the same boundary. They are ISO arithmetic from the
pinned date now, anchored at midday UTC so no offset can shift them.
The two E2E shards are the same disagreement — shard 1 holds `group-membership.spec.ts`
and shard 3 `tenant-date-defaults-backend.spec.ts`, both written for this window — but
they are not addressed here. Reproducing them needs a live platform inside the window, and
a guess at an E2E spec is not worth making.
7382713 to
af97825
Compare
E2E — mocked backend🎭 E2E Tests✅ All green — 427 passed · 0 failed · 1 skipped, across 40 spec files in 8m 5s. By spec file
All 428 tests — click to expand
Slowest 10 — what the shard counts should be tuned against
📼 Download the HTML report, videos and traces — see the Generated by run 39626430537 from |
E2E — real Fineract🎭 E2E Tests❌ 6 failing — 151 passed · 6 failed · 14 skipped · 8 flaky, across 50 spec files in 16m 41s. ❌ Failures
|
| Spec | ✅ | ❌ | ⏭️ | 🔒 | Time |
|---|---|---|---|---|---|
| backend.setup.ts | 3 | 0 | 0 | 0 | 6.0s |
| accounting-closure-backend.spec.ts | 1 | 1 | 0 | 0 | 14.7s |
| batch-api-operations.spec.ts | 5 | 0 | 0 | 0 | 31.0s |
| center-servicing.spec.ts | 2 | 0 | 0 | 0 | 19.0s |
| charge-servicing-backend.spec.ts | 6 | 0 | 0 | 0 | 32.1s |
| client-legal-form-search.spec.ts | 1 | 0 | 0 | 0 | 5.7s |
| client-transfer.spec.ts | 4 | 0 | 0 | 0 | 49.4s |
| collection-sheet.spec.ts | 1 | 0 | 0 | 0 | 7.5s |
| deposit-account-servicing.spec.ts | 3 | 0 | 0 | 0 | 29.8s |
| deposit-lifecycle-backend.spec.ts | 4 | 0 | 0 | 0 | 26.2s |
| deposit-product-configuration.spec.ts | 3 | 0 | 0 | 0 | 19.7s |
| double-submit-backend.spec.ts | 2 | 0 | 0 | 0 | 14.2s |
| form-layout-reflow.spec.ts | 6 | 0 | 0 | 0 | 38.7s |
| group-membership.spec.ts | 3 | 0 | 0 | 0 | 53.3s |
| loan-account-actions.spec.ts | 3 | 0 | 0 | 0 | 26.8s |
| loan-approved-amount-revision.spec.ts | 3 | 0 | 0 | 0 | 23.3s |
| loan-charge-off.spec.ts | 2 | 0 | 0 | 0 | 22.2s |
| loan-flows-non-admin-roles.spec.ts | 2 | 1 | 5 | 0 | 1m 22s |
| loan-product-accounting.spec.ts | 1 | 0 | 0 | 0 | 35.3s |
| loan-repayment-gating.spec.ts | 2 | 0 | 0 | 0 | 10.5s |
| loan-servicing-rbac-backend.spec.ts | 4 | 0 | 0 | 0 | 11.4s |
| loan-servicing.spec.ts | 2 | 0 | 0 | 0 | 20.4s |
| login.spec.ts | 4 | 0 | 0 | 0 | 7.5s |
| oidc-login-backend.spec.ts | 2 | 0 | 0 | 0 | 5.3s |
| parity-screens.spec.ts | 8 | 0 | 0 | 0 | 49.8s |
| rbac-backend-restricted-user.spec.ts | 7 | 0 | 0 | 0 | 41.9s |
| rbac-dead-end-controls.spec.ts | 7 | 0 | 0 | 0 | 41.5s |
| rbac-disabled-flag-backend.spec.ts | 6 | 0 | 0 | 0 | 30.4s |
| rbac-multi-permission.spec.ts | 9 | 0 | 0 | 0 | 1m 9s |
| rbac-office-scoped-user.spec.ts | 6 | 0 | 0 | 0 | 32.6s |
| bulk-import-entity-types.spec.ts | 1 | 0 | 0 | 0 | 9.0s |
| delinquency-configuration.spec.ts | 2 | 0 | 0 | 0 | 17.5s |
| full-demo.spec.ts | 0 | 1 | 0 | 0 | 54.9s |
| interest-rate-charts.spec.ts | 1 | 0 | 0 | 0 | 7.2s |
| loan-lifecycle.spec.ts | 0 | 1 | 3 | 0 | 40.7s |
| loan-schedule-type.spec.ts | 3 | 0 | 0 | 0 | 31.1s |
| rbac-permissionless-user.spec.ts | 4 | 0 | 0 | 0 | 24.4s |
| report-mailing-job.spec.ts | 3 | 0 | 0 | 0 | 20.6s |
| report-parameter-backend.spec.ts | 4 | 0 | 0 | 0 | 24.4s |
| savings-flows-non-admin-roles.spec.ts | 2 | 1 | 4 | 0 | 1m 24s |
| savings-transaction-correction.spec.ts | 1 | 0 | 0 | 0 | 7.7s |
| savings-transaction-gating.spec.ts | 2 | 0 | 0 | 0 | 7.0s |
| share-account-servicing.spec.ts | 2 | 0 | 0 | 0 | 19.0s |
| share-product-accounting.spec.ts | 1 | 0 | 0 | 0 | 25.9s |
| teller-cash-management.spec.ts | 2 | 0 | 0 | 0 | 39.8s |
| tenant-date-defaults-backend.spec.ts | 1 | 0 | 0 | 0 | 7.2s |
| working-capital-loan-actions-backend.spec.ts | 3 | 0 | 0 | 0 | 23.6s |
| working-capital-product-accounting-backend.spec.ts | 2 | 0 | 0 | 0 | 21.2s |
| working-capital-rbac-backend.spec.ts | 2 | 0 | 0 | 0 | 7.8s |
| working-capital-servicing-backend.spec.ts | 3 | 1 | 2 | 0 | 17.5s |
All 171 tests — click to expand
backend.setup.ts
- ✅ seed backend reference data —
2.0s - ✅ seed backend reference data —
2.0s - ✅ seed backend reference data —
2.0s
accounting-closure-backend.spec.ts
- ✅ Accounting closures against Fineract › a closed period reads as Closed, and the platform refuses a posting inside it —
7.8s - ❌ Accounting closures against Fineract › the form keeps the user on the page and names the reason when Fineract refuses —
6.8s(retried 2×)
batch-api-operations.spec.ts
- ✅ Batch API Operations against Fineract › runs the sample batch scenario — create client, create loan, add and read back a charge —
6.5s - ✅ Batch API Operations against Fineract › shows a parse error instead of submitting when the batch input is not valid JSON —
7.5s - ✅ Batch API enclosingTransaction semantics against Fineract › rolls back the earlier steps when enclosingTransaction is true and a later step fails —
5.5s - ✅ Batch API enclosingTransaction semantics against Fineract › does not roll back the earlier steps when enclosingTransaction is false and a later step fails —
5.9s - ✅ Batch API Operations on a mobile viewport against Fineract › the sample batch scenario is reachable and works by touch at mobile width —
5.6s
center-servicing.spec.ts
- ✅ Center servicing › a center is activated, staffed and given a group —
13.0s - ✅ Center servicing › notes are recorded against the center —
6.0s
charge-servicing-backend.spec.ts
- ✅ loan charge servicing › waives a loan charge, and the platform records the waiver —
6.5s - ✅ loan charge servicing › cannot reverse a waiver: the platform answers 500, not a business rule —
631ms - ✅ loan charge servicing › offers no Pay on a charge the platform will not let be paid —
5.7s - ✅ loan charge servicing › adjusts a loan charge to a smaller amount —
6.6s - ✅ savings charge servicing › pays a savings charge with the amount and due date the platform demands —
6.1s - ✅ savings charge servicing › carries an active flag, which is what gates Inactivate —
6.6s
client-legal-form-search.spec.ts
- ✅ Client list: legal form filtering › an entity client appears in the main client list —
5.7s
client-transfer.spec.ts
- ✅ Client transfer between offices › a proposed transfer is held until the destination accepts, and then the client moves —
12.2s - ✅ Client transfer between offices › a rejected transfer leaves the client on hold, and withdrawing is the way back —
13.0s - ✅ Client transfer between offices › a client can be transferred in one step when the user may act for both offices —
11.8s - ✅ Client staff assignment › an officer can be assigned and then removed —
12.5s
collection-sheet.spec.ts
- ✅ Collection Sheet › scopes staff to the office, sends the choice, and reports an empty sheet —
7.5s
deposit-account-servicing.spec.ts
- ✅ Term deposit account servicing › an account is approved, activated and closed before maturity —
12.5s - ✅ Term deposit account servicing › a deposit is recorded, listed, and reversed without leaving the list —
10.3s - ✅ Term deposit account servicing › an application can be rejected instead of approved —
7.0s
deposit-lifecycle-backend.spec.ts
- ✅ fixed deposit products › carry the rate the user typed, not a hidden default —
5.8s - ✅ an active fixed deposit account › shows its balance and maturity figures —
5.7s - ✅ an active fixed deposit account › can be closed into the client savings account —
7.8s - ✅ an active fixed deposit account › can have a charge added to it —
6.9s
deposit-product-configuration.spec.ts
- ✅ Deposit product configuration › a fixed deposit product survives being edited —
6.5s - ✅ Deposit product configuration › a recurring deposit product can be created at all —
6.3s - ✅ Deposit product configuration › a savings product carries its accounting configuration —
6.8s
double-submit-backend.spec.ts
- ✅ A double-click submits once › a repayment is recorded once, not twice —
7.0s - ✅ A double-click submits once › a client is created once, not twice —
7.2s
form-layout-reflow.spec.ts
- ✅ form layout at the narrow viewport › Create GL Account gives every field a usable width at 320px —
5.8s - ✅ form layout at the narrow viewport › Create Loan gives every field a usable width at 320px —
5.6s - ✅ form layout at the narrow viewport › Create Office gives every field a usable width at 320px —
5.6s - ✅ form layout at the narrow viewport › Create Staff gives every field a usable width at 320px —
5.3s - ✅ form layout at the narrow viewport › no page-level horizontal scroll at 320px —
10.6s - ✅ form layout at the wide viewport › Create GL Account still uses more than one column at 1280px —
5.8s
group-membership.spec.ts
- ✅ Group membership and lifecycle › a group is activated, staffed, given members and a committee, then emptied —
22.5s - ✅ Group membership and lifecycle › notes are recorded against the group and can be removed again —
10.0s - ✅ Group membership and lifecycle › an empty group is closed with a reason, and a group with members is refused —
20.8s
loan-account-actions.spec.ts
- ✅ Loan account lifecycle actions › new action menu items appear only for active loans —
7.6s - ✅ Loan account lifecycle actions › undo disbursal shows a confirm dialog and reverts the loan to Approved —
10.1s - ✅ Loan account lifecycle actions › write off requires confirmation and moves the loan out of Active status —
9.1s
loan-approved-amount-revision.spec.ts
- ✅ Loan approved and available-disbursement amount revision › revises the approved amount on an active, partially-disbursed loan —
7.4s - ✅ Loan approved and available-disbursement amount revision › revises the available disbursement amount, which also changes the approved amount —
8.0s - ✅ Loan approved and available-disbursement amount revision › shows the platform’s own refusal, not a generic validation message —
7.9s
loan-charge-off.spec.ts
- ✅ Loan servicing commands › charges a loan off through the UI and reverses it —
11.9s - ✅ Loan servicing commands › records a goodwill credit through the shared transaction form —
10.3s
loan-flows-non-admin-roles.spec.ts
- ✅ a loan taken through four separated duties, every account built in the UI › an administrator builds the four roles and accounts through the forms —
40.4s(retried 2×) - ✅ a loan taken through four separated duties, every account built in the UI › the officer books the application and is not offered approval of their own loan —
15.4s(retried 2×) - ❌ a loan taken through four separated duties, every account built in the UI › the approver, differing from the officer in one code, is offered it and approves —
26.4s(retried 2×) - ⏭️ a loan taken through four separated duties, every account built in the UI › the approver is not offered disbursement of the loan they just approved —
0ms(retried 2×) - ⏭️ a loan taken through four separated duties, every account built in the UI › the disburser, holding only DISBURSE_LOAN, completes the payout end to end —
0ms(retried 2×) - ⏭️ a loan taken through four separated duties, every account built in the UI › and the same route now refuses an UPDATE_LOAN holder, as the platform does —
0ms(retried 2×) - ⏭️ a loan taken through four separated duties, every account built in the UI › a command with no mapped code is left to the platform rather than guessed at —
0ms(retried 2×) - ⏭️ a loan taken through four separated duties, every account built in the UI › a repayment duty reaches its own form, and records a repayment —
0ms(retried 2×)
loan-product-accounting.spec.ts
- ✅ Loan product accounting › a cash-accounting product is configured, round-trips on edit, and posts to the ledger —
35.3s
loan-repayment-gating.spec.ts
- ✅ Repayment is offered only where the platform allows it › withheld on a loan awaiting approval, offered once it is active —
10.1s - ✅ Repayment is offered only where the platform allows it › the platform refuses a repayment on a loan awaiting approval —
395ms
loan-servicing-rbac-backend.spec.ts
- ✅ loan servicing and charge command permissions, on the platform › each command is authorised by the code the UI declares for it —
5.4s - ✅ loan servicing and charge command permissions, on the platform › no portfolio write code authorises any of its entity commands —
5.6s - ✅ loan servicing and charge command permissions, on the platform › the deferred-income adjustments are not commands at loan level —
168ms - ✅ loan servicing and charge command permissions, on the platform › the deferred-income adjustments are commands on one transaction —
185ms
loan-servicing.spec.ts
- ✅ Loan servicing: notes and transaction adjustment › notes can be added and removed, with a confirm dialog on delete —
9.3s - ✅ Loan servicing: notes and transaction adjustment › a repayment transaction can be viewed and adjusted with a corrected amount —
11.1s
login.spec.ts
- ✅ Login › login page displays correctly —
1.8s - ✅ Login › login form has required fields —
2.1s - ✅ Login › submit button is disabled when form is empty —
1.8s - ✅ Login › submit button is enabled when form is filled —
1.8s
oidc-login-backend.spec.ts
- ✅ identity-provider route against a real Fineract › is offered beside the password form, and pressing it sends nothing to Fineract —
1.8s - ✅ identity-provider route against a real Fineract › a real password sign-in still gets a session with the route offered —
3.5s
parity-screens.spec.ts
- ✅ Screens added for platform parity › a manual journal entry can be read whole and reversed —
6.3s - ✅ Screens added for platform parity › an entry that is already reversed is not offered again —
5.3s - ✅ Screens added for platform parity › a report definition can be created, edited and deleted; a core one cannot —
6.6s - ✅ Screens added for platform parity › a core report opens read-only with only its in-use setting —
5.6s - ✅ Screens added for platform parity › a pending loan is approved from the queue, in a batch —
7.3s - ✅ Screens added for platform parity › a fixed deposit is listed as a deposit, not as a savings account —
5.6s - ✅ Screens added for platform parity › an office has a screen, and it carries its custom fields —
5.6s - ✅ Screens added for platform parity › a savings account carries notes, and the note survives a reload —
7.5s
rbac-backend-restricted-user.spec.ts
- ✅ a genuinely restricted Fineract user › holds exactly the permissions their role was granted —
173ms - ✅ a genuinely restricted Fineract user › reaches the screen their permission covers —
6.1s - ✅ a genuinely restricted Fineract user › is refused a screen their permission does not cover, by URL and by the backend —
5.9s - ✅ a genuinely restricted Fineract user › is refused a write screen they can read the list for, and the write itself —
7.9s - ✅ a genuinely restricted Fineract user › is not offered the actions it would be refused for —
4.9s - ✅ a genuinely restricted Fineract user › is shown an action it cannot take, disabled and saying what it needs —
6.8s - ✅ a genuinely restricted Fineract user › the superuser the rest of the suite uses is unaffected —
10.1s
rbac-dead-end-controls.spec.ts
- ✅ a client's account tables › withhold the link, but not the number, from a user who cannot open the account —
5.9s - ✅ a client's account tables › keep the link for a user who holds READ_LOAN —
6.4s - ✅ the office transactions list › withholds Create from a reader, and the route refuses it too —
7.2s - ✅ the office transactions list › offers Create to an administrator —
5.4s - ✅ the office transactions list › refuses the list at the door for the code the platform does not check —
5.2s - ✅ a group's member list › names the member without linking when the reader cannot open clients —
5.8s - ✅ a group's member list › keeps the link for a reader who holds READ_CLIENT —
5.7s
rbac-disabled-flag-backend.spec.ts
- ✅ rbacEnabled: false, with a user who holds only READ_CLIENT › is shown the whole navigation, including modules their role does not cover —
3.9s - ✅ rbacEnabled: false, with a user who holds only READ_CLIENT › is admitted by the route guard to a screen their role does not cover —
8.1s - ✅ rbacEnabled: false, with a user who holds only READ_CLIENT › is still refused by Fineract, which the flag does not reach —
576ms - ✅ rbacEnabled: false, with a user who holds only READ_CLIENT › is told the list is beyond their role, and not offered a retry that cannot succeed —
6.1s - ✅ rbacEnabled: false, with a user who holds only READ_CLIENT › gets the same treatment on a second refused list, not a one-screen fix —
5.6s - ✅ rbacEnabled: false, with a user who holds only READ_CLIENT › still loads the list their role does cover, with no failure state at all —
6.2s
rbac-multi-permission.spec.ts
- ✅ a route declaring more than one permission code (OR semantics) › is admitted by either declared code alone —
6.2s - ✅ a route declaring more than one permission code (OR semantics) › is admitted by the other declared code alone —
5.7s - ✅ a route declaring more than one permission code (OR semantics) › is refused when holding neither declared code, by the router and by the backend —
6.0s - ✅ ALL_FUNCTIONS_READ, against the real Fineract permission catalogue › reaches read screens across modules it holds no specific code for —
10.8s - ✅ ALL_FUNCTIONS_READ, against the real Fineract permission catalogue › is refused every write screen, and the writes themselves —
8.8s - ✅ a restricted session across a real page reload › keeps the same permission boundary after reloading, not just after a fresh login —
12.3s - ✅ a second real action-level gate, distinct from loan repayment › is shown the Approve action disabled and naming what it needs, refused by the backend too —
6.7s - ✅ Security module writes (users, roles), against the real backend › reaches the list screens but is refused the write screens —
12.7s - ✅ Security module writes (users, roles), against the real backend › is refused creating a user and modifying a role, by the backend itself —
245ms
rbac-office-scoped-user.spec.ts
- ✅ an account scoped to a branch office › differs from a head-office account in office alone, not in permissions —
347ms - ✅ an account scoped to a branch office › is shown only its own office in the client list, and told which office it is in —
6.1s - ✅ an account scoped to a branch office › sees a shorter list than an identically-permissioned head-office account —
5.6s - ✅ an account scoped to a branch office › is refused another office’s client by the platform, and told so once —
6.1s - ✅ an account scoped to a branch office › can still open the record that is in its own office —
5.7s - ✅ an account scoped to a branch office › is not offered an edit it would be refused for on the Offices screen —
8.8s
bulk-import-entity-types.spec.ts
- ✅ every offered entity type is one the platform accepts —
9.0s
delinquency-configuration.spec.ts
- ✅ creates a delinquency range, then edits it —
9.1s - ✅ creates a delinquency bucket from the ranges the template offers —
8.4s
full-demo.spec.ts
- ❌ Full feature demo recording › walk through loan schedule type, lifecycle, custom fields, collateral, and disbursement —
54.9s(retried 2×)
interest-rate-charts.spec.ts
- ✅ lists charts without a server error —
7.2s
loan-lifecycle.spec.ts
- ❌ Loan lifecycle: creation, approval, disbursement › create, approve, and disburse a Cumulative loan —
40.7s(retried 2×) - ⏭️ Loan lifecycle: creation, approval, disbursement › create, approve, and disburse a Progressive loan —
0ms(retried 2×) - ⏭️ Loan lifecycle: creation, approval, disbursement › an approved loan can be returned to pending approval —
0ms(retried 2×) - ⏭️ Loan lifecycle: creation, approval, disbursement › the delinquency tab reads a real loan, and the empty data tabs stay hidden —
0ms(retried 2×)
loan-schedule-type.spec.ts
- ✅ Loan Schedule Type (Cumulative vs Progressive) › loan products list shows a schedule type chip per product —
7.8s - ✅ Loan Schedule Type (Cumulative vs Progressive) › create a Progressive loan product end-to-end and verify it round-trips —
13.3s - ✅ Loan Schedule Type (Cumulative vs Progressive) › loan creation shows the schedule type badge for a Progressive product —
10.0s
rbac-permissionless-user.spec.ts
- ✅ an account whose role grants nothing › is authenticated by Fineract and authorized by it for nothing —
833ms - ✅ an account whose role grants nothing › is signed in and landed on a screen rather than stranded at the login form —
5.5s - ✅ an account whose role grants nothing › is offered no permission-gated module, and refused each one by URL and by Fineract —
12.5s - ✅ an account whose role grants nothing › is left a navigation whose entries actually work —
5.5s
report-mailing-job.spec.ts
- ✅ report mailing job creation › is no longer refused for a missing parameter —
6.3s - ✅ report mailing job creation › the payload carries the locale and the schedule —
6.4s - ✅ report mailing job creation at the narrow viewport › every field is reachable and the job still saves at 320px —
7.9s
report-parameter-backend.spec.ts
- ✅ Dynamic report parameters against Fineract › keeps the parameter form available when a report has cascading lookups —
5.2s - ✅ Dynamic report parameters against Fineract › changing Office changes the Client Listing row set —
6.7s(retried 2×) - ✅ Cascading report parameters against Fineract › sends the parent value to the child lookup and clears the child when it changes —
7.6s - ✅ Chart reports against Fineract › renders a chart report as a chart rather than a table —
4.9s
savings-flows-non-admin-roles.spec.ts
- ✅ a savings account taken through four separated duties, every account built in the UI › an administrator builds the five roles and accounts through the forms —
49.6s(retried 2×) - ✅ a savings account taken through four separated duties, every account built in the UI › the officer books the application and is not offered approval of it —
8.8s(retried 2×) - ❌ a savings account taken through four separated duties, every account built in the UI › the approver, differing in one code, is offered it and approves —
25.2s(retried 2×) - ⏭️ a savings account taken through four separated duties, every account built in the UI › the activator activates, and cannot take a deposit —
0ms(retried 2×) - ⏭️ a savings account taken through four separated duties, every account built in the UI › the teller, holding only the transaction codes, records a deposit end to end —
0ms(retried 2×) - ⏭️ a savings account taken through four separated duties, every account built in the UI › the cash-withdrawal control asks for the cash code, not the application one —
0ms(retried 2×) - ⏭️ a savings account taken through four separated duties, every account built in the UI › the transaction route refuses an UPDATE_SAVINGSACCOUNT holder, as the platform does —
0ms(retried 2×)
savings-transaction-correction.spec.ts
- ✅ Savings transaction correction › a deposit is reversed and a hold is released —
7.7s
savings-transaction-gating.spec.ts
- ✅ Savings transactions are offered only on an active account › withheld while awaiting approval, offered once active —
6.7s - ✅ Savings transactions are offered only on an active account › the platform refuses a deposit on an account awaiting approval —
253ms
share-account-servicing.spec.ts
- ✅ Share account servicing › an account is approved, activated, traded and closed —
12.9s - ✅ Share account servicing › an application can be rejected —
6.2s
share-product-accounting.spec.ts
- ✅ Share product accounting › a share product is mapped to equity and round-trips on edit —
25.9s
teller-cash-management.spec.ts
- ✅ Teller cash management › a cashier is listed, receives an allocation, and settles cash back —
27.0s - ✅ Teller cash management › settling more than the cashier holds is refused and the form stays usable —
12.8s
tenant-date-defaults-backend.spec.ts
- ✅ Date defaults come from the platform, not the browser › a client can be created while the browser is a day ahead —
7.2s
working-capital-loan-actions-backend.spec.ts
- ✅ Working Capital loan actions, against a real Fineract › charges off an active loan, and then offers only the undo —
8.7s - ✅ Working Capital loan actions, against a real Fineract › credits the borrower with a goodwill credit, and the balance falls —
6.4s - ✅ Working Capital loan actions, against a real Fineract › writes the loan off, which closes it and opens the recovery path —
8.5s
working-capital-product-accounting-backend.spec.ts
- ✅ Working Capital product accounting, on the platform › configures the accrual rule and its twelve accounts, and the platform accepts it —
15.5s - ✅ Working Capital product accounting, on the platform › prefills a configured product and re-saves it without blanking anything —
5.7s
working-capital-rbac-backend.spec.ts
- ✅ Working Capital command permissions, on the platform › each command is authorised by the code the UI declares for it —
5.4s - ✅ Working Capital command permissions, on the platform › UPDATE_WORKINGCAPITALLOAN authorises none of them —
2.4s
working-capital-servicing-backend.spec.ts
- ✅ transaction corrections › undoes a repayment, and the platform marks it reversed —
6.0s(retried 2×) - ✅ transaction corrections › offers no correction on the disbursement, which the platform refuses by type —
5.3s(retried 2×) - ✅ transaction corrections › adjusts a repayment, which reverses it and books the new amount —
5.9s(retried 2×) - ❌ charge adjustment › adjusts a charge, and the outstanding amount follows —
259ms(retried 2×) - ⏭️ custom datatables › adds, edits and deletes a row of a multi-row table on the loan —
0ms(retried 2×) - ⏭️ custom datatables › creates a loan that a create-time check would otherwise refuse —
0ms(retried 2×)
Slowest 10 — what the shard counts should be tuned against
| Test | Spec | Time |
|---|---|---|
| Full feature demo recording › walk through loan schedule type, lifecycle, custom fields, collateral, and disbursement | full-demo.spec.ts |
54.9s |
| a savings account taken through four separated duties, every account built in the UI › an administrator builds the five roles and accounts through the forms | savings-flows-non-admin-roles.spec.ts |
49.6s |
| Loan lifecycle: creation, approval, disbursement › create, approve, and disburse a Cumulative loan | loan-lifecycle.spec.ts |
40.7s |
| a loan taken through four separated duties, every account built in the UI › an administrator builds the four roles and accounts through the forms | loan-flows-non-admin-roles.spec.ts |
40.4s |
| Loan product accounting › a cash-accounting product is configured, round-trips on edit, and posts to the ledger | loan-product-accounting.spec.ts |
35.3s |
| Teller cash management › a cashier is listed, receives an allocation, and settles cash back | teller-cash-management.spec.ts |
27.0s |
| a loan taken through four separated duties, every account built in the UI › the approver, differing from the officer in one code, is offered it and approves | loan-flows-non-admin-roles.spec.ts |
26.4s |
| Share product accounting › a share product is mapped to equity and round-trips on edit | share-product-accounting.spec.ts |
25.9s |
| a savings account taken through four separated duties, every account built in the UI › the approver, differing in one code, is offered it and approves | savings-flows-non-admin-roles.spec.ts |
25.2s |
| Group membership and lifecycle › a group is activated, staffed, given members and a committee, then emptied | group-membership.spec.ts |
22.5s |
📼 Download the HTML report, videos and traces — see the playwright-report-backend artifact.
Generated by run 39626430537 from 8350ba1. The run executed a fork branch, so treat its contents as unverified.
🔄 What this change talks toNo application TypeScript files changed, so there is nothing to draw. Generated by run 39626430528 from |
…advisory
Security Audit and the GA Readiness Gate both fail on `main` for one reason:
@angular/router 22.0.0 - 22.2.0
Severity: high
Denial of Service via Unmatched Empty-Path Outlet Route Matching in SSR
Denial of Service via RouterLink Query Parameter Retention in SSR
fix available — 22.2.3
`npm audit --audit-level=high --omit=dev` is the audit job outright, and `ga:check`
counts the same finding as its one *blocking* failure ("1 blocking failure(s)"); the
adapter-boundary backlog it also reports is advisory and pre-existing. Both go green on
this upgrade, and the production tree is now at 0 vulnerabilities.
Worth being precise about the exposure, because it is not what the severity suggests:
both advisories are server-side rendering denial of service, and this application has no
`@angular/ssr` and does not render on a server. There was no live exposure to either.
The upgrade is to clear a gate that is right to block on a high-severity advisory in the
production tree, not to close a hole that was open.
The whole Angular family moves together because it has to: the packages peer-depend on
their own exact version, so `@angular/router` alone cannot move. The nine exact pins go
to 22.2.3, and `@angular/cdk` follows its own caret to 22.2.4.
The lock is regenerated rather than amended. npm's incremental resolver refuses the
upgrade against the existing lock — it holds `@angular/platform-browser@22.2.0` from the
lock while the root asks for 22.2.3 and reports `ERESOLVE`, whichever subset of the family
is named on the command line. `--legacy-peer-deps` is not an option here: the Dependency
Integrity job exists to forbid exactly that. A clean resolve is what npm will accept, and
it re-floats every caret range to its newest member, so 156 packages move in all — among
them vitest, prettier, the angular-eslint plugins, playwright and the OpenAPI generator,
each of which gates a job. Nothing leaves a range the project already declared.
Verified against the gates those moves could break, rather than on the Angular bump alone:
`npm ci` resolves the lock clean, 0 production vulnerabilities, `ga:check` 10/11 with no
blocking failure, `lint:prune` 0 errors leaving `eslint-suppressions.json` untouched (the
plugin bump found nothing new), `format:check` clean on every tracked file, both
`tsconfig.app.json` and `tsconfig.e2e.json` type-clean, `api:surface` unchanged at 145
services and 642 operations, and the unit suite 314 files / 2589 tests green.
mainis red. Six jobs fail across the two causes below, plus a dependency advisory. This fixes Translation Check, Unit Tests, Security Audit and the GA Readiness Gate, and diagnoses the two E2E shards it does not fix.Not caused by what merged
Worth saying first, because it looked like a bad merge: no merged change is at fault for the clock failures. Lining the recent runs up by start time:
741b3075(#817 merge)7f7e55bc(#819 merge)41201a01c2cc7a13(#816 merge)bce5f224(#819 branch head)2f663f29144f2880Every run started before 17:45 UTC is green; both runs started after 18:26 UTC are red, with the same four jobs.
Asia/Kolkatais UTC+5:30, so its date turns over at 18:30 UTC — andAppConfig.tenantTimezonedefaults to it.1. Translation Check — a clean merge of two correct changes
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.REASONtoLOAN, 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:MotifbecomesPrê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 takesfrto 2763/2763, with the coverage baseline refreshed so the ratchet holds the gain instead of the old floor.app.language.fris added tohi.jsonas well: #819 registered French in the language pickers and labelled it forenandfr, so a Hindi user was offered the new language under a raw translation key.2. Unit Tests — a latent flake, now deterministic
Two cases in
group-action-dialog.component.test.tsassertedcomponent.actionDate()againsttoIsoDate(new Date())— the browser's today. The dialog resolves the tenant's today, deliberately, because the platform validatesactivateagainst a date it stamped in the tenant's zone. For five and a half hours each evening those are different days: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
recordServerTimerather than reading the real one — and pinning it inside the window that was breaking them (20:00Z on the 15th, already the 16th inAsia/Kolkata), so the cases assert the tenant's date against a browser that would say the 15th. That is the disagreement they exist for.offsetFromTodaymoved 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.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. Confirmed on CI: Unit Tests passed on this branch at 23:51 UTC, inside the window that had been failing.
3. Security Audit and the GA Readiness Gate — the router advisory
Both fail for one reason:
npm audit --audit-level=high --omit=devis the audit job outright, andga:checkcounts the same finding as its one blocking failure; the adapter-boundary backlog it also reports is advisory and pre-existing. Both go green, and the production tree is now at 0 vulnerabilities.Worth being precise about the exposure, because it is not what the severity suggests: both advisories are server-side rendering denial of service, and this application has no
@angular/ssrand does not render on a server. There was no live exposure to either. The upgrade clears a gate that is right to block on a high-severity advisory in the production tree; it does not close a hole that was open.The whole Angular family moves together because it has to — the packages peer-depend on their own exact version, so
@angular/routercannot move alone. The nine exact pins go to 22.2.3 and@angular/cdkfollows its own caret to 22.2.4.The lock is regenerated rather than amended, and that is the part worth reviewing. npm's incremental resolver refuses this upgrade against the existing lock — it holds
@angular/platform-browser@22.2.0from the lock while the root asks for 22.2.3 and reportsERESOLVE, whichever subset of the family is named on the command line.--legacy-peer-depsis not an option: the Dependency Integrity job exists to forbid exactly that. A clean resolve is what npm accepts, and it re-floats every caret range to its newest member, so 156 packages move in all — among them vitest, prettier, the angular-eslint plugins, playwright and the OpenAPI generator, each of which gates a job. Nothing leaves a range the project already declared, and the gates those moves could break were checked individually:angular-eslint22.5.0 → 22.6.0,eslint-plugin-security4.0.1 → 4.2.0lint:prune0 errors,eslint-suppressions.jsonuntouched — no new findingsprettier3.9.9 → 3.9.10format:checkclean on every tracked filevitest5.0.3 → 5.0.5,jsdom30.1.2 → 30.1.3@openapitools/openapi-generator-cli2.41.0 → 2.42.0generate-api→ no drift; the generator jar is pinned at 7.20.0 inopenapitools.json, independent of the CLIplaywright1.64.0 → 1.64.1npm ciresolves it clean4. The two E2E shards — same cause as §2, not fixed here
Shard 1 holds
group-membership.spec.ts, whose own comment reads "this run is UTC in CI against a tenant onAsia/Kolkata, which are different days after 18:30". Shard 3 holdstenant-date-defaults-backend.spec.ts, which exists for precisely this defect and moves the browser clock a day forward to provoke it.This branch's own run sharpened the evidence: shard 3/3 passed when it ran at 02:07 UTC, and shard 1/3 failed when it ran at 19:19 UTC — the two shards, same commit, opposite results, split by the window.
They are left alone deliberately. Whether the fault is in those specs or in a residual browser-clock path in the application is exactly what a reproduction inside the window would tell us, and a guess at an E2E spec is not worth making. 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.
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 where10:00Zis 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.Checks
UTC, atAmerica/New_Yorkand atEtc/GMT-10;test:mfegreen — all three passes the job runsnpm ciclean, 0 production vulnerabilities,ga:check10/11 with 0 blocking failureslint:prune0 errors with the suppressions ratchet unchanged,format:checkclean,tsconfig.app.jsonandtsconfig.e2e.jsontype-cleanapi:surfaceunchanged at 145 services / 642 operations;generate-apiproduces no drifthi.jsonis a two-line diff: only the one missing label, with the file's existing key order left alone