Aman-Mittal commented on PR #625: URL: https://github.com/apache/fineract-backoffice-ui/pull/625#issuecomment-5849140940
Correcting my previous comment. Two of the rows in that "what was ruled out" table were not sound, and both were mine to get right. **"Reproducible locally: No — 9 passed."** That run used the Fineract image my machine happened to have, built **2026-08-15**. CI pulls `apache/fineract:latest`, built **2026-09-25T21:25Z** — a different digest, six weeks newer. I had tested a backend CI does not run, against a database with hours of accumulated state where CI gets a migration-fresh one. `scripts/e2e-stack.sh` warns about precisely the second half of that, in its own header: > `--fresh` is what CI gets on every run… a database that has accumulated data across local runs hides failures that a migration-fresh one finds immediately. Reach for `--fresh` before concluding that a CI-only failure is CI's fault. **"`apache/fineract:latest` moved mid-session: No."** The reasoning was wrong, not only the conclusion. Showing the image did not change *between* two CI runs does not exonerate the image; it only rules it out as the delta between those two runs. The backend carrying an upstream merge from the previous day remains a candidate on its own. ### Re-tested properly `npm run e2e:stack:fresh` on the current `latest` (`sha256:d72ef39a…`), then the spec: ``` npx playwright test --project=backend e2e/parity-screens.spec.ts 9 passed (1.3m) ``` So it still does not reproduce — but this time under conditions that match CI's image and a fresh volume, which is the first version of that statement worth anything. One difference remains: CI's shard runs other specs against the same Fineract before this one, while I ran the spec alone. The full `backend` project against the same fresh stack is running now and I will report it. Nothing here changes the attribution question — the branch still cannot reach `/tasks/work-queues` — but the evidence I offered for it was bad, and the record should say so. -- 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]
