test(index): stabilize flaky enum-filter query.index integration test#16120
test(index): stabilize flaky enum-filter query.index integration test#16120arhxam wants to merge 1 commit into
Conversation
The "should use query.index to filter enum field" test intermittently fails on develop with the retry helper's "Validation failed. Retry...", blocking unrelated PRs. The product<->brand link is created after the products are already indexed, so it triggers an asynchronous re-index of the linked product. waitForIndexedEntities only waits for the brand and link rows, not for that product re-index to be reflected in the catalog. Unlike the sibling brand test (whose filter has an OR title fallback), this filter strictly depends on the link being queryable, so it returns an empty set until the re-index lands. Under CI load that window can exceed the 7.5s retry budget (5 x 1.5s). Align the budget with the 30s waitForIndexedEntities timeout used in the same test. Fixes medusajs#15967
|
|
Thanks for the contribution! Initial automated review looks good. Test-only change (1 file, 14 lines) that raises the fetchAndRetry budget for the enum-filter query.index test from 7.5s to 30s to match the 30s waitForIndexedEntities default (verified in integration-tests/helpers/wait-for-index.ts), addressing an index-sync race under CI load. PR template is complete; assertions are unchanged so it cannot mask a regression. No production code touched, and no security/perf/bug concerns. Missing changeset is acceptable for a test-only change. The explanatory comment does not embed an issue/PR number. Triggered by: new PR opened |
Summary
What — What changes are introduced in this PR?
Stabilizes the intermittently-failing integration test
integration-tests/modules/__tests__/index/query-index.spec.ts› Index engine - Query.index › should use query.index to filter enum field by aligning its final query retry budget with the index-sync wait budget already used in the same test.Why — Why are these changes relevant or necessary?
This test fails intermittently on
developwith the retry helper'sValidation failed. Retry..., which intermittently blocks unrelated PRs (see #15967, e.g. the approved/automerge-labeled #15856). It is a test-side index-sync race under CI load, not a product bug.Root cause: the
product⇄brandlink is created after the products have already been indexed, which triggers an asynchronous re-index of the linked product.waitForIndexedEntities(...)only waits for theBrandandProductProductBrandBrand(link) rows to be replicated — it does not wait for that product re-index to be reflected in the catalog. Unlike the sibling brand test (should use query.index to query the index module and hydrate the data), whose filter has an$orfallback ontitleand can therefore return rows even before the link is queryable, this test's filter (status: "published"+brand: { status: "active" }) strictly depends on the link being queryable. Soquery.indexreturns an empty set until the re-index lands. Under CI load that window can exceed the previous 7.5s retry budget (retries: 5×waitSeconds: 1.5), causing the flake.How — How have these changes been implemented?
Bumped only this test's
fetchAndRetrybudget from{ retries: 5, waitSeconds: 1.5 }(7.5s) to{ retries: 10, waitSeconds: 3 }(30s) so the query retry window matches the 30swaitForIndexedEntitiestimeout used elsewhere in the same test, and added a comment documenting the race. No production code is touched.Testing — How have these changes been tested, or how can the reviewer test the feature?
Test-only change. It extends the retry window for a query that is already expected to eventually succeed, so it cannot mask a real regression — the assertions (
resultset.data.length === 1) are unchanged. Reviewers can run:yarn jest integration-tests/modules/__tests__/index/query-index.spec.ts -t "filter enum field"Checklist
Fixes #15967