自定义Django Signal Receiver在Wagtail部署环境中未触发问题

可能原因及对应处理方案 #

1. 接收器注册时机错误 #

• 避免将接收器注册逻辑放在if __name__ == "__main__"代码块中，Cloud Foundry环境下应用启动入口通常不会触发这个分支，导致注册逻辑未执行。
• 把注册逻辑移到应用初始化的全局代码中，比如框架的启动钩子（如Django的apps.py的ready()方法）或主启动脚本的顶层代码里。

2. 模块重复导入导致dispatcher实例不一致 #

• 检查代码中是否混用相对导入和绝对导入，导致多次导入时生成了不同的dispatcher实例，注册的接收器只存在于某个实例中。
• 统一使用绝对导入获取dispatcher，并在注册和发送信号的位置打印id(dispatcher)，对比本地与staging环境的实例ID是否一致，确认是同一个实例。

3. 多进程模式下的接收器丢失 #

• 如果应用使用多进程启动（比如Gunicorn多worker），默认fork后的worker进程不会继承父进程的接收器注册状态。
• 可以通过Gunicorn的--preload参数预加载应用，让接收器在worker fork前完成注册；或者在worker进程的初始化钩子中重新执行接收器注册逻辑。

4. 自定义dispatcher的状态问题 #

• 若使用的是自定义信号dispatcher，确认其实现了单例模式，且在进程内状态能保持稳定。如果是跨进程的信号场景，内存型dispatcher无法共享状态，需要改用消息队列（如Redis）实现分布式信号分发。

5. 补充调试日志 #

• 在staging环境中添加更细致的日志：
  • 注册接收器后立即打印dispatcher.receivers的内容和长度，确认注册操作确实生效。
  • 在调用dispatcher.send前后，打印当前进程ID、dispatcher实例ID，排查是否是不同进程/实例导致接收器列表为空。

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