messere1 commented on PR #6729: URL: https://github.com/apache/rocketmq-dashboard/pull/6729#issuecomment-6272773974
Heads-up on the red **Frontend Build (Node 20)** on 9595e94b: the failure is in `ConsumerPage.test.tsx > highlights inconsistent subscriptions and refreshes the check result`, a file this PR does not touch (the change is confined to `message.tsx`, its own test file, and `translations.ts`). What I could reproduce locally: - On this PR merged with the current `rocketmq-studio` tip (127c47b0), the full `ConsumerPage.test.tsx` suite drops 1–2 timing-sensitive tests per run — the CI-failing one in one run, `keeps the latest client stack when an older request resolves last` in another; the failing subset differs run to run. - On a clean checkout of the tip itself (no PR code) the same suite also drops a test under full-suite load, while the CI-failing test passes in isolation (6.0s) — a load/timing flake on the tip, not a deterministic failure, and not reachable from this change. - On the PR's own base (a92c2314): `ConsumerPage.test.tsx` 56/56, `MessagePageAsyncState.test.tsx` 24/24, `MessagePage.test.tsx` 29/29, `tsc -b`/eslint/Prettier all clean. I don't have permission to re-run the failed job from this side (it needs repo admin rights). The suites this PR actually touches are green on this head, so a re-run of the failed job is all that stands between this and a fully green check run — but if the flake persists it originates on the tip, not here. Happy to help chase the tip-side flake separately if useful. -- 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]
