Quarkus Flyway外部化初始化退出码非零问题排查求助

1. 确认Flyway迁移的真实执行状态 #

• 直接查询数据库中的Flyway历史表（默认表名flyway_schema_history），检查所有迁移记录的success字段是否为true，同时核对已执行的迁移版本号是否与本地迁移文件完全匹配，确认是否真的没有遗漏或失败的迁移。
• 调高Quarkus日志级别：在容器环境变量中添加QUARKUS_LOG_LEVEL=TRACE，重新执行Job，获取完整的Flyway执行日志，重点查看以下内容：
  • Flyway启动时是否检测到待执行的迁移脚本
  • 是否出现“no migrations to apply”类的日志
  • 迁移执行过程中是否有警告或隐性错误（比如锁冲突、权限警告等）

2. 验证QUARKUS_INIT_AND_EXIT模式的退出码规则 #

• 本地复现场景：在本地开发环境中启动Quarkus应用，设置环境变量QUARKUS_INIT_AND_EXIT=true，分别测试两种情况：
  • 存在未执行的迁移脚本，记录应用退出码
  • 所有迁移已执行完毕，记录应用退出码
• 查看Quarkus Flyway扩展的核心逻辑：重点关注FlywayProcessor或InitAndExitListener相关代码，确认当Flyway无新迁移执行时，是否会触发非零退出码的逻辑。

3. 检查Job容器的执行环境与配置 #

• 核对容器的启动命令与环境变量：确认QUARKUS_INIT_AND_EXIT=true正确设置，同时检查Flyway相关配置（如quarkus.flyway.validate-on-migrate、quarkus.flyway.clean-disabled等）是否存在冲突，比如开启了validate但数据库schema与迁移脚本存在不一致的情况。
• 查看Job的完整容器日志：除了Quarkus应用日志，还要检查容器启动的系统级日志，确认是否存在数据库连接超时、文件权限不足等隐性问题，这些问题可能未在应用日志中明确输出，但会导致非零退出码。

4. 临时验证退出码影响 #

• 修改Job的容器启动命令，添加退出码覆盖逻辑，例如：

  sh -c "./application-runner; exit 0"
  

  重新执行Job，观察Helm是否判定执行成功，同时再次确认Flyway迁移状态正常。如果此时Helm判定成功，则说明问题确实出在Quarkus的退出码规则上。

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