哪些情况会触发SimPy异常“No scheduled events left but 'until' event was not triggered”

你遇到的RuntimeError: No scheduled events left but "until" event was not triggered是simpy的标准报错，不属于simpy内部漏洞。本质是你调用env.run(finished)指定了仿真终止条件为finished（也就是报错里提到的<Process(run)>进程）触发，但是仿真运行过程中所有待执行的事件都处理完了，这个终止条件还没有被触发，仿真没有后续事件可以执行，只能被迫中断。

• 核心进程逻辑提前终止：你指定的作为终止条件的run进程意外退出，既没有正常执行完成触发终止信号，也没有调度新的后续事件，导致事件队列逐步被清空
• 事件依赖链断裂：仿真逻辑中存在分支遗漏，比如某个条件判断下没有调度后续事件，或者某个等待的事件永远不会被触发（比如等待一个已经被销毁的资源释放、等待的信号被取消后没有兜底逻辑）
• 大规模场景下的时序竞态：小负载下事件的执行顺序符合你的预期，大负载下事件调度顺序发生变化，导致原本应该被触发的事件没有被触发，比如你预期A事件会给B进程发信号，但实际B进程先于A事件执行完退出，没有等待信号也没有后续逻辑
• 事件对象意外丢失：大规模场景下某些临时事件对象被Python垃圾回收机制提前回收，没有被正常加入simpy的事件调度队列，你以为已经提交的事件实际没有进入执行队列

• 给核心进程加全链路日志和异常捕获：重点监控报错中提到的run进程，给整个进程逻辑加上try-except捕获所有未处理异常，同时在进程启动、每个关键步骤执行、进程退出（正常/异常）时都打印日志，确认进程是否提前意外终止
• 给simpy添加事件调度日志：你可以在本地修改simpy的core.py文件，或者在自己的代码中给事件调度加钩子，每次有新事件加入队列、有事件执行完成时都打印事件的标识和触发时间，最后队列为空前的几个事件就是排查重点
• 缩小复现场景的规模：逐步降低大规模场景的参数（比如任务数、资源数、仿真时长），每次调整后多次运行验证是否能复现问题，找到能稳定复现问题的最小参数集，大幅降低排查难度
• 检查逻辑分支的完备性：遍历所有涉及事件调度、资源等待、信号等待的逻辑分支，确认每个分支下都有后续事件调度，对于等待外部信号的逻辑，建议添加超时机制，避免出现永远等待的情况
• 验证事件对象的生命周期：确认所有需要被调度的事件对象都有长期引用，不会被GC提前回收，尤其是大规模场景下动态生成的临时事件，不要只作为局部变量使用

内容的提问来源于stack exchange，提问作者Christian Menard