Message send reports success but Wi‑Fi drop causes connection error on same message; later messages fail (Smack 4.4.5 Android)

Smack Smack Support
1

Hi all,
I’m using Smack 4.4.5 on Android (smack-tcp, smack-android-extensions, smack-experimental, and also smack-streammanagement is on the classpath). I’m facing an issue with message sending semantics when the network drops mid‑burst.

Setup

  • Android app, Kotlin.
  • Connection is XMPPTCPConnection.
  • Stream Management is enabled via defaults:
    • XMPPTCPConnection.setUseStreamManagementDefault(true)
    • XMPPTCPConnection.setUseStreamManagementResumptionDefault(true)
  • Messages are sent sequentially (one at a time from a scheduler/queue).
  • For 1:1 chats I use chat.send(message) (Smack chat2). For group chats I use xmppConnection.sendStanza(message).

What I’m observing
If I send a sequence of messages (e.g. 20 messages):

Scenario A – firewall blocks server port before/while starting:
If I block the server TCP port with a firewall rule (so the server is unreachable), sending fails in a predictable way (exceptions / not connected) and I can mark messages as not sent. No unexpected behavior.

Scenario B – Wi‑Fi drops while sending (after some messages already went out):
If I start sending messages and then physically disable Wi‑Fi (or otherwise cut the network) during the sequence:

  • Messages 1..4 are sent normally.
  • Message 5: my send call returns without error (so my app considers it “sent”).
  • During/after that send, Smack later reports a connection error, transitions to NotConnected, and all subsequent messages (6..20) fail.
  • The confusing part is that message 5 appears as “sent” from the app point of view, but it is also the message that seems to trigger the connection failure (or is the first impacted by it). So I end up with an inconsistent state: message 5 reported as sent even though the connection broke right there.

Expected behavior (what I need to understand)
I understand that sendStanza() / chat.send() may be asynchronous and/or enqueue outgoing stanzas. However I’m trying to understand:

  • What does it mean exactly when chat.send() / sendStanza() returns successfully while the network is about to drop?
  • Is it expected that the call returns successfully because the stanza was queued, but then the actual socket write fails later and the connection enters NotConnected?
  • Is there any recommended way in Smack to detect that a stanza was actually written to the stream / delivered to the server vs only enqueued (especially in the presence of Stream Management)?

Questions

  1. In Smack 4.4.5, is “send returned without exception” only a guarantee that the stanza was queued, not that it reached the server?
  2. When Wi‑Fi drops and a stanza is in-flight, does Smack expose any callbacks/events that can help applications reconcile “message was considered sent” vs “connection failed while sending”?
  3. Are there best practices to avoid reporting a message as sent too early in this scenario?

Thanks in advance for any clarification.