你的问题应该这样来理解：
1）当A刚离线（非正常退出），服务端没有到30秒超时时间，所以服务端其实根本不知道A是否在线（或者说，服务端认为A是在线的），因为它没有办法，只能等到心跳超时时间到后，才能准确地知道A不在线；
2）当1）这种情况发生时，B向A发送消息，A肯定收不到，服务端也不会走onTransBuffer_C2C_RealTimeSendFaild_CallBack，因为服务端一直认为它是在线的（因为没有到超时时间呢，A的状态还是一直是“在线”的）；
3）1、2这种情况，在算法上来说，其实是正常的，因为MobileIMSDK的底层算法还有最后一层保证：即每一条消息，对方是否真的收到，是以发送者收到对方发过来的ACK确认包才算数的。所以，即使此时服务端把A当在线，把消息转发过去，且A没有收到的情况下，服务端也不会通知离线处理，这种逻辑也是合理的：因为B在这种情况下，就不会收到A的ACK包，在B这边，是可能通过MessageQoSListener收到哪些消息没有被对方收到的回调通知的，这种情况在，在主流的APP界面里，可以在消息气泡边上显示一个红色小图标，表示此条消息历经各种复杂情况，但不管怎么样，对方就是没有收到，就像下图这样：


综上所述，你帖子里提到的情况，其实是im通信过程中丛多复杂情况中的一种，但MobileIMSDK已经考虑到并通过回调告诉你了（只是这个回调通知是在客户端）。具体，你可以看看这个帖子里的讨论：《[已回复] 当MobileIMSDK的客户端收不到对方的ACK应答包时会发生什么？》

你的问题应该这样来理解：
1）当A刚离线（非正常退出），服务端没有到30秒超时时间，所以服务端其实根本不知道A是否在线（或者说，服务端认为A是在线的），因为它没有办法，只能等到心跳超时时间到后，才能准确地知道A不在线；
2）当1）这种情况发生时，B向A发送消息，A肯定收不到，服务端也不会走onTransBuffer_C2C_RealTimeSendFaild_CallBack，因为服务端一直认为它是在线的（因为没有到超时时间呢，A的状态还是一直是“在线”的）；
3）1、2这种情况，在算法上来说，其实是正常的，因为MobileIMSDK的底层算法还有最后一层保证：即每一条消息，对方是否真的收到，是以发送者收到对方发过来的ACK确认包才算数的。所以，即使此时服务端把A当在线，把消息转发过去，且A没有收到的情况下，服务端也不会通知离线处理，这种逻辑也是合理的：因为B在这种情况下，就不会收到A的ACK包，在B这边，是可能通过MessageQoSListener收到哪些消息没有被对方收到的回调通知的，这种情况在，在主流的APP界面里，可以在消息气泡边上显示一个红色小图标，表示此条消息历经各种复杂情况，但不管怎么样，对方就是没有收到，就像下图这样：


综上所述，你帖子里提到的情况，其实是im通信过程中丛多复杂情况中的一种，但MobileIMSDK已经考虑到并通过回调告诉你了（只是这个回调通知是在客户端）。具体，你可以看看这个帖子里的讨论：《[已回复] 当MobileIMSDK的客户端收不到对方的ACK应答包时会发生什么？》