共享concurrency group的Workflow为何被取消而非处于pending状态？

我有两个共享同一并发组的GitHub Actions工作流，配置分别如下：

工作流1：

jobs:
  evaluate:
    runs-on: [ android-emulator ]
    concurrency: evaluation_emulator

工作流2：

jobs:
  other_tests:
    runs-on: [ android-emulator ]
    concurrency: evaluation_emulator

第二个工作流的任务被取消，系统提示信息为：

Canceling since a higher priority waiting request for 'evaluation_emulator' exists

但根据GitHub官方文档说明，默认行为应为将队列中的并发工作流置于pending状态而非取消，文档原文如下：

When a concurrent job or workflow is queued, if another job or workflow using the same concurrency group in the repository is in progress, the queued job or workflow will be pending.

请问为何会出现这一与文档描述不符的现象？

出现这个现象的核心原因是工作流优先级差异以及并发组未被文档明确提及的调度逻辑，具体如下：

• 工作流优先级的影响：GitHub Actions会根据触发来源给工作流分配不同优先级，比如手动触发的工作流优先级高于push、PR等自动触发的工作流。当高优先级的工作流进入同一并发组的队列时，系统会直接取消低优先级的同组任务（无论对方是pending还是刚启动运行），而非让高优先级任务进入pending等待。你遇到的情况正是队列中存在更高优先级的请求，导致低优先级任务被取消。

• 文档描述的局限性：官方文档只说明了「同优先级」场景下的默认行为——当同优先级的工作流进入队列，若已有同组任务在运行，新任务会处于pending状态。但如果队列中存在高优先级任务，GitHub会优先保障高优先级任务的执行，同时取消低优先级的同组任务，这是文档未明确补充的调度规则。

• 任务状态的触发时机：如果第二个工作流的任务还处于pending等待阶段时，高优先级的同组工作流请求进入队列，系统会直接取消低优先级的pending任务；若低优先级任务已经开始运行，高优先级任务会先进入pending，直到运行中的任务结束——但如果你的低优先级任务刚启动就被取消，大概率是高优先级请求在它启动前就已进入队列触发了取消逻辑。

内容的提问来源于stack exchange，提问作者dzieciou