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