我们看到一个随机错误，该错误似乎是由于两个请求的数据混合在一起引起的。我们收到了一个关于Order的运输费用报价的请求，但是由于请求的帐户无法访问所请求的Order，因此请求失败。我正在寻找可以对这里可能发生的事情有所了解的任何人，我在Google，官方烧瓶帮助频道或SO上都没有发现任何类似我们正在经历的东西。
我们已部署在AWS上，具有apache，mod_wsgi，1个进程，15个线程，大约10个实例。
以下是发送电子邮件的代码：
msg = f"Order ID {self.shipping.order.id} is not valid for this Account {self.user.account_id}"
body = f"Error:<br/>{msg}<br/>Request Data:<br/>{request.data}<br/>Headers:<br/>{request.headers}"
send_email(msg, body, "devops@*******.com")
request_data = None
问题在于，在这种情况下，我们会通过电子邮件将错误和请求数据发送给自己，并且在许多情况下，我们获得的请求数据永远不会进入该特定代码段。可能是来自前端的请求，以获取当前用户的设置，例如，不参考任何订单，不要介意尝试为其获取运输报价。
将应用程序日志与apache的access_log进行比较，我们发现，在所有情况下，我们都在同一实例上收到两个请求，一个请求报价，另一个是实际被记录的请求。我们不知道这两个请求是由同一线程快速连续地处理还是由不同的线程处理，但是它们之间的距离是如此之近，以至于我认为后者的可能性更大。到目前为止，我们还无法唯一地将access_log条目与应用程序日志绑定在一起，因此，我们不知道哪个请求正在记录错误，但事实是我们将路由到视图与请求的内容不对应（即，我们不确定报价请求是否获得了错误的请求对象，或者其他请求是否被路由至错误的视图）。
另一个有趣的事实是，我们使用graphql，因此在 flask / werkzeug完成它们之后，完成了部分路由，但是目前我们从flask.request获得的主体显示的错误与执行的graphql函数/突变不对应。但这在直接通过烧瓶映射的视图中也会发生。 flask-login工作流程从一开始就对用户进行查找，它对应于“不良”请求（即，一个不用于报价的请求）。
答案 0 :(得分：0)
实际问题是python-graphql的一个库（promise）上的错误，而不是Flask，werkzeug或apache上的错误。不是“请求”数据“移动”到另一个线程，而是另一个线程试图解决对本应在其他地方处理的查询的承诺。