Understand order messages
Customer App can present order-message entry from the profile message list or from an eligible order. Availability, participants, history, attachments, and delivery depend on the current account, order, project, and configured service.
Treat the message area as an active feature. Opening or refreshing it can load order data and can request a read-state update. It is not a read-only archive.
Recognize the entry surface
| Surface | What it can mean | What it does not prove |
|---|---|---|
| Profile message list | The current account has an order entry that may open a thread | That the full history is current or that every listed order is message-eligible |
| Order details | A business or driver message action is conditionally available | That both participant views exist or share the same history |
| Message thread | Customer App is presenting messages for one order and participant view | That opening is side-effect free, or that all participants can see every item |
| Realtime or push notice | A message-related event may be available to reconcile | That the message was delivered, displayed, read, or still belongs to the current account |
If an entry is absent, do not infer that the order, participant, or message history does not exist. Eligibility and visibility require an authorized, current-state check.
Keep message states separate
| State | Safe interpretation |
|---|---|
| Thread requested | Customer App has begun loading one order context |
| History presented | A response is visible for the selected participant view |
| Read update requested | The app has attempted to update read state; the visible thread is not proof of acceptance |
| Draft entered | Text exists locally and has not been sent |
| Attachment selected | Media is staged locally and has not been uploaded or sent |
| Send requested | Customer App has started a message operation |
| Accepted response | A service response was returned; recipient delivery and read remain separate |
| Realtime update | A socket event was received and may need duplicate, order, account, and participant validation |
| Push presented or opened | An OS/provider event was presented or routed; authoritative thread state still must be reconciled |
| Unknown outcome | A response was lost, the app changed state, or the account/project changed before settlement was established |
Do not send again solely because a message is missing from the local thread. After a timeout, disconnect, or app interruption, treat the outcome as unknown until the current authorized thread is reconciled. Customer App does not offer a documented exactly-once delivery guarantee.
Participant and visibility boundaries
A thread can distinguish business and driver participants. A message may also have an audience different from the currently selected view. The current account must be authorized for the exact order, participant, and message before content or media is shown, copied, marked read, or sent.
Changing participant, order, account, or deployment context must invalidate the previous thread state. A stale title, avatar, unread count, draft, attachment, socket event, or push notice is not authorization to reuse the prior context.
Opening and read state
Opening a thread can cause both message loading and a read-state request. More than one local trigger can request the same read update while the thread loads or changes participant view. A duplicate request must not be interpreted as a second customer action, and a cleared unread indicator does not prove that the service accepted the update.
If an unread indicator changes unexpectedly, refresh the authorized thread once. Avoid repeatedly opening and closing it while settlement is unknown.
Text and attachments
Typing, choosing media, and sending are distinct actions:
- A text draft remains local until an explicit send action begins.
- Selecting an attachment can invoke the operating system's media picker and stage a local preview; it does not upload or send the file by itself.
- Removing the preview should affect only the staged attachment.
- Sending text and sending media can have different size, permission, privacy, encoding, and failure boundaries.
- Copying message text uses a device clipboard and can expose content outside Customer App. Use it only on a trusted device and clear sensitive content according to your device policy.
The current interface can clear a draft and staged media when a send starts. If the response fails or is lost, the draft or attachment may not be recoverable. Do not assume a cleared composer means the message was accepted.
Realtime, push, and privacy
Socket updates, push delivery, and the authoritative thread are separate channels. Reconnects can replay or delay events. Event content must be minimized and matched to the current account, project, order, participant, and session before presentation. A push preview can also appear on a device lock screen, outside the authenticated Customer App view.
Signing out, switching accounts or projects, closing the thread, or revoking the relevant consent must stop further use of the former context. Message-room listeners, provider identity, cached thread state, drafts, attachments, and pending callbacks require cleanup. A late event from the former context must be ignored.
Troubleshoot safely
| Symptom | Safe response |
|---|---|
| Message entry is missing | Confirm the current account, project, order, participant, and connection; do not infer nonexistence |
| History is empty or fails to load | Retry one authorized refresh; do not send a test message |
| Unread state changes unexpectedly | Reconcile the current thread; do not use the badge as a service receipt |
| Send remains busy or returns an error | Preserve the unknown outcome and reconcile before another send |
| Draft or attachment disappears | Do not infer upload or delivery; reselect only after the thread state is known |
| A message appears twice | Do not delete, resend, or acknowledge it as two messages; refresh and reconcile |
| A push opens a stale or wrong context | Leave the thread, verify the active account/project, and reopen from an authorized in-app surface |
| Content appears for the wrong order or participant | Stop, avoid copying or sharing it, sign out if safe, and contact support through an approved channel |
Do not troubleshoot by changing OS permissions, sending real content, choosing personal media, copying private text, repeatedly reconnecting, or switching accounts while an operation is unsettled.
Accessibility expectations
Message entry, participant selection, unread state, attachment preview/remove, composer, send/busy/error state, message author and time, and new-message announcements need distinct semantic names, roles, states, and predictable focus. Screen-reader order must follow the visible conversation without reading hidden participant content. Keyboard appearance, large text, safe areas, and iOS/Android back behavior must not hide the composer or strand focus.
Do not use color, avatar, alignment, or an unread badge as the only indication of author, participant, state, or error. Attachment controls require a text alternative and a separately reachable remove action. These are verification requirements, not a claim of current accessibility certification.
Recertification triggers
Revalidate this reference after changes to thread entry, order or participant authorization, read-state behavior, message audience, draft retention, attachment handling, socket rooms/listeners, push content or routing, consent, session/account cleanup, platform permissions, navigation, or accessibility. Source inspection alone does not certify deployed behavior.
Related guides: Understand order details and status · Understand orders and support · Get help with an order · Understand offline and reconnect behavior · Understand privacy and consent · Understand platform and accessibility behavior