Rebus一级重试场景下获取历史投递尝试异常的方法咨询

IErrorTracker注入说明 #

• 不推荐直接将IErrorTracker注入到业务消息处理器中。该接口属于Rebus的内部服务，仅面向框架自身的重试、死信队列等核心逻辑提供能力，没有对外的兼容保障，版本迭代时可能出现无预告的破坏性修改，直接依赖会大幅提升后续框架升级的风险。
• 如果你确定需要直接使用IErrorTracker的能力，可以在Rebus配置阶段手动将其注册到依赖注入容器中，后续即可在处理器中注入使用，.NET Microsoft DI环境下的参考配置如下：

services.AddRebus(config => config
    // 你的其他Rebus配置，比如传输、路由、序列化器配置
    .Options(opt => {
        opt.Decorate<IErrorTracker>((tracker, sp) => {
            services.AddSingleton(tracker);
            return tracker;
        });
    })
);

注意该方式需要自行承担版本兼容风险。

上一次投递异常的稳定获取方式 #

官方推荐通过IMessageContext读取消息头的方式获取异常信息，该方式跨版本兼容：

• 首先在消息处理器中注入IMessageContext实例
• Rebus每次消息投递失败后，会自动将异常的类型、信息、调用栈等内容序列化后存入消息头的rbs2-error-details字段，直接从IMessageContext.Headers中读取该key对应的内容即可获取上一次投递的异常详情。
• 如果你需要结构化的异常对象，对该字段的JSON内容做反序列化处理即可。

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