Handle delivery problems
Delivery Failed reports that an assigned order could not be completed at the customer phase. It is a consequential order-status mutation, not a support note or preview. A visible control, open modal, image preview, GPS read, changed card, or returned order does not prove that the failure or every follow-on effect completed.
:::warning Delivery Failed can change order and assignment behavior
The final Delivery Failed can write the order, history, reason/comment and location trail, and start logistics, queue, notification, socket, plugin, and job work. Do not select it to test visibility, permissions, GPS, image capture, or documentation.
:::
Availability
Current Driver App source can present Delivery Failed for customer-phase states shown as pickup completed, almost arrived at customer, on the way, or arrived at customer. Visibility also depends on project-specific presentation, reject-control configuration, order/loading state, connectivity, and the local permission gate.
The control is not eligibility proof. The App does not apply the separate
Driver may reject orders gate used by the plain request-rejection action. API
ownership, order lock, target status and other validation remain separate.
Opening the failure form requires the App's local permission gate and mounts a GPS hook. The delivery-failure status itself is not in the form's local location-requirement list, so the candidate position is not appended by this modal. A later backend path can still read stored Driver location for an optional status trail.
Before you start
- Confirm that the order is the intended authorized active delivery and that a real delivery problem prevents completion.
- Review the customer-phase status and current assignment with the dispatcher when uncertain.
- Prepare a truthful reason and meaningful comment. Do not use whitespace to satisfy the weak comment check.
- If an image is required, capture only evidence requested for this order.
- Wait for any current order or provider loading state before continuing.
Complete the task
- In the active delivery detail, select Delivery Failed once.
- If Request permissions opens, stop and review the permission state before returning. Returning does not prove an effective grant or valid GPS.
- In Delivery Failed, select a Reject reasons option when one accurately describes the problem. The dropdown reason is optional in the current App.
- Enter a clear, meaningful comment in Please type your comments in here. The final control is disabled while the comment is empty.
- If Upload status image appears, capture the requested evidence, review the preview, and use Remove image when it is incorrect.
- Select the final Delivery Failed once. Wait while the order is loading; do not repeat the action if the modal or order state remains unclear.
Opening the form can read GPS even though the failure request does not attach that candidate location. Image upload, status update, stored location trail, notifications and other follow-ons are independent stages.
Verify the result
| Observable result | Safe interpretation |
|---|---|
| Delivery Failed absent | Current status/project/configuration did not present the control |
| Request-permissions screen | Local permission gate did not admit the modal |
| Delivery Failed modal | Local reason/comment form is open and GPS work may have started |
| Final button disabled | Comment, configured image, or order loading remains unresolved |
| Image preview | Local media candidate exists; upload/status are not accepted |
| Order loading | C05 status request is unresolved |
| Error state | One request layer reported failure; upload/order/trail/provider effects still require reconciliation |
| Modal remains visible | The inline form has no uniform successful-close receipt |
| Order/card/status changes | Client/returned state changed; durable failure and all follow-ons are not proved |
If the outcome is unclear, do not submit again or choose Complete delivery. Ask the dispatcher to verify the current order, assignment, failure reason, media and any logistics state.
States and variations
Visibility and project branch
The customer-phase control set is source-defined for four returned states. A project-specific condition can further limit control presentation, and the reject-controls configuration can hide Delivery Failed. Visibility is local presentation, not current service eligibility.
Reason and comment
The form offers predefined failure reasons, including an Other option. The dropdown is optional; comment is required by truthiness. Whitespace-only comment passes the client check, so public guidance requires meaningful text.
Configured image
When the status-image rule includes delivery failure, the form requires camera media before submission and sends multipart data. Without the rule, it sends a JSON status/reason request. Neither branch proves upload, persistence, or rollback.
Location boundary
The modal GPS hook reads a candidate position on mount, but delivery failure is not locally location-validated and does not append that position. Current API source can write a feature-gated order location trail using stored Driver location after status changes. Candidate GPS, stored location and trail remain separate and are not freshness/trust proof.
Troubleshooting
Delivery Failed is missing
The returned state, project presentation, reject-controls configuration, loading, or connectivity can hide it. Refresh the order once if operationally needed and contact the dispatcher; do not change another status to reveal it.
The reason list does not describe the problem
Choose Other only when accurate and explain the situation in the required comment. Do not select a false reason merely to enable submission.
GPS activates when the form opens
The form mounts a location hook, but its candidate is not part of the delivery- failure request. Do not refresh GPS or open Settings as a test. Follow Understand Driver permissions for permission boundaries.
A required image cannot be captured
Keep the failure unsubmitted and report the capture issue. Do not reuse unrelated media or disclose customer/order evidence outside the approved workflow.
The modal remains after submission
Do not press Delivery Failed again. Ask the dispatcher to reconcile the order and any partial upload, trail, notification, logistics or queue effects.
Related guides: Understand an active delivery · Complete a delivery · Complete pickup · Understand Driver permissions