Apache DolphinScheduler 3.4.3 已正式发布。这次更新围绕调度、权限、安全、性能和稳定性展开，涉及任务实例与工作流实例查询、API 权限控制、敏感信息保护以及任务失败恢复等生产场景。
对运维和数据平台团队来说，值得关注的不是版本号本身，而是几个具体问题：排查任务时能否更顺畅地找到实例？接口是否严格遵守权限边界？任务失败后，恢复过程是否符合预期？
查询与恢复：沿着一次故障排查来验收
任务实例和工作流实例查询，是调度平台日常排障的入口。一次工作流失败后，工程师通常需要定位工作流实例、查看失败任务，再判断是否重试或恢复执行。查询能力和恢复行为，实际上处在同一条操作链路上。
来源摘要说明，3.4.3 对这些场景进行了改进和修复，但没有提供具体缺陷编号、性能数据或恢复语义。因此，不能据此推断“所有查询都更快”，也不能假设升级后恢复任务不会重复产生业务副作用。
可以这样实践：在预发布环境准备一条带有可控失败点的工作流，完整走一次排障过程。
| 验收环节 | 建议检查的内容 |
|---|---|
| 实例查询 | 时间范围、状态筛选和分页结果是否符合预期 |
| 定位失败 | 工作流实例与任务实例的信息是否能对应 |
| 恢复执行 | 实际执行的任务是否符合预期，有无遗漏或重复 |
| 业务结果 | 写表、文件输出或外部接口调用是否出现重复副作用 |
调度恢复不等于业务幂等。 即使平台正确恢复了任务，重复写入、重复发送通知等问题，仍需要任务代码或下游系统自行防护。
API 权限与敏感信息：不要只看页面是否隐藏按钮
本次发布涉及 API 权限控制和敏感信息保护。验收时，应把“界面上不能点击”和“接口确实拒绝访问”分开检查。
一个账号看不到某项操作，不代表它无法直接调用对应 API。反过来，正常账号能查询数据，也不代表返回内容中不存在不应暴露的字段。
可以准备三类身份进行对照：
- 具有权限的账号：应能完成允许的查询或操作。
- 缺少目标权限的账号：不应读取或修改权限范围外的资源。
- 未认证请求：不应访问受保护资源。
敏感信息检查则要覆盖接口响应、任务日志和异常信息，而不仅是配置页面。检查时尤其要留意凭据、连接参数和令牌；测试产生的响应文件，也应按敏感数据处理。
可以这样实践：对一个受保护的查询接口做冒烟测试
下面的 Bash 示例不是 DolphinScheduler 3.4.3 的官方接口示例，而是一个可改造的验收脚本。它不假定具体 API 路径或认证方式。
运行前，请将 API_URL 改为你们部署中已确认的、受保护的只读查询接口，再按现有认证方式配置请求头。不要使用会创建、删除或启动任务的接口。
#!/usr/bin/env bash
set -euo pipefail
umask 077
# 替换为实际的受保护只读查询接口。
: "${API_URL:?请设置 API_URL}"
# 完整认证请求头，例如你们部署实际使用的 token 请求头。
: "${AUTH_HEADER:?请设置 AUTH_HEADER}"
OUT_DIR="$(mktemp -d)"
trap 'rm -rf "$OUT_DIR"' EXIT
probe() {
local name="$1"
shift
local code
code="$(curl \
--silent --show-error \
--connect-timeout 5 \
--max-time 30 \
--output "$OUT_DIR/$name.json" \
--write-out '%{http_code}' \
"$@" \
"$API_URL")"
printf '%s: HTTP %s\n' "$name" "$code"
}
probe authenticated --header "$AUTH_HEADER"
probe anonymous
printf '\n请在本地检查响应中的业务状态和敏感字段。\n'
printf '临时响应目录：%s\n' "$OUT_DIR"
read -r -p "检查完成后按 Enter 删除临时文件。" _
保存为 check-api.sh 后运行：
chmod +x check-api.sh
export API_URL='https://scheduler.example.internal/替换为实际查询路径'
read -r -s -p '输入完整认证请求头：' AUTH_HEADER
printf '\n'
export AUTH_HEADER
./check-api.sh
unset AUTH_HEADER
不要只凭 HTTP 状态码判定测试成功：部分接口可能在响应正文中表达业务错误。还要确认未认证请求没有返回受保护数据，并用低权限账号重复测试权限边界。
该脚本只提供冒烟检查，不替代完整的安全测试。不要开启 shell 调试输出，也不要把包含凭据或业务数据的响应粘贴进公共工单。
3.4.3 与 3.5.0：把已发布改进和规划能力分开
来源摘要还提到，预计在 3.5.0 中添加调度补火策略。这里需要划清边界：这是后续版本的计划，不是 3.4.3 已交付的能力。
对于复杂数据工作流，错过调度时点后是否补跑、补跑多少次、如何控制积压，都是重要的设计问题。但摘要没有说明补火策略的配置方式、适用条件或最终行为，现阶段不宜按这些未知细节设计生产流程。
更稳妥的升级路径是：
- 升级前：备份必要配置与元数据，确认兼容性、升级步骤和回退条件。
- 预发布验证：覆盖实例查询、权限边界、敏感信息与失败恢复。
- 生产观察：比较相同负载下的查询耗时、错误情况和恢复结果。
- 后续跟进：待 3.5.0 的正式说明明确后，再评估补火策略。
3.4.3 更适合被看作一次围绕生产可靠性的持续完善。升级是否值得，不应只看发布摘要，而应看它能否通过你们真实工作流的验收：查得到、管得住、恢复得正确，并且没有引入新的业务副作用。