The send result is uncertain
Uncertain means the provider neither acknowledged the message nor refused it — the connection dropped, or a call timed out after the message may already have been accepted. Connect shows that honestly instead of picking an answer. It resolves with evidence: the provider's own sent folder, or a reply from the person you wrote to.
What the symptom looks like#
The reply sits on the thread marked as uncertain rather than as sent or failed, and an entry appears in Needs You. Nothing further happens to it on its own. That is deliberate, and it is the least comfortable of the three states precisely because it asks a person to look at something outside Connect before deciding.
It is a genuinely different state from a failure. A failure is a definite answer from the provider — the reply would not send covers those. Uncertain is the absence of an answer, and treating one as the other is what produces either a duplicate in a customer's inbox or a reply nobody ever sent.
Why nothing is re-sent automatically#
A message is only ever reported as sent when the provider acknowledges it. That rule is what makes the sent state worth anything: without it, 'sent' would mean 'handed over and hoped for', which is not evidence a customer would accept and not evidence a colleague should rely on.
The consequence is that the missing acknowledgement has to be shown rather than resolved. Guessing in one direction delivers the same reply twice, which is worse than a late reply and reads as carelessness. Guessing in the other direction marks a delivered message as failed, so the thread is answered again by somebody who believes nothing went. Neither guess is cheaper than asking a person to look.
| State | What it means | What changes | What can fail |
|---|---|---|---|
| Sent | The provider acknowledged the message | A sent record with the provider's evidence | Nothing — this is the state everything else is measured against |
| Failed | The provider refused it | A failure record on the thread | Retrying a permanent rejection instead of correcting the address |
| Uncertain | No answer either way | A record marked uncertain and queued in Needs You | Resolving it by assumption; both assumptions are wrong roughly half the time |
How it resolves, stage by stage#
- Trigger — a send through
outbound.pycompletes without an acknowledgement. - External event — a dropped connection or a timeout, on the provider's side of the boundary.
- Authentication and workspace resolution — the message belongs to one mailbox in one workspace, which is where the evidence must be looked for.
- Ingest — nothing further is fetched about this message; Connect does not poll the provider for a verdict it was never given.
- Canonical record — the reply stays on the thread with an uncertain state, complete and unchanged.
- Classification — uncertain is recorded as its own state rather than being folded into failure.
- Knowledge, memory and rules — untouched; an unconfirmed send teaches nothing.
- Autonomy and approval — a person is asked, because this is precisely the class of decision autonomy exists to route to a human.
- Action — somebody checks the mailbox's own sent folder at the provider.
- Result — the state is settled from evidence: it went, or it did not.
- Relationship, timeline and memory — the timeline shows what actually happened rather than what was assumed.
- Audit, usage and Needs You — the resolution is recorded, and the queued entry clears once the state is settled.
What Connect did complete#
- The reply was written, approved where approval was required, and passed every compliance check.
- It was handed to the provider through the one send boundary a person's own send uses.
- The uncertain outcome was recorded rather than rounded to the nearest convenient answer.
- The item was raised in Needs You, because an unresolved send is somebody's problem rather than a log line.
What Connect did not complete#
- It did not confirm delivery, and it will not claim to have done so.
- It did not try again. A silent second attempt is how a customer gets the same reply twice.
- It did not mark the thread as answered, so the conversation is still open work.
- It did not create a follow-up from a commitment inside a message that may never have arrived.
What you can do, and when to escalate#
Open the mailbox at the provider and look in its sent folder.
Result This is the evidence. A copy there means the message went; no copy, after a reasonable wait, means it did not.
Check the thread for a reply from the customer.
Result An answer is stronger evidence than any log — somebody replying to a message received it.
If it went, mark the thread as handled and move on.
Result The record now matches reality, and nobody sends a second copy later.
If it did not, send it again from the same thread.
Result The re-send passes the ordinary gates and carries the provider's acknowledgement this time.
If you must send again while still unsure, say so in the first line.
Result A duplicate that acknowledges itself costs a sentence; an unacknowledged one costs credibility.
An administrator can check whether uncertain sends are clustering on one mailbox or one time window, which usually points at a network or provider problem rather than at anything in the workspace. Escalate when they recur rather than when one appears — a single uncertain send is a normal consequence of an honest boundary, and a pattern of them is a fault.
Questions#
Why does Connect not simply check whether the message is in the sent folder?
Because a missing acknowledgement and a missing copy are not the same thing, and the answer can change while you look. The provider's sent folder is evidence for a person to weigh alongside the thread, not a substitute for the acknowledgement that never came.
Does an uncertain send count against the daily allowance?
The work was done and is metered like any other send. That is another reason not to re-send reflexively: a blind retry spends allowance on a message that may already have arrived.
Can the state change on its own later?
Not from silence. It changes when evidence arrives — most often the customer's own reply, which settles the question completely.