Antylogic
DemoApp login

399 operational guides

Docs sections
DocsTPV and KDS
Device

Retry a failed output job

Send a failed print or KDS job back to the TPV output queue without creating a new job. The retry keeps the same `tpv_output_job`, moves it to `pending`, clears the visible error message and lets the terminal runtime process it again when a compatible active output device is available.

In this article

Use this guide when a receipt, invoice or KDS output job has failed during service and the operator needs to try it again from the TPV queue.

The action is a recovery step, not a reprint from scratch. Antylogic updates the existing output job, removes the old visible error and returns it to the queue for the current terminal scope.

Before you start

  • Sign in to `Harbor Demo Group` and open the `Harbor Soho` location.
  • The TPV workspace must have an active service session, because the output queue is loaded for that `service_session_id`.
  • The operator must be able to use TPV and open the print/KDS queue. In the UI, the queue entry point requires TPV print or manage access.
  • If TPV staff access appears, select `Olivia Hart` before opening the workspace.
  • At least one failed `tpv_output_job` must be visible for the current terminal scope. Only failed rows show `Retry`.
  • For automatic processing after retry, the related `tpv_output_device` must be active and a compatible local adapter must be available.

Instructions

  1. 1.

    Open the TPV

    Open the Harbor Soho TPV on the floor tab. If the staff selector is shown in the capture runtime, choose Olivia Hart so the TPV workspace becomes available.

  2. 2.

    Open the print and KDS queue

    From the TPV workspace, open the more-actions menu and choose the print and KDS queue. The current product capture uses the implemented labels `Más acciones del TPV` and `Cola de impresión y KDS`.

  3. 3.

    Find a failed job

    Look for a row with failed status. Failed rows can show the previous error message and are the only rows that expose the retry action.

  4. 4.

    Retry the job

    Select `Retry` on the failed row. The app updates the same output job with `status: pending`, keeps or assigns terminal identifiers and sends `error_message` as an empty string.

  5. 5.

    Check the refreshed queue

    After the update succeeds, the queue refreshes and the old error should no longer be shown for that row. The job can then be claimed and completed by the terminal runtime, or fail again with a new error if the adapter cannot process it.

  6. 6.

    Handle retry errors

    If the update fails, keep the operator in the queue and check permissions, terminal scope and whether the job belongs to the current location before trying again.

Validations and limits

  • Only jobs with `status: failed` show the retry action in the UI.
  • Retry updates the existing `tpv_output_job`; it does not create a new output job.
  • The retry payload sets `status` to `pending` and clears `error_message` with an empty string.
  • The backend rejects invalid status values and invalid `terminal_id` values.
  • A job from another location is treated as not found, and insufficient permissions are denied before modification.
  • Retry clears the visible error message, but it does not reset `attempts`, `failed_at`, `claimed_at` or `completed_at`.
  • If no compatible active output device or adapter is available, the job can remain `pending`.

Expected result

The failed output job returns to processing as the same job record, with the previous visible error cleared and the queue ready for the terminal runtime to pick it up again.

Related articles