Unknown results: verify before shipping again
UNKNOWN means remote shipment may have committed but its response was lost. It is not a confirmed failure. Preserve the original task/command and verify the receipt for that command.
Causes
A disconnect after sending, a committed remote transaction with a lost response, or a worker stopping mid-send can leave an unknown result. A sent command cannot be declared failed merely because it timed out.
Verification sequence
1. Record the original command ID, source reference, state and last reason in task details.
2. Check source health and worker heartbeat; fix key/bot access denial first.
3. Use Check now on the original UNKNOWN command and wait for background receipt verification.
4. If applied, the same identifier retrieves the saved result; only a confirmed absent receipt can lead to applying with that same identifier.
5. Confirm APPLIED/SHIPPED or send non-secret details to an administrator if uncertainty persists.
Retry versus receipt verification
RETRY_WAIT waits after non-delivery or temporary refusal. UNKNOWN observes the receipt first and stays unknown while inconclusive; repeated attempts do not prove no shipment. Check now advances scheduling, not guaranteed completion time.
Restrictions while waiting
Do not delete the original command, recreate orders/tasks, ship again in Odoo, or create a differently identified duplicate. Reprinting is not proof of posting. Ask an administrator about source conflicts, persistently unreadable receipts or access that cannot be restored. Source conflicts use status CONFLICT.
Can a long-running UNKNOWN be treated as failure and redone?
No. Timeout does not prove non-execution. Read the same command's receipt, retain its identifier and have an administrator resolve source/connectivity problems.
Did Check now fail to send if nothing changed?
It only schedules earlier background processing. Check worker, source health and command times. An inconclusive receipt remains UNKNOWN; do not recreate shipment.