dbt-core项目中run_results.json文件写入异常问题分析

问题背景

在dbt-core项目中，run_results.json文件记录了每次dbt运行的重要结果信息，包括模型执行状态、耗时等关键数据。然而在1.9.0-b4版本中发现了一个严重问题：当主线程执行过程中遇到异常时，该文件不会被写入，导致用户无法获取运行结果数据。

问题现象

当在dbt项目的on-run-end钩子中执行包含错误的宏时，虽然模型本身执行成功，但由于钩子执行在主线程抛出异常，导致run_results.json文件未被生成。这给用户带来了两个主要困扰：

1. 无法获取模型执行成功的记录
2. 无法通过自动化工具解析运行结果

技术分析

问题的核心在于异常处理机制的不一致性。在dbt-core的代码中，我们发现：

1. 对于工作线程中的异常，系统有完善的异常捕获和处理机制，能够确保run_results.json文件正常写入
2. 但对于主线程（特别是钩子执行）中的异常，异常被捕获后直接终止了程序，跳过了结果写入步骤

这种不一致性导致了上述问题。主线程异常处理位于cli/requires.py文件中，而工作线程的异常处理则位于task/run.py中。

解决方案思路

解决这个问题需要从以下几个方面考虑：

1. 异常处理统一化：应该将主线程和工作线程的异常处理机制统一，确保无论哪个线程出现异常，都能正确记录运行结果

2. 结果持久化前置：在可能抛出异常的代码执行前，先确保运行结果已经持久化到文件中

3. 错误分类处理：区分致命错误和非致命错误，对于非致命错误仍应保留运行结果

实现建议

基于现有代码结构，建议的修改方案包括：

1. 在主线程异常处理中添加run_results.json的写入逻辑
2. 确保写入操作在异常处理的最外层进行
3. 保持与工作线程异常处理相似的错误记录方式
4. 考虑添加异常类型判断，对于某些特定错误仍允许结果写入

影响评估

该问题属于回归性bug，影响所有使用钩子功能并在钩子中可能抛出异常的用户场景。修复后可以确保：

1. 运行结果数据的完整性
2. 自动化工具依赖的稳定性
3. 错误诊断信息的可用性

最佳实践建议

为避免类似问题，建议开发者在编写dbt项目时：

1. 对钩子中的代码进行充分测试
2. 在钩子宏中添加完善的错误处理
3. 避免在钩子中执行可能失败的关键操作
4. 定期检查run_results.json文件的完整性

该问题的修复将提升dbt-core在异常情况下的数据可靠性，确保用户在任何情况下都能获取完整的运行结果记录。