我不确定这是否是 ActiveRecord、PostgreSQL、Flynn 或我的应用程序的问题，但我最近在我的应用程序中一个名为environments的表中添加了一个新字段flynn_process_settings，出于某种原因，而 Environments#update 请求返回 200 状态，更新环境的内容包括flynn_process_settings的新值， 发送到数据库的 UPDATE SQL 语句不包括flynn_process_settings。
我觉得我已经排除了所有常见的嫌疑人，例如"数据库是否被迁移"等，因为我可以在生产中打开 rails 控制台并对其进行更新，所以似乎大多数事情都是按预期设置的。
这是真正奇怪的部分。 如果我只是一遍又一遍地发送相同的更新请求，它大约在 20-30 次中工作。 我在请求之间等待一分钟还是 2 秒似乎并不重要。 它总是有大约 5% 的成功机会。
上下文：我正在使用Postgres在Flynn容器环境中运行此应用程序。 在暂存中遇到同样的问题后，我最近将更新部署到生产环境，我能够通过多次推送到 Flynn 来修复这个问题。 所以这可能是某种弗林的问题，但我无法想象是什么会导致这种问题......？
最新版本中运行 rails 进程的 2 个实例。 失败/成功似乎与任何一个特定的都不对应(它似乎被配置为我的客户端绑定到特定实例(。
更新：看起来参数哈希包括自动包装的参数"environment" => { "flynn_process_settings" => "..." }在它实际工作的请求上，所以这可能是参数解析/包装的问题！ 虽然我不确定为什么需要该嵌套参数，因为我访问参数的代码如下所示：
def update
if environment.update(environment_params)
render ...
else
render ...
end
end
def environment_params
setup_step_keys = [An Array]
params.permit(setup_step_keys + [:flynn_process_settings]) #This should be at the root of params, right?
end
更新2：看起来Flynn以某种方式运行了一个旧的应用程序进程(App 141(，这就是出现问题的应用程序进程(这并不奇怪，尽管我仍然对它如何返回200状态感到困惑(。 所以现在我的主要问题是，为什么在将新版本的应用程序部署到 Flynn 之后，还会运行旧版本的应用程序。
这可能无法完全回答这个问题，但事实证明，有一个流浪的乘客进程仍在运行，导致错误结果。 每个工作结果都来自更新的乘客流程。 因此，我们的主要理论是，旧进程是在迁移运行之前启动的，并且以某种方式继续运行而没有异常，但由于某种原因仍然没有更新数据库，即使在迁移运行之后也是如此。
我们使用的是 Passenger 5.1.5，它有"使用内置引擎运行时导致内存损坏问题的重构错误"——所以可能与此有关，尽管我不知道这有多大可能性。
无论如何，主要问题是有一个流氓乘客进程导致了错误行为，而杀死该进程解决了这个问题。 至于为什么/如何开始这个过程以及为什么它没有引发异常，我还不能说，所以如果有人有更完整的解释，我将对此进行进一步的回答。