Retry, Fix, or Give Up

Retry, Fix, or Give Up

Every night a batch job pushes staged ledger lines to a legacy posting service — and every night one bad line kills the whole run, leaving hundreds of untouched lines behind it. Not all failures deserve the same treatment: a line with broken data must wait for an operator to fix it, a service outage will resolve itself by the next run, and a truly unexpected error should be parked so a human can investigate. Your job is the triage layer behind every robust batch job: catch each failure, classify it, route it — and never let one line stop the run.

What you get

The starter ships four objects. Keep all four exactly as given and include them in your submission — the grading tests reference them by name.

• Enum "Staged Line Status" with the values Pending, Posted, "Needs Fix", Retry and Failed.
• Table "Staged Ledger Line": primary key "Line Code" (Code[20]), plus "Item Code" (Code[20]), Quantity (Decimal), Status (the enum above) and "Failure Reason" (Text[250]).
• Codeunit "Ledger Gateway" with procedure Post(StagedLedgerLine: Record "Staged Ledger Line") — a sealed stand-in for the legacy service. It performs no database writes; returning without an error means the line was posted. It fails like the real one: an "Item Code" starting with DOWN simulates an outage (an error whose message text begins with GATEWAY-DOWN:); one starting with GLITCH simulates an unexpected internal crash; one starting with MIMIC simulates a service-side rejection raised as a plain error whose wording happens to contain must have a value — it imitates a field-test message without being one; one starting with VERBOSE simulates a crash whose diagnostic is longer than "Failure Reason" can hold; and otherwise it validates the line — an empty "Item Code" or a zero Quantity fails with a field-test (TestField) error. Every diagnostic the gateway invents carries a fresh incident code, stamped into the message text at call time.