View order conversations

The Messages tab presents order-based conversation entries available in the current Driver App state. Each card summarizes an order and can open its order chat. A listed card, unread badge, sort position, or changed status is presentation—not proof of assignment, message delivery, read completion, or fresh server state.

:::warning Opening Messages can start reads and socket activity

Opening the tab requests order data and can join live-update channels. A message event can trigger an order-detail read before changing the local list. Order events update the local list directly. Do not open or refresh Messages repeatedly to test delivery, unread state, or socket connectivity.

:::

Availability

Messages is a signed-in bottom tab. The current Driver experience shows an Orders conversation list; dormant contact-list choices are not part of this visible flow.

Use the list only for orders you are authorized to handle. Driver App can scope current-source order reads to the signed-in Driver, but visibility alone is not an independent authorization or assignment receipt.

Open this capability

Open Messages once and wait for the initial list state to settle. A conversation card can show:

Card item	Safe interpretation
Business name and logo	Returned/local business presentation for the order
Masked Order No.	The card's order context without displaying the full identifier
Delivery date or time	Formatted returned order timing data
Order status label	A UI label for the returned status value
Timing value for selected active statuses	A local calculation from returned timing fields and the device clock
Unread badge	The order's current returned/local unread count

Select a card only when you need to inspect that authorized order conversation. Opening the conversation can start a separate message-list read and a state-changing read-receipt request. See Use order chat for that boundary.

Sort and load the list

The visible tags can request sorting by Newest or Order number. A tag changes the list's sort request and reloads the first page. The resulting order is not a freshness, delivery, or unread guarantee.

When more pages are reported, Load more orders requests the next page and adds orders not already represented by the same ID. Pull-to-refresh can request the first page again. Wait for one request to settle before starting another.

States and variations

Visible state	Safe interpretation
Initial card skeletons	The first order-list request or a sort reload is unresolved
Additional footer skeletons	A later page is loading while existing cards remain visible
Conversation cards	Returned/local orders are available for presentation
Unread badge	Current card state has an unread count greater than zero; no read/delivery completion is implied
Sorry, no results found	The settled current list contains no cards
Network or returned error	The current list request did not produce a usable list state
Load more orders	Another reported page is available and no current page request is loading
Card moves to the top	A socket message caused an order detail read, or an order event updated local list state
Card changes or disappears	A returned order event changed status/Driver data and the local handler updated or removed the card
Business image changes or stays blank	Remote/local image source and cache presentation varied; no identity guarantee follows

Socket updates and page reads can interleave. The current source does not establish a single atomic snapshot across pages, events, unread counts, timing, and order status.

Connection and order-update handlers can remain registered after the visible screen cleanup. Do not treat leaving and reopening Messages as proof that every prior listener was removed or that later updates occur exactly once.

Viewing boundaries

• Do not interpret Newest as proof that the first card has the latest durable message or server event.
• Do not interpret an unread badge, zero count, moved card, or opened thread as a read receipt or delivery receipt.
• Do not send text, add media, or use a real conversation to test list updates. Message writes and read-receipt completion are outside this overview.
• Do not copy business, timing, or order data from the list into public media.
• Do not assume socket join, reconnect, event cleanup, or order refresh succeeded because the list looks current.

Troubleshooting

The list remains on skeletons

Wait for the current read to settle and check connectivity without repeatedly reopening the tab. If the state persists, contact the project operator; do not send a test message to force an update.

No conversations are shown

Confirm that you are signed in with the intended Driver account and that the current list has finished loading. An empty list can reflect current scope, pagination, returned data, or an error; it does not prove that no message records exist.

The unread badge looks incorrect

Treat the badge as returned/local aggregate state. Opening a conversation can start read-related effects, so do not open it solely to clear or test the badge. Ask the project operator to review a persistent mismatch.

A card is missing after a live update

An order event can update or remove a Driver card when assignment data changes. Use the current authorized Orders view and operator support to confirm the order; do not infer reassignment from the Messages list alone.

Load more repeats or reorders cards

Pagination, deduplication, sorting, and live events are separate local stages. Wait for the current page to settle, then refresh once if operationally needed. Do not use repeated loads as a completeness test.

Related guides: Driver App overview · Navigate the Driver App · Use order chat · Understand an active delivery