Summary
On at least one companion registration (personal account, client linked as companion device), every DM sent with LID addressing is rejected by the server with ack error="400" and never delivered — including stanzas built after #731 (consistent LID to + LID participants). The same message sent with pre-0.6 PN addressing (PN fanout, PN sessions, PN to) is delivered within ~2 seconds, with normal Delivered receipts.
Environment
Repro / evidence
With stock addressing (LID, post-#731 shape), every send to the LID-mapped peer logs:
WARN Client/Ack: Received 400 nack for msg Some("3EB089068216561CDEDD91"); the message was likely not delivered (...)
WARN Client/Ack: Received 400 nack for msg Some("3EB04ABF01E55905A9982E"); the message was likely not delivered (...)
No Delivered receipt ever arrives; the recipient never sees the message. Reproducible on every send.
Switching the same build/peer/session to forced PN addressing (an opt-in flag I'm proposing in a follow-up PR): Delivered receipts arrive within ~2s, repeatedly, including full inbound → reply round-trips.
On plain v0.6.0 (pre-#731, before the ack logging existed) the failure was fully silent: send_message resolved Ok, no receipt, nothing in logs — which made this quite painful to diagnose. The first DM to a fresh PN (no cached mapping) is delivered, and every subsequent one is dropped once the LID mapping is learned, which looks like random breakage from the outside.
Side observation
With PN addressing on the same build, each send also draws a 479 (SmaxInvalid) nack (reporting token?) while still delivering fine. Happy to file separately if useful.
Questions
- Is this server behavior known? (LID-incapable registration? account age / pairing vintage?) I could not find a capability check on the send path that would predict it.
- Would you take an opt-in escape hatch that keeps outbound DM addressing on PN (pre-0.6 behavior) for deployments like this? PR incoming — but if you'd rather see an automatic fallback (e.g. retry over PN after a 400 nack on a LID-addressed DM), I'm happy to rework in that direction.
Summary
On at least one companion registration (personal account, client linked as companion device), every DM sent with LID addressing is rejected by the server with
ack error="400"and never delivered — including stanzas built after #731 (consistent LIDto+ LID participants). The same message sent with pre-0.6 PN addressing (PN fanout, PN sessions, PNto) is delivered within ~2 seconds, with normalDeliveredreceipts.Environment
v0.6.0+ cherry-picked fix(send): address LID-mapped DM by LID end to end so the server stops 400-rejecting it #731 (to isolate the stanza-shape fix and get the ack nack logging it added)Repro / evidence
With stock addressing (LID, post-#731 shape), every send to the LID-mapped peer logs:
No
Deliveredreceipt ever arrives; the recipient never sees the message. Reproducible on every send.Switching the same build/peer/session to forced PN addressing (an opt-in flag I'm proposing in a follow-up PR):
Deliveredreceipts arrive within ~2s, repeatedly, including full inbound → reply round-trips.On plain
v0.6.0(pre-#731, before the ack logging existed) the failure was fully silent:send_messageresolvedOk, no receipt, nothing in logs — which made this quite painful to diagnose. The first DM to a fresh PN (no cached mapping) is delivered, and every subsequent one is dropped once the LID mapping is learned, which looks like random breakage from the outside.Side observation
With PN addressing on the same build, each send also draws a
479 (SmaxInvalid)nack (reporting token?) while still delivering fine. Happy to file separately if useful.Questions