sadpandajoe commented on code in PR #43004: URL: https://github.com/apache/superset/pull/43004#discussion_r4148762104
########## superset-frontend/playwright/tests/dashboard/global-async-query-resilience.spec.ts: ########## @@ -0,0 +1,424 @@ +/** + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +/** + * Global Async Queries (GAQ) under stress: a query that fails, a superseded + * query racing a newer one, a lost channel token, and a page torn down + * mid-flight. + * + * GAQ's happy path is visually identical to a synchronous load, so these are + * the cases where its machinery actually becomes observable -- or where it + * must stay invisible. The happy paths live in global-async-query.spec.ts. + * + * Requires the `GLOBAL_ASYNC_QUERIES` feature flag, Redis, and a running + * Celery worker. + */ +import { testWithAssets, expect } from '../../helpers/fixtures'; +import { apiGetChart, apiPutChart } from '../../helpers/api/chart'; +import { TIMEOUT } from '../../utils/constants'; +import { apiPost } from '../../helpers/api/requests'; +import { + BIG_NUMBER_COUNT_SPEC, + nativeFilterValuesIn, + setupDashboardWithBigNumberCharts, + setupDashboardWithSelectFilter, + sliceIdFromChartDataUrl, + trackGaqSignals, +} from './dashboard-test-helpers'; +import { isFeatureEnabled } from '../../helpers/featureFlags'; + +testWithAssets.beforeEach(async ({ page }) => { + await page.goto('chart/list/'); + testWithAssets.skip( + !(await isFeatureEnabled(page, 'GLOBAL_ASYNC_QUERIES')), + 'GLOBAL_ASYNC_QUERIES is not enabled on this instance', + ); +}); + +testWithAssets( + 'broken chart surfaces a clean error under GAQ instead of hanging, and recovers once fixed', + async ({ page, testAssets }) => { + // Two forced refreshes plus an API round-trip between them exceed the + // default timeout on a loaded runner. + testWithAssets.setTimeout(TIMEOUT.SLOW_TEST); + + const BAD_COLUMN = 'this_column_does_not_exist_gaq_test'; + + // A custom SQL metric on a nonexistent column fails in Postgres, not in + // client-side validation -- so the job really is queued and run, and this + // exercises the async error path rather than a request that never ships. + const { dashboardId, dashboard, charts, valueLocators } = + await setupDashboardWithBigNumberCharts( + page, + testAssets, + testWithAssets.info(), + { + datasetName: 'birth_names', + chartNamePrefix: 'gaq_tc3_broken_chart', + chartSpecs: [ + { + viz_type: 'big_number_total', + params: { + metric: { + expressionType: 'SQL', + sqlExpression: `SUM(${BAD_COLUMN})`, + label: 'broken_metric', + hasCustomLabel: true, + }, + }, + }, + ], + }, + ); + const [chart] = charts; + const [value] = valueLocators; + const errorAlert = dashboard.getChart(chart.id).locator('.ant-alert-error'); Review Comment: `errorAlert` is the same locator before and after `forceRefresh()`, and the refreshed metric is identical to the one that already failed on initial load -- so the checks at lines 100-102 (visible, "Data error", `BAD_COLUMN`) would pass identically whether the refresh's own query ever completed or the DOM simply never changed. Only the signals check at lines 104-113 (202 + a status-changes poll) proves a fresh submission happened, and even that only proves the task was queued and polled, not that its failure is what's actually rendered. Would asserting on something that changes across the refresh (e.g. a fresh task id in the poll response, or clearing/re-showing the alert element around the `forceRefresh()` call) close that gap? ########## superset-frontend/playwright/tests/dashboard/global-async-query-resilience.spec.ts: ########## @@ -0,0 +1,424 @@ +/** + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +/** + * Global Async Queries (GAQ) under stress: a query that fails, a superseded + * query racing a newer one, a lost channel token, and a page torn down + * mid-flight. + * + * GAQ's happy path is visually identical to a synchronous load, so these are + * the cases where its machinery actually becomes observable -- or where it + * must stay invisible. The happy paths live in global-async-query.spec.ts. + * + * Requires the `GLOBAL_ASYNC_QUERIES` feature flag, Redis, and a running + * Celery worker. + */ +import { testWithAssets, expect } from '../../helpers/fixtures'; +import { apiGetChart, apiPutChart } from '../../helpers/api/chart'; +import { TIMEOUT } from '../../utils/constants'; +import { apiPost } from '../../helpers/api/requests'; +import { + BIG_NUMBER_COUNT_SPEC, + nativeFilterValuesIn, + setupDashboardWithBigNumberCharts, + setupDashboardWithSelectFilter, + sliceIdFromChartDataUrl, + trackGaqSignals, +} from './dashboard-test-helpers'; +import { isFeatureEnabled } from '../../helpers/featureFlags'; + +testWithAssets.beforeEach(async ({ page }) => { + await page.goto('chart/list/'); + testWithAssets.skip( + !(await isFeatureEnabled(page, 'GLOBAL_ASYNC_QUERIES')), + 'GLOBAL_ASYNC_QUERIES is not enabled on this instance', + ); +}); + +testWithAssets( + 'broken chart surfaces a clean error under GAQ instead of hanging, and recovers once fixed', + async ({ page, testAssets }) => { + // Two forced refreshes plus an API round-trip between them exceed the + // default timeout on a loaded runner. + testWithAssets.setTimeout(TIMEOUT.SLOW_TEST); + + const BAD_COLUMN = 'this_column_does_not_exist_gaq_test'; + + // A custom SQL metric on a nonexistent column fails in Postgres, not in + // client-side validation -- so the job really is queued and run, and this + // exercises the async error path rather than a request that never ships. + const { dashboardId, dashboard, charts, valueLocators } = + await setupDashboardWithBigNumberCharts( + page, + testAssets, + testWithAssets.info(), + { + datasetName: 'birth_names', + chartNamePrefix: 'gaq_tc3_broken_chart', + chartSpecs: [ + { + viz_type: 'big_number_total', + params: { + metric: { + expressionType: 'SQL', + sqlExpression: `SUM(${BAD_COLUMN})`, + label: 'broken_metric', + hasCustomLabel: true, + }, + }, + }, + ], + }, + ); + const [chart] = charts; + const [value] = valueLocators; + const errorAlert = dashboard.getChart(chart.id).locator('.ant-alert-error'); + + // Let the initial (also broken) load settle before tracking. + await expect(errorAlert).toBeVisible({ timeout: TIMEOUT.CHART_RENDER }); + + const signals = trackGaqSignals(page); + + await dashboard.forceRefresh(); + + await expect(errorAlert).toBeVisible({ timeout: TIMEOUT.CHART_RENDER }); + await expect(errorAlert).toContainText('Data error'); + await expect(errorAlert).toContainText(BAD_COLUMN); + + await expect(() => { + expect( + signals.submitStatusFor(chart.id), + 'forced chart-data submission for the broken chart should still be accepted (202) onto the async path', + ).toBe(202); + expect( + signals.sawTaskStatusPoll, + 'the client should have polled /api/v1/task/status_changes while the broken query ran', + ).toBe(true); + }).toPass({ timeout: TIMEOUT.CHART_RENDER }); + + // Fix the config and confirm the chart recovers, rather than staying stuck. + const chartResp = await apiGetChart(page, chart.id); + expect(chartResp.ok()).toBe(true); + const { result } = await chartResp.json(); + const fixedParams = { ...JSON.parse(result.params), metric: 'count' }; + + const updateResp = await apiPutChart(page, chart.id, { + params: JSON.stringify(fixedParams), + }); + expect(updateResp.ok()).toBe(true); + + // Refreshing re-submits the form_data already loaded client-side, so it + // would not pick up an out-of-band config change. Re-navigating refetches + // the chart's metadata. + await dashboard.gotoById(dashboardId); + await dashboard.waitForLoad(); + + await expect(value).toBeVisible({ timeout: TIMEOUT.CHART_RENDER }); + await expect(value).toHaveText(/\d/); + await expect(errorAlert).not.toBeAttached(); + }, +); + +testWithAssets( + 'rapidly switching a filter value never lets the superseded selection clobber the screen', + async ({ page, testAssets }) => { + testWithAssets.setTimeout(TIMEOUT.SLOW_TEST); + + // Generous enough that girl's own select/apply cycle plus network latency + // cannot consume the window while boy sits parked -- the delay starts when + // boy is applied, i.e. before that cycle even begins. + const RACE_DELAY_MS = 8000; + const FILTER_COLUMN = 'gender'; + + const { chartId, dashboardId, dashboard, filterBar, value } = + await setupDashboardWithSelectFilter( + page, + testAssets, + testWithAssets.info(), + { + datasetName: 'birth_names', + namePrefix: 'gaq_tc4_filter_race', + filterColumn: 'gender', + filterName: 'Gender', + }, + ); + + await dashboard.gotoById(dashboardId); + await dashboard.waitForLoad({ timeout: TIMEOUT.SLOW_TEST }); + await expect(value).toBeVisible({ timeout: TIMEOUT.CHART_RENDER }); + + // Learn "girl"'s real count first, so the race can assert on that specific + // number. The chart keeps showing the unfiltered total while "girl"'s query + // is in flight, and that total already contains a digit -- so a bare /\d/ + // would read the *pre-filter* value as the baseline whenever the query was + // slow. Wait for the round trip at the network level instead, as the race + // below does: a 200 straight away (cache hit) or 202 then 200, ending in + // 200 either way. + const baselineSignals = trackGaqSignals(page); + await filterBar.selectOption('girl'); + await filterBar.apply(); + await expect(() => { + const statuses = baselineSignals.submitStatusesFor(chartId); + expect( + statuses, + '"girl"\'s chart-data request should have been answered', + ).not.toHaveLength(0); + expect( + statuses.every(status => status === 200 || status === 202), + `"girl"'s chart-data statuses should all be 200/202, got ${statuses.join(', ')}`, + ).toBe(true); + expect( + statuses[statuses.length - 1], + '"girl"\'s chart-data round trip should end with a 200', + ).toBe(200); + }).toPass({ timeout: TIMEOUT.CHART_RENDER }); + await expect(value).toHaveText(/\d/, { timeout: TIMEOUT.CHART_RENDER }); + const expectedGirlText = await value.textContent(); + + // Example queries settle in ~1-2s, too fast to race for real. Delaying only + // the next request makes "boy" reliably still in flight when "girl" fires. + let matchCount = 0; + const raceRoute = (url: URL) => + sliceIdFromChartDataUrl(url.toString()) === chartId; + await page.route(raceRoute, async route => { + matchCount += 1; + if (matchCount === 1) { + await new Promise(resolve => { + setTimeout(resolve, RACE_DELAY_MS); + }); + } + await route.continue(); + }); + + // The chart keeps rendering its previous value while a query is in flight + // -- it does not blank or spinner over the number (confirmed by trace). So + // asserting the expected text alone would pass instantly against what is + // already on screen, proving nothing. Tracking from here gives a + // network-level proof instead: "boy" is parked in the artificial delay and + // has not reached the server, so any chart-data response seen inside the + // race window belongs to "girl". + const signals = trackGaqSignals(page); + + await filterBar.selectOption('boy'); + await filterBar.apply(); + const boyAppliedAt = Date.now(); Review Comment: `boyAppliedAt` is captured after `filterBar.apply()`'s UI promise resolves, not when the intercepted request actually starts the `RACE_DELAY_MS` timer in the route handler above. If that UI cycle is slow on a loaded runner, `remainingParkMs` (line 233) overstates how much of the delay is actually left, and the `statusesFor('boy')).toHaveLength(0)` check at line 268 can fail on a perfectly healthy run because "boy" is legitimately released before the computed deadline. Could the delay's start be measured from the route interception itself (e.g. a timestamp set inside the `page.route` handler) rather than from the client-side apply() return? ########## superset-frontend/playwright/tests/dashboard/global-async-query-resilience.spec.ts: ########## @@ -0,0 +1,424 @@ +/** + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +/** + * Global Async Queries (GAQ) under stress: a query that fails, a superseded + * query racing a newer one, a lost channel token, and a page torn down Review Comment: This header says the file covers "a lost channel token" scenario, but none of the four tests below exercises losing the async-token cookie (that case is described in the PR body as living elsewhere). Also, the comment at lines 213-215 ("any chart-data response seen inside the race window belongs to 'girl'") is stale against the code that follows it: lines 240-243 and 265-268 specifically handle the case where "boy"'s response can also land in that window, via payload-correlated `statusesFor` rather than raw arrival order. Worth trimming the header to what this file actually covers, and updating/removing the now-inaccurate "belongs to girl" line? ########## scripts/change_detector.py: ########## @@ -55,6 +55,11 @@ ], "frontend": [ r"^\.github/workflows/.*(bashlib|frontend|e2e)", + # The composite actions every Playwright job calls (cached-dependencies, + # setup-backend, change-detector). A change to the setup they share can + # break those jobs while touching nothing under superset-frontend/, so + # it has to reach them. + r"^\.github/actions/", Review Comment: This `.github/actions/` pattern (and its own comment, which says these composite actions are "every Playwright job's" shared setup, explicitly including `setup-backend`) is added only under `"frontend"`, not `"python"`. `setup-backend` is a plain backend/Python setup action, not a frontend one -- a PR that changes only `.github/actions/setup-backend/` would set `frontend=true` but leave `python=false`, so the Python unit/integration jobs gated on that output would skip re-running despite their own setup changing. Should this pattern (or at least the `setup-backend`/`change-detector` actions) also be added under `"python"`? ########## superset-frontend/playwright/tests/dashboard/global-async-query-resilience.spec.ts: ########## @@ -0,0 +1,424 @@ +/** + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +/** + * Global Async Queries (GAQ) under stress: a query that fails, a superseded + * query racing a newer one, a lost channel token, and a page torn down + * mid-flight. + * + * GAQ's happy path is visually identical to a synchronous load, so these are + * the cases where its machinery actually becomes observable -- or where it + * must stay invisible. The happy paths live in global-async-query.spec.ts. + * + * Requires the `GLOBAL_ASYNC_QUERIES` feature flag, Redis, and a running + * Celery worker. + */ +import { testWithAssets, expect } from '../../helpers/fixtures'; +import { apiGetChart, apiPutChart } from '../../helpers/api/chart'; +import { TIMEOUT } from '../../utils/constants'; +import { apiPost } from '../../helpers/api/requests'; +import { + BIG_NUMBER_COUNT_SPEC, + nativeFilterValuesIn, + setupDashboardWithBigNumberCharts, + setupDashboardWithSelectFilter, + sliceIdFromChartDataUrl, + trackGaqSignals, +} from './dashboard-test-helpers'; +import { isFeatureEnabled } from '../../helpers/featureFlags'; + +testWithAssets.beforeEach(async ({ page }) => { + await page.goto('chart/list/'); + testWithAssets.skip( + !(await isFeatureEnabled(page, 'GLOBAL_ASYNC_QUERIES')), + 'GLOBAL_ASYNC_QUERIES is not enabled on this instance', + ); +}); + +testWithAssets( + 'broken chart surfaces a clean error under GAQ instead of hanging, and recovers once fixed', + async ({ page, testAssets }) => { + // Two forced refreshes plus an API round-trip between them exceed the + // default timeout on a loaded runner. + testWithAssets.setTimeout(TIMEOUT.SLOW_TEST); + + const BAD_COLUMN = 'this_column_does_not_exist_gaq_test'; + + // A custom SQL metric on a nonexistent column fails in Postgres, not in + // client-side validation -- so the job really is queued and run, and this + // exercises the async error path rather than a request that never ships. + const { dashboardId, dashboard, charts, valueLocators } = + await setupDashboardWithBigNumberCharts( + page, + testAssets, + testWithAssets.info(), + { + datasetName: 'birth_names', + chartNamePrefix: 'gaq_tc3_broken_chart', + chartSpecs: [ + { + viz_type: 'big_number_total', + params: { + metric: { + expressionType: 'SQL', + sqlExpression: `SUM(${BAD_COLUMN})`, + label: 'broken_metric', + hasCustomLabel: true, + }, + }, + }, + ], + }, + ); + const [chart] = charts; + const [value] = valueLocators; + const errorAlert = dashboard.getChart(chart.id).locator('.ant-alert-error'); + + // Let the initial (also broken) load settle before tracking. + await expect(errorAlert).toBeVisible({ timeout: TIMEOUT.CHART_RENDER }); + + const signals = trackGaqSignals(page); + + await dashboard.forceRefresh(); + + await expect(errorAlert).toBeVisible({ timeout: TIMEOUT.CHART_RENDER }); + await expect(errorAlert).toContainText('Data error'); + await expect(errorAlert).toContainText(BAD_COLUMN); + + await expect(() => { + expect( + signals.submitStatusFor(chart.id), + 'forced chart-data submission for the broken chart should still be accepted (202) onto the async path', + ).toBe(202); + expect( + signals.sawTaskStatusPoll, + 'the client should have polled /api/v1/task/status_changes while the broken query ran', + ).toBe(true); + }).toPass({ timeout: TIMEOUT.CHART_RENDER }); + + // Fix the config and confirm the chart recovers, rather than staying stuck. + const chartResp = await apiGetChart(page, chart.id); + expect(chartResp.ok()).toBe(true); + const { result } = await chartResp.json(); + const fixedParams = { ...JSON.parse(result.params), metric: 'count' }; + + const updateResp = await apiPutChart(page, chart.id, { + params: JSON.stringify(fixedParams), + }); + expect(updateResp.ok()).toBe(true); + + // Refreshing re-submits the form_data already loaded client-side, so it + // would not pick up an out-of-band config change. Re-navigating refetches + // the chart's metadata. + await dashboard.gotoById(dashboardId); + await dashboard.waitForLoad(); + + await expect(value).toBeVisible({ timeout: TIMEOUT.CHART_RENDER }); + await expect(value).toHaveText(/\d/); + await expect(errorAlert).not.toBeAttached(); + }, +); + +testWithAssets( + 'rapidly switching a filter value never lets the superseded selection clobber the screen', + async ({ page, testAssets }) => { + testWithAssets.setTimeout(TIMEOUT.SLOW_TEST); + + // Generous enough that girl's own select/apply cycle plus network latency + // cannot consume the window while boy sits parked -- the delay starts when + // boy is applied, i.e. before that cycle even begins. + const RACE_DELAY_MS = 8000; + const FILTER_COLUMN = 'gender'; + + const { chartId, dashboardId, dashboard, filterBar, value } = + await setupDashboardWithSelectFilter( + page, + testAssets, + testWithAssets.info(), + { + datasetName: 'birth_names', + namePrefix: 'gaq_tc4_filter_race', + filterColumn: 'gender', + filterName: 'Gender', + }, + ); + + await dashboard.gotoById(dashboardId); + await dashboard.waitForLoad({ timeout: TIMEOUT.SLOW_TEST }); + await expect(value).toBeVisible({ timeout: TIMEOUT.CHART_RENDER }); + + // Learn "girl"'s real count first, so the race can assert on that specific + // number. The chart keeps showing the unfiltered total while "girl"'s query + // is in flight, and that total already contains a digit -- so a bare /\d/ + // would read the *pre-filter* value as the baseline whenever the query was + // slow. Wait for the round trip at the network level instead, as the race + // below does: a 200 straight away (cache hit) or 202 then 200, ending in + // 200 either way. + const baselineSignals = trackGaqSignals(page); + await filterBar.selectOption('girl'); + await filterBar.apply(); + await expect(() => { + const statuses = baselineSignals.submitStatusesFor(chartId); + expect( + statuses, + '"girl"\'s chart-data request should have been answered', + ).not.toHaveLength(0); + expect( + statuses.every(status => status === 200 || status === 202), + `"girl"'s chart-data statuses should all be 200/202, got ${statuses.join(', ')}`, + ).toBe(true); + expect( + statuses[statuses.length - 1], + '"girl"\'s chart-data round trip should end with a 200', + ).toBe(200); + }).toPass({ timeout: TIMEOUT.CHART_RENDER }); + await expect(value).toHaveText(/\d/, { timeout: TIMEOUT.CHART_RENDER }); + const expectedGirlText = await value.textContent(); + + // Example queries settle in ~1-2s, too fast to race for real. Delaying only + // the next request makes "boy" reliably still in flight when "girl" fires. + let matchCount = 0; + const raceRoute = (url: URL) => + sliceIdFromChartDataUrl(url.toString()) === chartId; + await page.route(raceRoute, async route => { + matchCount += 1; + if (matchCount === 1) { + await new Promise(resolve => { + setTimeout(resolve, RACE_DELAY_MS); + }); + } + await route.continue(); + }); + + // The chart keeps rendering its previous value while a query is in flight + // -- it does not blank or spinner over the number (confirmed by trace). So + // asserting the expected text alone would pass instantly against what is + // already on screen, proving nothing. Tracking from here gives a + // network-level proof instead: "boy" is parked in the artificial delay and + // has not reached the server, so any chart-data response seen inside the + // race window belongs to "girl". + const signals = trackGaqSignals(page); + + await filterBar.selectOption('boy'); + await filterBar.apply(); + const boyAppliedAt = Date.now(); + // Deliberately no wait -- "boy" is still in flight as "girl" is applied. + await filterBar.selectOption('girl'); + await filterBar.apply(); + + // Whatever is left of boy's artificial delay once girl has been applied. + // Measured rather than assumed: the UI cycle above is not instant, and + // hard-coding `RACE_DELAY_MS - 500` silently shrinks to nothing on a loaded + // runner, letting boy's response land inside the window below. + const remainingParkMs = RACE_DELAY_MS - (Date.now() - boyAppliedAt); + expect( + remainingParkMs, + 'girl should have been applied while boy was still parked in the route delay', + ).toBeGreaterThan(0); + + // Identify the response by the filter that produced it, not by arrival + // order: both requests are for this same slice, so "first status seen for + // the slice" can be boy's -- its delay is already running when girl is + // applied, so on a slow runner it can respond inside this window and + // satisfy the check without girl ever having completed. + const statusesFor = (value: string) => + signals.submitStatusesWhere(chartId, body => + nativeFilterValuesIn(body, FILTER_COLUMN).includes(value), + ); + + // "girl" ran once already, so this repeat may be a synchronous cache hit + // rather than a fresh 202. Either proves the round-trip happened, which is + // all that is being established here -- but it has to be one of those two. + // Merely asserting a status was recorded would accept a 4xx/5xx, and since + // the chart keeps displaying the previous "girl" value while a query is in + // flight, the text assertion below would then pass on stale pixels and the + // test would be green without a successful round trip. + await expect(() => { + const girlStatuses = statusesFor('girl'); + expect( + girlStatuses, + '"girl"\'s fast chart-data request should have been answered', + ).not.toHaveLength(0); + expect( + [200, 202], + '"girl"\'s fast chart-data submission should have succeeded (200 cache-hit or 202 async-accepted)', + ).toContain(girlStatuses[0]); + // The race only exists if boy is still parked at this point. Asserted + // alongside girl's success so a run where the delay failed to hold boy + // back is reported as such, instead of quietly testing nothing. + expect( + statusesFor('boy'), + '"boy" should still be parked in the route delay while "girl" completes', + ).toHaveLength(0); + }).toPass({ timeout: remainingParkMs }); + + await expect(value).toHaveText(expectedGirlText ?? '', { + timeout: TIMEOUT.UI_TRANSITION, + }); + const raceResultText = await value.textContent(); + + // Give the superseded "boy" response every chance to arrive and clobber it. + await page.waitForTimeout(RACE_DELAY_MS + 2000); + await expect(value).toHaveText(raceResultText ?? ''); Review Comment: This final wait can't actually prove the anti-clobber behavior it's testing. When "girl" is applied, the app aborts the in-flight "boy" request client-side (`chartAction.ts`'s `setTimeout(() => prevController.abort(), 0)`, fired as soon as the new query starts) rather than letting it run to completion and discarding a late response. That abort happens almost immediately, well before this route's artificial `RACE_DELAY_MS` delay would release "boy"'s response -- so the browser cancels that request outright, and no late "boy" response is ever possible through this path for the code below to wait out. The `waitForTimeout(RACE_DELAY_MS + 2000)` + re-assert would pass the same way whether or not the app's supersession logic is correct. Could the route handler hold "boy" open without letting the click complete (e.g. delay before `route.continue()` on the *first* interception, keeping the request itself in flight rather than resolved-then-aborted), or is there another way to get a genuine late response into this window? -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
