2026-08-05 Daily PRICE_UNMATCHED diagnosis

Metadata

Date: 2026-08-06
Status: Latest frozen review awaits explicit employee retry after deployed technical repair
Scope: Daily job arrjob-f1cd01f5fddd458cbdafada0ec7dd14d, rejected Finance version 28
Confidence: Fact for the hash-matched local replay and checked-in reference; production rule-set binary identity remains unproven because the supplied trace omits rule_set_sha256
Source: operator-supplied ARR trace, hash-matched 0805.XML, deterministic processor 3.0.0 replay, structured failure result, fixed price-reference workbook
Last verified: 2026-08-06
Stale trigger: a successful run-67 retry, a price/rule deployment, or a fresh processing job for business date 2026-08-05

Question

Why did the deployed 2026-08-05 Opera XML daily job fail with PRICE_UNMATCHED, and do the reported 151 validation-failed rows represent separate bad source records?

Evidence

The server trace reports source size 948,683 bytes, rejected version 28 and outcomes 199 source = 46 excluded + 151 validation_failed + 2 price_unmatched, with no duplicates or retained output.
The read-only Desktop XML has the exact logged size and SHA-256. An isolated replay with checked-in processor 3.0.0 exits 2 and creates only result.json, structured-result.json and 异常清单.xlsx.
The two actionable errors are:
- reservation[2]: Lian Tai + LBLT + Opera amount 0; zero-night stay.
- reservation[64]: Lian Tai + GRP1 + Opera amount 1150; one-night stay.
Every one of the 151 validation_failed records carries BATCH_NOT_VALIDATED; 150 also carry PRICE_REFERENCE_MATCHED, and one carries the approved ZERO_PRICE_EXCEPTION. They are atomic batch fallout, not 151 independent field/date errors.
Read-only artifact-tool inspection of arr-opera-daily-ingest/references/价格对照.xlsx shows Lian Tai GRP1 mappings only at Sheet1 rows 23–28 for Opera amounts 900/1200/1300/1400/1800/2400, and Lian Tai LBLT mappings at rows 40/42/43 for 900/1400/2400. Neither exact target exists.
Both checked-in price-reference workbooks are byte-identical at SHA-256 123d1d1ea0e28ce481a63dfdbe4bd22b5e6069c585a8cbde4194376ed18fb0d6 and have not changed since commit a701de9 (2026-07-29).
The local replay rule-set SHA is c41257208324a43e711de13ec9776a5e6486db334757f152531bf8292a2018eb. The server trace exposes only processor version 3.0.0, so exact production rule-set hash comparison is not available from that trace alone.

Finding

The deterministic processor correctly failed under the current frozen rules because two exact normalized price keys are absent. Numeric formatting and trailing rate-code spaces are not the cause. The 总价 values cannot be inferred safely from neighboring mappings, and zero nights do not bypass price-key validation under the current approved rule.

Impact

The deployed v4 workflow created review cases instead of another rejected Finance version. Latest run 67 has a frozen GRP1/LBLT manifest of 200/0 and remains retryable generation_failed after two repaired infrastructure defects; it still has no Finance version or run outbox event. Run 66 separately retains 2300/0, and run 65 remains unset.
The values apply only to their own task and do not change the fixed reference table. No automatic retry or re-upload is safe because a successful final replay is the Finance/monthly commit boundary.
Keep rejected version 28 as immutable failure history. Only an explicitly authorized successful final replay may activate Finance facts and trigger monthly processing.

Open Items

Refresh/login, open latest run 67, confirm its frozen LBLT=0 and GRP1=200 values are intended, then invoke its retry once. Do not select run 66 accidentally because its frozen GRP1 value differs.
After success, verify 153 retained rows, two manual_review rows, one active Finance version and exactly one new daily-commit/monthly event.

3.9 KiB Raw Blame History Unescape Escape