【问题标题】:Request data seemingly dirty in multithreaded flask app在多线程烧瓶应用程序中请求数据似乎很脏
【发布时间】:2020-10-07 18:18:14
【问题描述】:

我们看到一个随机错误,这似乎是由两个请求的数据混淆造成的。我们收到了在Order 上报价运费的请求,但请求失败,因为请求的帐户无法访问请求的Order。我正在寻找可以提供关于这里可能发生的事情的提示的人,我在谷歌、官方烧瓶帮助频道或看起来像我们正在经历的 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 工作流查找,它对应于“错误”请求(即,不用于引用的请求)。

【问题讨论】:

    标签: amazon-web-services flask mod-wsgi werkzeug


    【解决方案1】:

    实际问题是 python-graphql 的库之一 (promise) 上的错误,而不是 Flask、werkzeug 或 apache 上的错误。不是请求数据“移动”到另一个线程,而是另一个线程试图解决应该在其他地方处理的查询的承诺。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-07-23
      • 1970-01-01
      • 2019-11-13
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多