direct message with path is marked as "Delivered" immediately, even if no ACK is received at all. #163

New Issue

2026-10-27T15:41:54+01:00

adam commented

2026-10-27 15:41:54 +01:00

Describe the bug

When I send a direct message and the path is already known, it immediately shows "Delivered" even if no ACK is received.

I know this because the recipient is offline.

Which device are you using

LilyGO T-Deck Plus

Which Firmware are you using

v0.9.11

To Reproduce

Write a direct message to a contact where there is already a path (no "Flood") and the recipient is not reachable via that path (or not reachable at all)
Tap on the message
See status "Delivery: Delivered"

Expected behaviour

Show "Pending" or "Failed" until an ACK is received.
Show "Delivered" only when an ACK is received.

**Describe the bug** When I send a direct message and the path is already known, it immediately shows "Delivered" even if no ACK is received. I know this because the recipient is offline. **Which device are you using** LilyGO T-Deck Plus **Which Firmware are you using** v0.9.11 **To Reproduce** 1. Write a direct message to a contact where there is already a path (no "Flood") and the recipient is not reachable via that path (or not reachable at all) 2. Tap on the message 3. See status "Delivery: Delivered" **Expected behaviour** Show "Pending" or "Failed" until an ACK is received. Show "Delivered" only when an ACK is received.

adam closed this issue

2026-10-27 15:41:54 +01:00

adam commented

2026-10-27 15:41:55 +01:00

improved in v0.9.12

DM delivery status now clearly follows the Mark Delivered Faster setting
- If Mark Delivered Faster is enabled, your reported behavior still happens by design.
- If Mark Delivered Faster is disabled, behavior matches your expected ACK-only Delivered semantics.

improved in v0.9.12 - **DM delivery status now clearly follows the Mark Delivered Faster setting** - If Mark Delivered Faster is enabled, your reported behavior still happens by design. - If Mark Delivered Faster is disabled, behavior matches your expected ACK-only Delivered semantics.

adam commented

2026-10-27 15:41:55 +01:00

If Mark Delivered Faster is enabled, your reported behavior still happens by design.

If Mark Delivered Faster is disabled, behavior matches your expected ACK-only Delivered semantics.

As I understand the upstream information about "Mark Delivered Faster", it is not meaning to mark as delivered as soon as one repeater is heard repeating the own message, but as soon as the ACK, coming back from the recipient, is heard, even if the ACK is heard not coming back the exact same path as the message was sent (e.g. when you send [own device] -> [ab] -> [09] -> [ce] -> [recipient], and the ACK is heard [recipient] -> [ce] -> [own device], "Mark Delivered Faster" would then mark the message as delivered while otherwise it would only be marked as delivered if the whole path is followed back).

But I am not sure.

Here is what I find to read:

https://forum.letsmesh.net/t/meshcore-app-v1-36-0-for-ios-android-and-web/175
- added new messages setting to mark outgoing messages delivered faster
- app can now mark messages delivered before an ack has passed through all intended repeaters

Do you have more insights on it, @dabeani?

Regards!

> * *If Mark Delivered Faster is enabled, your reported behavior still happens by design.* > * *If Mark Delivered Faster is disabled, behavior matches your expected ACK-only Delivered semantics.* As I understand the upstream information about "Mark Delivered Faster", it is _not_ meaning to mark as delivered as soon as one repeater is heard repeating the own message, but as soon as the ACK, _coming back_ from the recipient, is heard, even if the ACK is heard not coming back the exact same path as the message was sent (e.g. when you send [own device] -> [ab] -> [09] -> [ce] -> [recipient], and the ACK is heard [recipient] -> [ce] -> [own device], "Mark Delivered Faster" would then mark the message as delivered while otherwise it would only be marked as delivered if the whole path is followed back). But I am not sure. Here is what I find to read: * https://forum.letsmesh.net/t/meshcore-app-v1-36-0-for-ios-android-and-web/175 > - *added new messages setting to mark outgoing messages delivered faster* > - *app can now mark messages delivered before an ack has passed through all intended repeaters* Do you have more insights on it, @dabeani? Regards!

adam commented

2026-10-27 15:41:56 +01:00

@dabeani, are you really sure that "Mark Delivered Faster" is the official by-design behaviour that it is marked as delivered when the own packet is heard to be repeated?

Because other sources say that it means "mark as delivered" if an ACK is heard (and only then), BUT the ACK is allowed to come back via another path than the intended path.

Regards!

@dabeani, are you really sure that "Mark Delivered Faster" is the official by-design behaviour that it is marked as delivered when the own packet is heard to be repeated? Because [other sources](https://matrix.to/#/!zsKeYAmLCJicjJBdhO:matrix.org/$tbKV7MiM74ETfW0csKGFDjsO0VwmFviNymBnTEcrl3Y?via=matrix.org&via=darc.de&via=tchncs.de) say that it means "mark as delivered" if an ACK is heard (and only then), BUT the ACK is allowed to come back via another path than the intended path. Regards!

adam commented

2026-10-27 15:41:57 +01:00

@dreirund you are right!

if (pkt->isRouteDirect() && pkt->getPathHashCount() > 0) {
if (pkt->getPayloadType() == PAYLOAD_TYPE_ACK) {
...
onAckRecv(pkt, ack_crc);
}
}

I will correct this implementation!
Thank you for digging deeper.

@dreirund you are right! if (pkt->isRouteDirect() && pkt->getPathHashCount() > 0) { if (pkt->getPayloadType() == PAYLOAD_TYPE_ACK) { ... onAckRecv(pkt, ack_crc); } } I will correct this implementation! Thank you for digging deeper.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/meshcore#163