another attempt at improving e2e flakiness#8207
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request increases the polling timeouts in e2e/helpers/usage.ts from 60 to 90 seconds, and the overall test suite timeout in e2e/specs/usage.spec.ts from 180 to 300 seconds to prevent tests from being cut off during slow ClickHouse ingestion. I have no feedback to provide on these changes.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
🚀 Snapshot Release (
|
| Package | Version | Info |
|---|---|---|
@graphql-hive/laboratory |
0.2.0-alpha-20260713160700-3aefe97fb7ef554644137914593e61715767e575 |
npm ↗︎ unpkg ↗︎ |
@graphql-hive/render-laboratory |
0.1.11-alpha-20260713160700-3aefe97fb7ef554644137914593e61715767e575 |
npm ↗︎ unpkg ↗︎ |
hive |
11.5.0-alpha-20260713160700-3aefe97fb7ef554644137914593e61715767e575 |
npm ↗︎ unpkg ↗︎ |
|
🐋 This PR was built and pushed to the following Docker images: Targets: Platforms: Image Tags: |
…le within poll window
| await expect | ||
| .poll( | ||
| async () => { | ||
| await flushAsyncInserts(); |
There was a problem hiding this comment.
Minor: This could probably be moved to just after the insert to avoid calling it on every poll for this condition.
2 participants
This PR fixes the flaky
usage.spec.tse2e tests ("usage report should be visible in Insights") by forcing a ClickHouse async-insert flush before each read, instead of racing the flush timer.First assumed cold-start ingestion latency and bumped poll/per-test timeouts. That didn't hold, so assumed the ClickHouse async-insert flush timer was the lever and overrode
async_insert_busy_timeout_ms. That also flaked. Digging into container logs showed the pipeline up to the ClickHouse insert is ~10ms; the variable, sometimes >90s delay is purely async-insert read-visibility. The flake actually tracks the ClickHouse image bump 24.8 → 26.3 (#8120), not the recent Cypress → Playwright migration.Root cause: the usage-ingestor writes with
async_insert=1, wait_for_async_insert=0(fire-and-forget), so a row isn't queryable until the async buffer flushes, and that flush timing is non-deterministic under CI load. A single small e2e report never trips the size-flush, so it rides entirely on the timer. Timeout/size tuning can only make this less likely, never deterministic.The fix (test-infra only, no production changes): expose the ClickHouse port in the e2e compose and call
SYSTEM FLUSH ASYNC INSERT QUEUEinside the usage helper's poll loop, making ingested reports queryable immediately. This is the approach ClickHouse's own test suite uses for async-insert read-after-write. The 30s poll stays as a web-first backstop. The canonical alternative,wait_for_async_insert=1, was avoided because it touches the shared production ingestor that self-hosters inherit.Also includes a small diagnostic that surfaces the real OIDC signinup response body on parse failure (a separate integration flake).