有小伙伴在执行测试报告的时候反馈，在某些接口中，返回报告数据用例竟然重复执行了两次，一开始定位问题怀疑是用例执行异常触发重复执行导致，但是并非如此，因为即使重复执行也是用例中某个接口请求被重复执行，而不是整个用例重复执行了两次
后面在优化获取测试报告性能的时候发现，原来前端有一个机制，在请求任意接口时，如果超过2min没有返回则重复再次请求一次该接口，这样会导致什么问题呢？
该测试计划在执行超过2min时，前端又再次请求一次，这样的话该版本测试计划就再次执行了一次，导致了测试报告莫名其妙的出现相同的执行用例的问题
测试报告执行返回响应，具体执行的逻辑采用异步的方式执行即可
Flask提供了比较优雅的异步执行的方式，具体的案例如下
from flask import Flask
import time
from concurrent.futures import ThreadPoolExecutor
executor = ThreadPoolExecutor(1)
app = Flask(__name__)
@app.route('/synchronize')
def update_redis():
executor.submit(do_update)
return 'ok'
def do_update():
time.sleep(10)
print('start update')
if __name__ == '__main__':
app.run()
在本地调试运行，可满足需求，so easy搞定，部署上线
上线后发现一个严重的问题，执行测试计划一直没有写入测试报告信息，哪里出现了问题？
通过打日志一步步坚信的调试发现，原来在执行一定时间后，测试计划的异步执行被强制毫无异常的终止了，why？
本地调试的是mac环境，服务部署的是linux环境，讲道理是没有任何区别的，那为啥出现不一致的情况呢？
多线程？或许是因为启动参数的原因？
线上环境启动
app.run(host='0.0.0.0', port=5001, debug=False, processes=10)
本地mac环境启动
app.run(host='0.0.0.0', port=5001, debug=False, threaded=True)
将本地mac环境修改成线上一样的启动方式后，本地mac环境一样出现了上面的问题？
那是什么原因导致了异步执行直接被终止呢？因为 threaded=True 的原因？但是linux环境无法配置该选项
在各种尝试毫无办法的时候，看看具体的调用
executor.submit(PlanController(req.get('planId')).load_and_scheduling，builder=req.get('builder'))
更换一下传参的方式
executor.submit(PlanController(req.get('planId')).load_and_scheduling(builder=req.get('builder')))
再次运行，发现竟然可以了！！！两种方式均可以，但是为什么第一种异步执行1s后被强制悄悄的终止了，原因现在仍未知