rumqttc - Get packet id for publish

[shikoku1]

There doesn't seem to be a way to get the packet id for a published QoS1/2 message, to track its state
Is this correct? Is there a workaround?

[tekjar]

@shikoku1 In release R12 (tentative release in 2 weeks), publish method will return packet id on success

[mladedav]

@tekjar @de-sh does in-pipeline mean that there is a PR for this already? I couldn't find anything so I assume this was not released in March, correct?

I have looked around a bit and without changing the structure of client <-> envetloop architecture (where the latter is responsible for choosing packet IDs) I don't think there are other options than #291.

[tekjar]

in-pipeline means we've planned to work on this. This being worked in mqtt v5 PR where we use locks to access eventloop buffers. This allows us to return packet ids in client

[mladedav]

Is it planned also for 3.1.1? I've noticed that the v5 PR explicitly states that it doesn't make changes to lower versions.

I cannot migrate to 5 because of a broker but I would like to know that a message was delivered.

[tekjar]

Yeah also planned in 3.1.1. It's just that all the feedback we've collected is going into v5 first

[mladedav]

Ok, thanks for the clarifications.

[mladedav]

Hi @tekjar . I have noticed that R13 was released with the MQTT5 support, but the publish method still returns Result<(), _>.

Was this pushed further back? This is still planned for 3.1.1, right?

[tekjar]

Yeah this is planned @mladedav . Publish will return pkid. We still need to work on APIs

[svet-b]

Would very much love to see this implemented also. I noticed that in a few previous versions this was available for the v5 client, but was reverted more recently (due to other architectural changes).

Are there any workarounds in the meantime? Calling publish() and then inspecting the ID of the Publish event that's emitted on the loop? (seems brittle, of course, but maybe better than nothing)

[harlem88]

Is there any news about Publish will return pkid on v3.1.1?

[dlips]

Hi, I would also need this functionality. Is there any progress on this topic?

[swanandx]

Hi, I would also need this functionality. Is there any progress on this topic?

Hey @dlips , there was some progress, I created a PoC main...pkid-poc for an approach where we move pkid generation logic in client instead of state, thus allowing us to return pkid. 🚀

but as this lead to use to locks and shared states, this might slow down publishes during contention. The PoC hasn't been thoroughly reviewed yet, as other work was prioritized and lack of maintainers time 😅

other approach could be, instead of returning actual pkid, we can return some token which can be used for tracking packet. But ig it will more or less be same as our client can be cloned and shared between threads?

btw, can you let us know specific use case why you might need this functionality? we might try to figure out some workaround.

thank you :)

[dlips]

I have to send messages to a broker in a reliable way. To this end, I implemented a persistent message queue with rusqlite. Then I send the messages to a MQTT broker with QOS 1 and would like to remove the messages from the queue/db if I get the ACK for them.

[cartertinney]

I also need this. I need the ability to track when an ack for a specific publish is received.

[leoedin]

We can't see a way to implement functional QoS 1 or QoS 2 without being able to match sent packets with the received PubAck ID. This would give us one way of doing that.

If there's complications with locks, could you instead allow the user to pass in something when calling .publish() which is then passed to the event loop via the Event::Outgoing::Publish enum? The event loop handler would then have both the user token and pkid. I think that change can be implemented with fairly minimal code changes.