Skip to content

OP-CHECK-TRACKING-STATUS: Check tracking status

Reads a tracked request's status, optionally polling with a sleep/re-read loop while the status remains Scheduled or Processing.

Field Value
Operation ID OP-CHECK-TRACKING-STATUS
Trigger Client requests GET v1/info/track/{trackingId}
Entry endpoint GET v1/info/track/{trackingId}
Owning component InfoController.CheckPdfTrackingStatus(long, int, int) → PdfTrackingService.CheckPdfTrackingStatus(long, int, int)
Inputs trackingId route segment; retryIntervalMilliseconds, retryCount query parameters
Outputs Bare PdfTrackingInfo (Status, FileId, FilePath, TrackingId)
Failure response No try/catch on this action — any exception produces framework exception detail (IncludeErrorDetailPolicy.Always) before ApiResponseHandler runs; the final client-visible envelope is unknown** (see Endpoints: Error response shape)

Steps

  1. PdfTrackingService.CheckPdfTrackingStatusById reads the PDFTracking row by Id (data model) — bracketed by _uow.Begin()/_uow.Commit().
  2. If tracking is unavailable (_uow == null), the operation degrades gracefully and returns a non-tracked result instead of failing (BR-PDFAPI-012).
  3. While the read status is Scheduled or Processing and the retry budget (retryCount) is not exhausted, the operation sleeps retryIntervalMilliseconds and re-reads the row (BR-PDFAPI-014). With the defaults (retryCount = 0), this is a single read.
  4. The persisted status code is mapped onto the PdfStatus enum (SCHED→Scheduled, PROC→Processing, SUCC/ERROR/CANCE/ABORT→their terminal equivalents) (BR-PDFAPI-011).
  5. A bare PdfTrackingInfo is returned — HTTP 200.

Process flow

The following diagram shows the read-and-optionally-poll sequence used to answer a tracking status request.

flowchart TD
    A["GET v1/info/track/trackingId"] --> B["Read PDFTracking by Id"]
    B --> C{"Status Scheduled or Processing<br>and retries remaining?"}
    C -->|Yes| D["Sleep retryIntervalMilliseconds"]
    D --> B
    C -->|No| E["Map status to PdfStatus"]
    E --> F["Return PdfTrackingInfo"]

Transaction and side effects

Aspect Finding
Unit of work IUnitOfWorkFactory("oracle"), InstancePerRequest (read-only)
Commit point No write — read-only Query() inside Begin()/Commit(), potentially repeated across the poll loop
Records written None
Downstream calls None
Repeat-call behavior Read-only; safe to repeat

Logging

Surface Written content
— No dedicated logging observed on this path beyond framework-level exception logging on an uncaught failure

Error handling

  • Any repository/database exception: no try/catch on this action — escapes to the framework, which produces exception detail (IncludeErrorDetailPolicy.Always) before ApiResponseHandler runs; the final client-visible envelope is unknown** (see Endpoints: Error response shape).
  • Tracking unavailable: degrades gracefully to a non-tracked result rather than failing (BR-PDFAPI-012).

Note: Statements marked with ** could not be confirmed; treat as unknown until verified.

Sources

  • PdfAPI\Controllers\v1\InfoController.cs
  • PdfAPI\Services\PdfTrackingService.cs
  • PdfAPI.Core\PdfTrackingInfo.cs