keep record latch message when reset buffer

[jian-dong]

Hello, Have any plan keep record latch message?

[DLu]

I don't recall what the current behavior is. Do the latched messages fall out of the recording window?

[jian-dong]

I see the code, when flush recording buffer, every message will be drop.

[Timple]

Looks like they are dropped.

A keep-last option would work for all topic types I guess. Or one has to inspect if it is a latched topic like so.

[Timple]

@jian-dong

Is this issue no longer relevant for you? For us it is (not highest prio at the moment though). Would you mind keeping it open 'for the record'?

[jian-dong]

@Timple Thank you for caring about this issue, now I use a temporary way be work around, just resend latch message when play bag.

[arneboe]

This issue is also relevant for us :-) Right now we are still using a fork that I made when this was still a PR but eventually we would like to switch to upstream and this feature would be much appreciated. Maybe I will get around to implement it in our branch and merge it upstream

[gavanderhoorn]

Related ROS Answers (I believe posted by @arneboe): Is it possible to know if a topic is latched on subscriber side in cpp.

[arneboe]

Related ROS Answers (I believe posted by @arneboe): Is it possible to know if a topic is latched on subscriber side in cpp.

yep that was me (sorry for the double post btw.). I am implementing this right now in our fork and will hopefully provide a PR within the next week :-)

[Timple]

Another option would be to drop all connections and re-subscribe to all topics. All the latched topics would be send again.

Note: This might result in some message loss in-between bagfiles (we don't care).

[ayrton04]

+1. It seems like using the same logic we use here should work.

[eborghi10]

You can just use this and it'll keep the first message:

- /tf_static:
    duration: -1