本文旨在解决 Pact Broker 升级至 2.107.1 后，消费者配置中的 pactFileWriteMode = overwrite 不再生效，导致无法覆盖同版本 Pact 文件的问题。文章分析了该配置失效的原因，并提供了启用 allow_dangerous_contract_modification 功能的替代方案，同时强调了该方案可能带来的风险，帮助开发者更好地理解和解决此类问题。
在 Pact Broker 升级后，如果遇到 Pact 文件无法覆盖的问题，需要理解 pactFileWriteMode 配置的变更以及 Pact Broker 的版本控制策略。
问题原因：pactFileWriteMode 的移除
pactFileWriteMode 配置是 Pact 客户端库（如 Pact-JS）的配置，而非 Pact Broker 的配置。在 Pact-JS 10.x.x 版本之后，该配置已被移除。这意味着在更新 Pact 客户端库后，即使在消费者配置中设置了 pactFileWriteMode = overwrite，也不会生效。
解决方案：启用 allow_dangerous_contract_modification
Pact Broker 提供了一个名为 allow_dangerous_contract_modification 的配置项，可以控制是否允许修改已存在的消费者版本的 Pact 内容。
要启用此功能，需要在 Pact Broker 的配置中进行设置。具体步骤取决于你的 Pact Broker 部署方式。例如，如果你使用 docker 运行 Pact Broker，则可以通过环境变量进行配置：
PACT_BROKER_ALLOW_DANGEROUS_CONTRACT_MODIFICATION=true
或者，如果你使用其他方式部署 Pact Broker，请参考 Pact Broker 的官方文档，找到对应的配置方法。
配置项说明：
- allow_dangerous_contract_modification: 布尔值，用于控制是否允许修改已存在的消费者版本的 Pact 内容。
注意事项与风险提示
启用 allow_dangerous_contract_modification 功能存在一定的风险，强烈建议在生产环境中谨慎使用。
- 不可靠的 can-i-deploy 结果： 允许修改已存在的 Pact 内容会使 can-i-deploy 命令的结果变得不可靠。can-i-deploy 命令用于确定是否可以安全地部署某个版本的消费者或提供者。如果允许修改 Pact 内容，则无法保证 can-i-deploy 的结果的准确性，因为 Pact 内容可能在部署过程中发生变化。
- 版本控制混乱： 允许修改 Pact 内容会使版本控制变得混乱。理想情况下，每次提交都应该发布具有唯一版本号的 Pact。如果允许修改 Pact 内容，则可能会出现多个提交共享同一个 Pact 版本的情况，从而导致版本控制的混乱。
最佳实践
为了避免上述风险，建议采用以下最佳实践：
- 禁用 allow_dangerous_contract_modification： 除非有特殊原因，否则应始终禁用 allow_dangerous_contract_modification 功能。
- 为每次提交生成唯一的 Pact 版本： 确保每次提交都发布具有唯一版本号的 Pact。可以使用 git commit hash 作为 Pact 版本号。
- 使用 Pact Broker 的版本控制功能： Pact Broker 提供了强大的版本控制功能，可以帮助你管理 Pact 的版本。建议充分利用 Pact Broker 的版本控制功能，确保 Pact 的版本控制清晰明确。
总结
在 Pact Broker 升级后，pactFileWriteMode 配置不再生效是由于 Pact 客户端库的变更导致的。虽然可以通过启用 allow_dangerous_contract_modification 功能来解决这个问题，但该方案存在一定的风险。建议在生产环境中谨慎使用，并遵循最佳实践，确保 Pact 的版本控制清晰明确。如果可能，升级您的Pact流程，确保每次提交都发布具有唯一版本号的 Pact，这是最安全的做法。
