From 4f6cc0bff5ad6b7a919f6d5d8c0c1878e92ba180 Mon Sep 17 00:00:00 2001 From: Saqib Date: Mon, 17 Aug 2026 19:21:53 +0530 Subject: [PATCH] Add concurrency guard to run-smoke.yml Two PRs merging 37s apart each triggered their own push-to-main smoke run against the shared dev backend with no guard against overlap (unlike ci.yml, which got this same fix 2026-08-12). The second run hit a hard 120s pytest-timeout kill and failed with no report.json produced. Mirrors ci.yml's existing pattern. --- .github/workflows/run-smoke.yml | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/.github/workflows/run-smoke.yml b/.github/workflows/run-smoke.yml index 1b9f979..44cf7fa 100644 --- a/.github/workflows/run-smoke.yml +++ b/.github/workflows/run-smoke.yml @@ -51,6 +51,20 @@ on: SANDBOX_ORG_SLUG: required: false +# Added 2026-08-17 after a real, reproduced failure: two PRs merged 37s apart +# each triggered their own push-to-main run of this workflow (no guard existed +# here, unlike ci.yml's own concurrency block added 2026-08-12 for the exact +# same reason). The second run overlapped the first against the shared dev +# backend and hit a hard 120s pytest-timeout kill on a test that hangs under +# concurrent load (no report.json produced -> smoke gate correctly failed, +# but for an infra reason unrelated to the actual code being smoke-tested). +# cancel-in-progress is also the right behavior for this workflow's +# workflow_call use (ParakhAI-frontend's CD pipeline): a newer deploy's smoke +# check should supersede a stale one, not queue behind it. +concurrency: + group: ${{ github.workflow }}-${{ github.ref }} + cancel-in-progress: true + jobs: smoke: name: Smoke Tests