Back to Details

flake

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Flake

Flake（偶发失败）

Use this skill when a Remotion CI check fails and looks flaky, or when asked to run 
/flake
.
Tracker issue: https://github.com/remotion-dev/remotion/issues/8375
当 Remotion CI 检查失败且看起来像是偶发问题时，或当用户要求运行 
/flake
时，使用此 skill。
跟踪 Issue：https://github.com/remotion-dev/remotion/issues/8375

Goal

目标

Record flaky CI failures in issue #8375 and get the affected suite running again.
For every confirmed or likely flake:
  1. Identify the PR, workflow run, job, failed step, and concise failure signature.
  2. Update issue #8375:
    • If the signature already exists, increment its 
      Count
      .
    • If it is new, append a row with count 
      1
      , workflow/job, first-seen date, and evidence URL.
  3. Rerun the flaky job or failed jobs.
将偶发的 CI 失败记录到 issue #8375 中，并让受影响的 suite 重新运行。
对于每个已确认或疑似 Flake：
  1. 确定 PR、workflow run、job、失败的 step 以及简明的失败特征。
  2. 更新 issue #8375：
    • 如果该特征已存在，将 
      Count
      加 1。
    • 如果是新特征，追加一行，其中 count 为 
      1
      ，并包含 workflow/job、首次出现日期和证据 URL。
  3. 重新运行出现 Flake 的 job 或失败的 job。

Find The Failure

查找失败信息

Prefer 
gh
because the GitHub app may not expose all Actions logs or write permissions.
If the user gave a PR:
bash
gh pr view <pr-number> --repo remotion-dev/remotion --json number,title,headRefName,statusCheckRollup
gh pr checks <pr-number> --repo remotion-dev/remotion --watch=false
If the user gave a workflow run or job URL:
bash
gh run view <run-id> --repo remotion-dev/remotion --json databaseId,attempt,displayTitle,event,headBranch,headSha,status,conclusion,workflowName,createdAt,updatedAt,url,jobs
gh api repos/remotion-dev/remotion/actions/jobs/<job-id>/logs
If there is no PR context, inspect recent open PRs and recent failed runs:
bash
gh pr list --repo remotion-dev/remotion --state open --limit 30 --json number,title,headRefName,statusCheckRollup
gh run list --repo remotion-dev/remotion --workflow "Install and Test" --status failure --limit 20 --json databaseId,displayTitle,event,headBranch,headSha,conclusion,createdAt,url,workflowName
For rerun attempts, inspect the original attempt before deciding whether a failure was flaky:
bash
gh api repos/remotion-dev/remotion/actions/runs/<run-id>/attempts/1/jobs --paginate
gh api repos/remotion-dev/remotion/actions/jobs/<failed-job-id>/logs
优先使用 
gh
，因为 GitHub app 可能无法提供所有 Actions 日志或写入权限。
如果用户提供了 PR：
bash
gh pr view <pr-number> --repo remotion-dev/remotion --json number,title,headRefName,statusCheckRollup
gh pr checks <pr-number> --repo remotion-dev/remotion --watch=false
如果用户提供了 workflow run 或 job URL：
bash
gh run view <run-id> --repo remotion-dev/remotion --json databaseId,attempt,displayTitle,event,headBranch,headSha,status,conclusion,workflowName,createdAt,updatedAt,url,jobs
gh api repos/remotion-dev/remotion/actions/jobs/<job-id>/logs
如果没有 PR 上下文，检查最近的开放 PR 和最近失败的 run：
bash
gh pr list --repo remotion-dev/remotion --state open --limit 30 --json number,title,headRefName,statusCheckRollup
gh run list --repo remotion-dev/remotion --workflow "Install and Test" --status failure --limit 20 --json databaseId,displayTitle,event,headBranch,headSha,conclusion,createdAt,url,workflowName
对于重跑尝试，在判断失败是否为 Flake 前，检查原始 attempt：
bash
gh api repos/remotion-dev/remotion/actions/runs/<run-id>/attempts/1/jobs --paginate
gh api repos/remotion-dev/remotion/actions/jobs/<failed-job-id>/logs

Classify A Flake

判定 Flake

Treat a failure as a flake when at least one is true:
  • The same run, job, or failed step succeeded after a rerun without code changes.
  • The failure is infrastructure/network related, such as 
    fetch failed
    , connection resets, package manager download failures, cache service failures, or runner provisioning errors.
  • The test failure is a timeout, race, browser disconnect, port collision, or intermittent external service failure, and the PR changes do not plausibly touch that area.
Do not record deterministic type errors, lint errors, snapshots, or test assertions caused by changed source behavior unless there is evidence they pass on retry.
如果出现以下任一情况，则将失败视为 Flake：
  • 在没有代码变更的情况下，同一 run、job 或失败的 step 在重跑后成功。
  • 失败与基础设施或网络有关，例如 
    fetch failed
    、连接重置、包管理器下载失败、缓存服务失败或 runner 预配错误。
  • 测试失败源于超时、竞态、浏览器断开连接、端口冲突或外部服务间歇性故障，并且 PR 的变更不太可能影响该区域。
不要记录确定性的类型错误、lint 错误、快照错误，或由源代码行为变更导致的测试断言失败，除非有证据表明它们在重试时能够通过。

Signature Rules

特征签名规则

Use a stable signature that groups repeats but stays specific enough to act on:
  • Include package or suite when available, for example 
    @remotion/it-tests#testssr
    .
  • Include test name when available.
  • Include the root error text, stripped of timestamps, paths, random IDs, ports, line numbers, and ANSI codes.
  • Include workflow/job separately in the tracker row, not inside the signature unless needed to disambiguate.
Good examples:
  • `oven-sh/setup-bun@v2.1.2` failed with `TypeError: fetch failed`
  • `delayRender()` timeout while running `Render video with browser instance not open` in `@remotion/it-tests#testssr`
使用一种稳定的特征签名，将重复问题归组，同时保持足够的具体性以便采取行动：
  • 在可用时包含 package 或 suite，例如 
    @remotion/it-tests#testssr
    。
  • 在可用时包含测试名称。
  • 包含根错误文本，并移除时间戳、路径、随机 ID、端口、行号和 ANSI codes。
  • 将 workflow/job 单独放在跟踪表中，不要包含在特征签名内，除非需要用它消除歧义。
好的示例：
  • `oven-sh/setup-bun@v2.1.2` failed with `TypeError: fetch failed`
  • `delayRender()` timeout while running `Render video with browser instance not open` in `@remotion/it-tests#testssr`

Update The Tracker

更新跟踪表

Read the issue body:
bash
gh issue view 8375 --repo remotion-dev/remotion --json body --jq .body
Edit the full issue body, preserving the table. Always write the replacement Markdown to a temporary file and use 
--body-file
; do not pass multiline Markdown inline.
Table format:
md
| Count | Signature | Workflow / job | First seen | Evidence |
| ---: | --- | --- | --- | --- |
| 1 | `signature` | `Workflow` / `Job` | YYYY-MM-DD | https://github.com/remotion-dev/remotion/actions/runs/... |
When incrementing an existing row:
  • Change only 
    Count
    unless the evidence link is dead or less useful than the new one.
  • Keep 
    First seen
    as the earliest known date.
When appending a row:
  • Use the GitHub Actions job URL when possible.
  • Use the current date from the log timestamp, not the local machine date, if they differ.
Verify after editing:
bash
gh issue view 8375 --repo remotion-dev/remotion --json body --jq .body
读取 Issue 正文：
bash
gh issue view 8375 --repo remotion-dev/remotion --json body --jq .body
编辑完整的 Issue 正文，并保留表格。始终将替换后的 Markdown 写入临时文件并使用 
--body-file
；不要以内联方式传入多行 Markdown。
表格格式：
md
| Count | Signature | Workflow / job | First seen | Evidence |
| ---: | --- | --- | --- | --- |
| 1 | `signature` | `Workflow` / `Job` | YYYY-MM-DD | https://github.com/remotion-dev/remotion/actions/runs/... |
递增现有行时：
  • 仅更改 
    Count
    ，除非原证据链接已失效，或其 usefulness 不如新链接。
  • 将 
    First seen
    保持为已知的最早日期。
追加行时：
  • 尽可能使用 GitHub Actions 的 job URL。
  • 当前日期应取自日志时间戳；如果日志时间戳与本地机器日期不同，则不要使用本地机器日期。
编辑后进行验证：
bash
gh issue view 8375 --repo remotion-dev/remotion --json body --jq .body

Rerun

重新运行

Prefer rerunning only failed jobs:
bash
gh run rerun <run-id> --repo remotion-dev/remotion --failed
If only one known flaky job needs a rerun and the run is complete:
bash
gh api --method POST repos/remotion-dev/remotion/actions/jobs/<job-id>/rerun
If a flaky suite is still in progress and waiting would block the task, abort that workflow run and rerun failed jobs after cancellation is visible:
bash
gh run cancel <run-id> --repo remotion-dev/remotion
gh run watch <run-id> --repo remotion-dev/remotion --exit-status
gh run rerun <run-id> --repo remotion-dev/remotion --failed
If 
gh run watch
exits non-zero because cancellation made the run fail, continue to rerun failed jobs.
优先仅重新运行失败的 job：
bash
gh run rerun <run-id> --repo remotion-dev/remotion --failed
如果只有一个已知的 Flake job 需要重跑，并且该 run 已完成：
bash
gh api --method POST repos/remotion-dev/remotion/actions/jobs/<job-id>/rerun
如果存在 Flake 的 suite 仍在进行中，而继续等待会阻塞任务，则中止该 workflow run，并在取消操作可见后重新运行失败的 job：
bash
gh run cancel <run-id> --repo remotion-dev/remotion
gh run watch <run-id> --repo remotion-dev/remotion --exit-status
gh run rerun <run-id> --repo remotion-dev/remotion --failed
如果 
gh run watch
因取消操作导致 run 失败而以非零状态退出，仍要继续重新运行失败的 job。

Report Back

汇报结果

Summarize:
  • Tracker issue row added or incremented.
  • Rerun action taken, including run or job URL.
  • Any remaining running checks that were intentionally left alone.
总结：
  • 跟踪 Issue 中已添加或递增的行。
  • 已执行的重跑操作，包括 run 或 job URL。
  • 任何有意保留、仍在运行的检查。