testing-mwaa-workflow

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Testing MWAA Workflows

测试 MWAA Workflow

AWS MCP server (optional but recommended): running the AWS CLI commands in this skill through the AWS MCP server gives sandboxed execution and audit logging. Every command here also works with the plain AWS CLI, so the skill does not require the MCP server or any MCP-only tools.

Test Amazon MWAA workflow execution end-to-end: trigger a run, poll it to a terminal state, and on failure drive a capped debug -> fix -> retest loop. This skill triggers and reads state only; it delegates every diagnosis to debugging-mwaa-workflow and every mutation (artifact edit, redeploy, environment create/update) to authoring-mwaa-workflow. Routes by flavor, then runs one shared spine.

Execution note — poll in discrete steps: whenever you wait for an AWS operation to reach a terminal or ready state, issue one status check per call and decide in your own loop whether to check again. Never block a single command or script on the wait (no
while
+
sleep
until done), regardless of the operation or how long it takes.

**AWS MCP server（可选但推荐）：**通过 AWS MCP server 在此 skill 中运行 AWS CLI 命令，可以获得沙箱化执行和审计日志。本文中的每条命令也可使用原生 AWS CLI 运行，因此该 skill 不依赖 MCP server 或任何 MCP 专属工具。

端到端测试 Amazon MWAA workflow 执行：触发一次运行、轮询至终态，并在失败时驱动一个次数受限的“调试 -> 修复 -> 重测”循环。此 skill 仅负责触发和读取状态；所有诊断均委派给 debugging-mwaa-workflow，所有变更操作（编辑 artifact、重新部署、创建或更新 environment）均委派给 authoring-mwaa-workflow。先按类型路由，再运行统一的主流程。

执行说明——以离散步骤轮询：每当需要等待 AWS 操作进入终态或就绪状态时，每次调用只发起一次状态检查，并自行在循环中决定是否再次检查。绝不要让单个命令或脚本阻塞等待完成（不要使用
while
+
sleep
一直等到结束），无论操作类型或耗时如何。

Guardrail — where this skill's own files live (MCP vs local install)

防护栏——此 skill 自身的文件位置（MCP 与本地安装）

This skill can be loaded two ways, and they resolve the skill's own bundled files from different places. Determine how the skill was loaded before reading a reference:

Loaded through the AWS MCP
retrieve_skill
tool: The skill is not installed on the local filesystem. You MUST fetch each reference via
```
retrieve_skill
```
with the
```
file
```
parameter (e.g.
```
file="references/provisioned-testing.md"
```
) and read the returned content. Do NOT
```
file_read
```
these paths locally — they do not exist on disk.
Installed locally (e.g.
```
.kiro/skills/testing-mwaa-workflow/
```
or
```
~/.claude/skills/testing-mwaa-workflow/
```
): Read the files from the local skill directory using relative paths.

This distinction applies only to the skill's own packaged files. User data and session artifacts are always read from and written to the user's working directory. Never fetch or write customer data through

retrieve_skill

此 skill 有两种加载方式，二者解析 skill 自带文件的位置不同。读取参考资料前，先确定 skill 的加载方式：

通过 AWS MCP
retrieve_skill
工具加载：此 skill 未安装在本地文件系统中。你必须通过
```
retrieve_skill
```
并使用
```
file
```
参数获取每份参考资料（例如
```
file="references/provisioned-testing.md"
```
），然后读取返回的内容。不要在本地对这些路径使用
```
file_read
```
——它们在磁盘上并不存在。
在本地安装（例如
```
.kiro/skills/testing-mwaa-workflow/
```
或
```
~/.claude/skills/testing-mwaa-workflow/
```
）：使用相对路径从本地 skill 目录读取文件。

此区别仅适用于此 skill 自带的打包文件。用户数据和 session artifact 始终从用户的工作目录读取，并写入该目录。绝不要通过

retrieve_skill

获取或写入客户数据。

Step 0: Detect Flavor, Mode, and Complexity

步骤 0：检测类型、模式和复杂度

Flavor (reuse debugging's logic)

类型（复用 debugging-mwaa-workflow 的逻辑）

An environment name resolvable via
```
aws mwaa get-environment
```
-> Provisioned.
A
```
workflow/...
```
ARN or any
```
aws mwaa-serverless
```
context -> Serverless.
Neither signal -> ask: MWAA Provisioned (Python DAG) or MWAA Serverless (YAML workflow)?

可通过
```
aws mwaa get-environment
```
解析到的 environment 名称 -> Provisioned。
```
workflow/...
```
ARN 或任何
```
aws mwaa-serverless
```
上下文 -> Serverless。
两者均无 -> 询问：**MWAA Provisioned（Python DAG）**还是 MWAA Serverless（YAML workflow）？

Invocation mode

调用模式

Standalone — the user points at an existing, already-deployed target.
Delegated — authoring-mwaa-workflow deployed and handed over the resolved target (env name +
```
dag_id
```
, or workflow ARN). Its "deploy and test now?" approval satisfies the first trigger confirmation only.

Standalone——用户指定一个现有且已部署的目标。
Delegated——authoring-mwaa-workflow 已完成部署，并移交了解析后的目标（environment 名称 +
```
dag_id
```
，或 workflow ARN）。其
```
deploy and test now?
```
批准仅满足首次触发确认。

Complexity

复杂度

Simple — target already deployed and known-ready -> skip to Step 2.
Standard — just deployed, readiness unknown -> full spine.
Complex — retest inside an active fix loop.

Simple——目标已部署且明确处于就绪状态 -> 跳至步骤 2。
Standard——刚刚部署，就绪状态未知 -> 执行完整主流程。
Complex——在活跃的修复循环中执行重测。

Step 1: Readiness Check (before the first trigger)

步骤 1：就绪检查（首次触发前）

Confirm the artifact is deployed and parse-ready. Do not trigger blind. This step is MANDATORY even when you plan to adopt an existing run — the readiness data (

last_parsed_time

is_active

has_import_errors

) feeds the freshness gate in Step 2.

Provisioned: confirm
```
dag_id
```
present with
```
has_import_errors: false
```
, then apply the version-aware ready check via the
```
/dags
```
collection endpoint. Determine the poll window from the environment's configured scan interval: check
```
get-environment
```
->
```
AirflowConfigurationOptions
```
for
```
scheduler.dag_dir_list_interval
```
(AF2) or
```
dag_processor.refresh_interval
```
(AF3). If unset, default to 300s. Poll up to that interval + 30s at 15s intervals (the per-DAG endpoint can lag). On AF2 (REST API v1) require
```
is_active: true
```
. On AF3 (REST API v2) the
```
is_active
```
field does not exist — require
```
is_stale: false
```
instead and never wait on
```
is_active
```
(it reads as absent/false forever). A DAG that is parsed but not yet ready will reject trigger attempts with an opaque
```
RestApiClientException
```
. Not ready in time -> hand to debugging-mwaa-workflow.
Serverless: confirm
```
WorkflowStatus
```
is
```
READY
```
(via
```
get-workflow --workflow-arn
```
). Not ready -> hand to debugging-mwaa-workflow.

This readiness window is separate from the Step 3 run timeout. See references/provisioned-testing.md and references/serverless-testing.md for exact commands.

确认 artifact 已部署且可以解析。不要盲目触发。即使计划采用已有运行，此步骤也是强制要求——就绪数据（

last_parsed_time

、

is_active

、

has_import_errors

）将用于步骤 2 的新鲜度门禁。

**Provisioned：**确认存在带
```
has_import_errors: false
```
的
```
dag_id
```
，然后通过
```
/dags
```
集合端点应用版本感知的就绪检查。根据 environment 配置的扫描间隔确定轮询窗口：检查
```
get-environment
```
->
```
AirflowConfigurationOptions
```
中的
```
scheduler.dag_dir_list_interval
```
（AF2）或
```
dag_processor.refresh_interval
```
（AF3）。如果未设置，默认使用 300s。以 15s 为间隔，最多轮询该间隔 + 30s（单 DAG 端点可能存在滞后）。在 **AF2（REST API v1）**中，要求
```
is_active: true
```
。在 **AF3（REST API v2）**中，不存在
```
is_active
```
字段——应改为要求
```
is_stale: false
```
，且切勿等待
```
is_active
```
（它始终显示为不存在或 false）。已解析但尚未就绪的 DAG 会拒绝触发请求，并返回难以理解的
```
RestApiClientException
```
。如果未能在规定时间内就绪 -> 交给 debugging-mwaa-workflow。
**Serverless：**确认
```
WorkflowStatus
```
为
```
READY
```
（通过
```
get-workflow --workflow-arn
```
）。如果未就绪 -> 交给 debugging-mwaa-workflow。

此就绪窗口与步骤 3 的运行超时相互独立。准确命令请参阅 references/provisioned-testing.md 和 references/serverless-testing.md。

Step 2: Confirm, then Trigger (safety gate)

步骤 2：确认后触发（安全门禁）

State the resolved target and classify its environment. Unless you are certain it is a development/test environment (name or tags clearly indicate dev/test), treat it as production: emit a prod warning and require explicit user confirmation before triggering. If the target is confirmed production (name or tags contain

prod

prd

, or

production

, or the user says so), require explicit approval at every state-changing step — each trigger, re-trigger, and clear/rerun — not just once. For a target you are certain is dev/test, require explicit user confirmation before the first trigger and each re-trigger.

This gate is already satisfied when the user has given explicit approval for the action: in delegated mode the authoring "deploy and test now?" approval covers the first trigger, and an explicit pre-authorization to trigger a specific run counts as that confirmation — do not re-ask when approval has already been given.

Before triggering, check for scheduler-created runs (see provisioned-testing reference). Apply the freshness gate before adopting any prior run:

Delegated mode: always trigger fresh. Prior runs predate the deployment by definition — do not adopt regardless of state.
Standalone mode: compare
```
run.start_date
```
against
```
dag.last_parsed_time
```
read from the
```
/dags
```
collection response the Step 1 readiness check already fetches (the collection returns
```
last_parsed_time
```
per DAG in both v1 and v2 — no per-DAG call needed). If
```
start_date < last_parsed_time
```
, the run tested a prior artifact version — treat as stale, trigger fresh. Only adopt runs where
```
start_date >= last_parsed_time
```
.

For fresh, non-stale runs that pass the gate: if a run already exists for the target interval, adopt it instead of POSTing. Monitor through Step 3.

On a retest, all run identifiers must be fresh (Provisioned: both

dag_run_id

and

logical_date

; Serverless: new

start-workflow-run

call). Before re-triggering, confirm every prior run is terminal — a still-running prior run can block the new one from starting.

See references for exact trigger commands and retest hygiene.

说明已解析的目标，并判断其 environment 类别。除非能够确定目标是开发或测试 environment（名称或 tag 明确标识为 dev/test），否则一律按生产环境处理：发出生产环境警告，并要求用户在触发前明确确认。如果目标已确认为生产环境（名称或 tag 包含

prod

、

prd

或

production

，或用户明确说明），则每个会改变状态的步骤都必须获得明确批准——包括每次触发、重新触发以及 clear/rerun，而不能只批准一次。对于确定属于 dev/test 的目标，首次触发及每次重新触发前也必须获得用户明确确认。

当用户已明确批准该操作时，此门禁即视为已满足：在 Delegated 模式下，authoring 的

deploy and test now?

批准涵盖首次触发；针对特定运行的明确预授权也视为确认——已有批准时不要重复询问。

触发前，检查 scheduler 是否已创建运行（参见 provisioned-testing 参考资料）。采用任何已有运行之前，必须应用新鲜度门禁：

**Delegated 模式：**始终触发新运行。已有运行按定义必然早于本次部署——无论其状态如何，都不得采用。
**Standalone 模式：**将
```
run.start_date
```
与步骤 1 就绪检查已获取的
```
/dags
```
集合响应中的
```
dag.last_parsed_time
```
进行比较（该集合在 v1 和 v2 中都会返回每个 DAG 的
```
last_parsed_time
```
——无需调用单 DAG 端点）。如果
```
start_date < last_parsed_time
```
，说明该运行测试的是旧版 artifact——将其视为过期并触发新运行。仅采用满足
```
start_date >= last_parsed_time
```
的运行。

对于通过门禁的新鲜且未过期运行：如果目标时间区间已有运行，则采用该运行，而不是发送 POST 请求。通过步骤 3 监控该运行。

执行重测时，所有运行标识符都必须是全新的（Provisioned：同时使用新的

dag_run_id

和

logical_date

；Serverless：发起新的

start-workflow-run

调用）。重新触发前，确认所有先前运行均已进入终态——仍在运行的先前运行可能会阻止新运行启动。

准确的触发命令和重测规范请参阅相关参考资料。

Step 3: Poll to Terminal

步骤 3：轮询至终态

Poll the triggered run until it reaches a terminal state. See references for exact poll commands and error fallbacks.

Timeout handling:

Provisioned with
dagrun_timeout
set: if elapsed time exceeds
```
dagrun_timeout
```
and the run is still not terminal, treat as failure -> Step 4. (
```
dagrun_timeout
```
is a DAG-level Airflow parameter and does not apply to MWAA Serverless.)
Serverless: poll until the service returns a terminal state — no caller ceiling is needed, because the MWAA Serverless service enforces its own run cap and surfaces it as the
```
TIMEOUT
```
terminal state.
Provisioned without
dagrun_timeout
: there is no DAG- or service-level deadline, so agree a maximum wait with the user before polling (they know the DAG's expected runtime; default to 1h if they have no preference). Poll until terminal OR the maximum wait elapses. On reaching the cap, stop polling and report — do not silently mark it failed, and do not keep polling unbounded:
Run
```
<run-id>
```
has not reached a terminal state within the agreed
```
<max-wait>
```
. It may still be running — I have not failed it. Choose: (a) extend the wait, (b) inspect logs / the Airflow UI, or (c) treat this test as inconclusive.

Poll interval scales with elapsed time:

Elapsed time	Poll interval
<= 5 min	15s
> 5-15 min	30s
> 15-30 min	60s
> 30-60 min	2 min
> 60 min	5 min

Pass = terminal SUCCESS only; no output-data inspection. On pass -> Step 6.

轮询已触发的运行，直到其进入终态。准确的轮询命令和错误回退方案请参阅相关参考资料。

超时处理：

**Provisioned 且设置了
```
dagrun_timeout
```
：**如果经过时间超过
```
dagrun_timeout
```
，而运行仍未进入终态，则将其视为失败 -> 进入步骤 4。（
```
dagrun_timeout
```
是 DAG 级别的 Airflow 参数，不适用于 MWAA Serverless。）
**Serverless：**轮询至服务返回终态——无需由调用方设置上限，因为 MWAA Serverless 服务会强制执行自身的运行时长上限，并以
```
TIMEOUT
```
终态返回。
Provisioned 且未设置
dagrun_timeout
：不存在 DAG 或服务级别的截止时间，因此轮询前应与用户约定最长等待时间（用户了解 DAG 的预期运行时间；如果没有偏好，默认 1h）。持续轮询，直至进入终态或达到最长等待时间。达到上限时，停止轮询并报告——不要在未说明的情况下将其标记为失败，也不要无限期继续轮询：
运行
```
<run-id>
```
在约定的
```
<max-wait>
```
内尚未进入终态。它可能仍在运行——我并未将其判定为失败。请选择： (a) 延长等待时间，(b) 检查日志 / Airflow UI，或 (c) 将此次测试视为结论不确定。

轮询间隔随经过时间调整：

经过时间	轮询间隔
<= 5 min	15s
> 5-15 min	30s
> 15-30 min	60s
> 30-60 min	2 min
> 60 min	5 min

通过 = 终态为 SUCCESS；不检查输出数据。通过后 -> 进入步骤 6。

Step 4: On Failure, Delegate to Debugging

步骤 4：失败时委派给调试流程

Hand the run identifiers to debugging-mwaa-workflow. It returns its standard structure (Root Cause / Impact / Immediate Fix / Prevention / Commands). Do not re-diagnose here.

将运行标识符交给 debugging-mwaa-workflow。它会返回其标准结构（根因 / 影响 / 即时修复 / 预防措施 / 命令）。不要在此处重新诊断。

Step 5: Classify Fixes and Loop

步骤 5：分类修复项并进入循环

5a. Classify each action item debugging returns into one bucket:

Bucket	Examples	Handling
ARTIFACT	wrong operator param, missing import, bad YAML schema/timedelta, wrong task wiring, Serverless code-package fix (missing dep / wrong-platform wheel / bad zip layout)	Delegate to authoring-mwaa-workflow: regenerate the compliant artifact (and rebuild/redeploy the `--code` package for Serverless), then redeploy. Auto-continue.
ENVIRONMENT	requirements.txt dependency, plugins.zip, env config / worker sizing	Delegate to authoring's deploy path (owns env mutation + its own approval). Auto-continue after that gate.
HUMAN-GATED	new IAM permission, VPC/networking, missing data asset, quota increase	Cannot be auto-applied. Present exact commands, pause the loop, wait for the user to confirm resolution before any retest.

Testing never mutates directly.

5b. Re-test. After an auto-fixable bucket is applied and redeployed, loop back to Step 1 (redeploy triggers a fresh S3-sync/parse) -> Step 2 (re-confirm) -> Step 3. Apply Step 2's re-trigger hygiene: fresh

dag_run_id

and

logical_date

, and confirm the prior run is terminal (not just still retry-backing-off) before the new trigger.

5c. Mixed action items in one cycle (parallel). Kick off the auto-fixable fixes (regenerate + redeploy via authoring) and present the human-gated items at the same time; do not fully serialize. Two guardrails: (1) gate the retest on both completing — do not re-trigger until auto-fixes are redeployed and the user confirms the human-gated items; (2) if an auto-fix depends on a human-gated item (the regenerated artifact references a resource/permission the user must create first), sequence them instead of parallelizing.

5d. Loop cap and stop conditions. The cap counts attempts without progress, not raw attempts — default 3 (override "retry up to N"). Define progress as either: a task that failed before now reaches SUCCESS (the pipeline advanced), or debugging reports a different root cause than the prior attempt. An attempt that makes progress resets the counter — a multi-task pipeline that clears one blocker per run is advancing, and a hard raw-count cap would abandon it mid-repair. Stop and summarize when any of: (1) run reaches SUCCESS -> Step 6 pass; (2) the no-progress counter hits the cap; (3) a HUMAN-GATED item -> pause for the user. Two consecutive runs with the same root cause count as one no-progress increment each — that is the counter advancing, not a separate rule.

5a. 将调试返回的每个操作项归入一个分类：

分类	示例	处理方式
ARTIFACT	operator 参数错误、缺少 import、YAML schema/timedelta 错误、task wiring 错误、Serverless code-package 修复（缺少依赖 / wheel 平台错误 / zip 布局错误）	委派给 authoring-mwaa-workflow：重新生成合规 artifact（对于 Serverless，还要重建并重新部署 `--code` package），然后重新部署。自动继续。
ENVIRONMENT	requirements.txt 依赖、plugins.zip、environment 配置 / worker sizing	委派给 authoring 的部署路径（负责 environment 变更及其自身的批准门禁）。通过该门禁后自动继续。
HUMAN-GATED	新增 IAM 权限、VPC/网络配置、缺少数据资产、提高配额	无法自动应用。提供准确命令，暂停循环，并在任何重测前等待用户确认问题已解决。

测试流程绝不直接执行变更。

**5b. 重测。**应用可自动修复的分类并重新部署后，返回步骤 1（重新部署会触发新的 S3 同步/解析）-> 步骤 2（重新确认）-> 步骤 3。遵循步骤 2 的重新触发规范：使用新的

dag_run_id

和

logical_date

，并确认先前运行已进入终态（不能仅因为其仍处于 retry/backoff 状态就继续）。

5c. 单个周期内存在混合操作项（并行处理）。同时启动可自动应用的修复（通过 authoring 重新生成并重新部署）和需要人工处理的操作项；不要将二者完全串行化。两项防护规则：(1) 重测必须同时等待两者完成——在自动修复重新部署完成且用户确认人工操作项已解决之前，不得重新触发；(2) 如果某项自动修复依赖某项人工操作项（例如重新生成的 artifact 引用了必须由用户先创建的资源或权限），则改为按顺序执行。

5d. 循环上限和停止条件。该上限计算的是没有进展的尝试次数，而不是原始尝试总次数——默认 3（可通过“retry up to N”覆盖）。出现以下任一情况即视为取得进展：之前失败的任务现在到达 SUCCESS（pipeline 取得进展），或者 debugging 报告了与上一次尝试不同的根因。取得进展的尝试会重置计数器——多任务 pipeline 每次运行清除一个阻塞项属于持续推进，如果采用严格的原始次数上限，可能会在修复过程中过早终止。出现以下任一情况时停止并汇总：(1) 运行到达 SUCCESS -> 进入步骤 6 并通过；(2) 无进展计数器达到上限；(3) 存在 HUMAN-GATED 操作项 -> 暂停并等待用户处理。连续两次运行出现相同根因时，每次都计为一次无进展增量；这只是计数器推进，不构成另一条独立规则。

Step 6: Report

步骤 6：报告

Test Result: PASS | FAIL | STOPPED (<reason>)
Target: <env-name + dag_id | workflow ARN>  [PROD WARNING if applicable]
Attempts: <n>/<cap>
Run History:
  Attempt 1: <run_id> -> <state> (<duration>) [-> root cause if failed]
Fixes Applied: <artifact/env fixes auto-applied via authoring, per attempt> | none
Outstanding Action Items: <human-gated items, exact commands> | none
Next Step: <re-invoke to retest after resolving | passed, nothing needed>

PASS requires terminal SUCCESS. STOPPED covers cap-reached / no-progress / human-gated-pause, each named explicitly.

测试结果: PASS | FAIL | STOPPED (<原因>)
目标: <env-name + dag_id | workflow ARN>  [如适用则添加 PROD WARNING]
尝试次数: <n>/<cap>
运行历史:
  尝试 1: <run_id> -> <state> (<duration>) [-> 失败时的根因]
已应用修复: <每次尝试中通过 authoring 自动应用的 artifact/environment 修复> | 无
待处理操作项: <HUMAN-GATED 操作项及准确命令> | 无
下一步: <解决后重新调用以重测 | 已通过，无需进一步操作>

PASS 要求运行进入 SUCCESS 终态。STOPPED 涵盖达到上限、无进展或因 HUMAN-GATED 项暂停等情况，并且必须明确指出具体原因。

Gotchas

注意事项

A freshly deployed artifact is not immediately runnable — it must sync from S3 and parse (Provisioned) or was validated at create/update (Serverless). Step 1 is mandatory before the first trigger unless complexity is Simple.
This skill never edits an artifact, changes requirements, or creates/updates an environment. Those are authoring-mwaa-workflow's job and carry its approval gates. Testing only triggers (confirmed) and reads state.
Pass is run-state SUCCESS only. Output-data correctness is out of scope.

新部署的 artifact 不会立即可运行——必须先从 S3 同步并完成解析（Provisioned），或在创建/更新时完成验证（Serverless）。除非复杂度为 Simple，否则首次触发前必须执行步骤 1。
此 skill 绝不编辑 artifact、修改 requirements，或创建/更新 environment。这些操作由 authoring-mwaa-workflow 负责，并受其批准门禁约束。测试仅在获得确认后触发运行并读取状态。
通过仅以运行状态 SUCCESS 为准。输出数据的正确性不在范围内。

Troubleshooting

故障排查

Symptom	Cause	Action
DAG absent from `GET /dags`	S3-sync lag or import error	Hand to debugging-mwaa-workflow before triggering
`--path` rejected / truncated	Path over 64 chars (https://docs.aws.amazon.com/cli/latest/reference/mwaa/invoke-rest-api.html)	Poll the collection path with `--query-parameters`
`RestApiClientException` on poll	Web server unreachable	Fall back to DAGProcessing/Scheduler log groups
`RestApiClientException` on dagRuns POST (empty message)	DAG not ready — AF2: `is_active=false` (activation incomplete); AF3: `is_stale=true` ( `is_active` does not exist in v2)	Poll `/dags` collection until ready (AF2 `is_active=true` / AF3 `is_stale=false` ); do not retry the trigger blind
Manual run created but stuck in `queued` , never starts (AF3)	DAG is paused — AF3 does not execute manual runs while paused (AF2 does)	Unpause ( `PATCH /dags/<dag_id>` `{"is_paused": false}` ) then trigger; common right after an upgrade where DAGs are deployed paused
Serverless `get-workflow` not READY	Still creating/updating or failed	Wait for READY; if FAILED, hand to debugging
Same failure two attempts running	Fix not addressing root cause	Stop at no-progress; summarize; do not burn the cap

症状	原因	操作
DAG 未出现在 `GET /dags` 中	S3 同步延迟或 import 错误	触发前交给 debugging-mwaa-workflow
`--path` 被拒绝或截断	路径超过 64 个字符（https://docs.aws.amazon.com/cli/latest/reference/mwaa/invoke-rest-api.html）	使用 `--query-parameters` 轮询集合路径
轮询时出现 `RestApiClientException`	Web server 无法访问	回退到 DAGProcessing/Scheduler log group
对 dagRuns 发起 POST 时出现 `RestApiClientException` （错误信息为空）	DAG 尚未就绪——AF2： `is_active=false` （激活尚未完成）；AF3： `is_stale=true` （v2 中不存在 `is_active` ）	轮询 `/dags` 集合直至就绪（AF2 `is_active=true` / AF3 `is_stale=false` ）；不要盲目重试触发
手动运行已创建但一直停留在 `queued` ，从未启动（AF3）	DAG 已暂停——AF3 在暂停期间不会执行手动运行（AF2 会）	解除暂停（ `PATCH /dags/<dag_id> {"is_paused": false}` ）后再触发；升级后部署的 DAG 经常处于暂停状态，因而常见此问题
Serverless `get-workflow` 未返回 READY	仍在创建/更新，或创建/更新失败	等待 READY；如果状态为 FAILED，则交给 debugging
连续两次尝试出现相同失败	修复未解决根因	在无进展状态下停止并汇总；不要耗尽重试上限

References

参考资料

references/provisioned-testing.md — exact invoke-rest-api commands (readiness, trigger, poll), 64-char path limit, retest hygiene, log fallback
references/serverless-testing.md — exact mwaa-serverless commands (get-workflow, start-workflow-run, get-workflow-run), terminal states

references/provisioned-testing.md——准确的 invoke-rest-api 命令（就绪检查、触发、轮询）、64 字符路径限制、重测规范、日志回退方案
references/serverless-testing.md——准确的 mwaa-serverless 命令（get-workflow、start-workflow-run、get-workflow-run）、终态列表

Security Considerations

安全注意事项

Triggers real runs (state-changing): every trigger and re-trigger requires explicit confirmation; prod-named targets get a warning first.
No autonomous mutation: the skill never edits artifacts, requirements, or environments and never changes IAM — those are delegated to authoring (with its own gates). Human-gated fixes pause the loop for user action.
No secret exposure: run and log inspection must not surface credentials or connection strings into output.

会触发真实运行（状态变更）：每次触发和重新触发都需要明确确认；名称中带有 prod 的目标必须先显示警告。
**不允许自主变更：**此 skill 绝不编辑 artifact、requirements 或 environment，也绝不修改 IAM；这些操作均委派给 authoring（并受其自身门禁约束）。需要人工处理的修复会暂停循环，等待用户操作。
**不得暴露 secret：**检查运行和日志时，不得在输出中暴露凭据或连接字符串。