Evidence Topic: First live ARR2 user-run trace

Metadata

Date: 2026-07-30
Status: Resolved by the monthly-publication implementation completed later on 2026-07-30
Scope: ARR2 loopback runtime on port 8766, controlled booking_test, OSS-backed daily processing, local monthly output
Confidence: Fact
Source: persisted Web API trace, read-only PostgreSQL queries, local artifact metadata, source inspection
Last verified: 2026-07-30
Stale trigger: Historical evidence; see 2026-07-30-monthly-publication-live-acceptance.md for current behavior

Question

Did the user's successful daily run commit to PostgreSQL, and why did the subsequent successful monthly action show no monthly result or download?

Evidence

Daily commit

Job arrjob-e6042c9cfe7d4f07aa986c5cffc4548e is processing run 27 with terminal raw status accepted.
Its one artifact delivery is committed and points to Finance daily version 4.
Daily version 4 is active, version number 1, for business date 2026-07-21.
Counts reconcile: 135 source rows = 119 retained + 16 excluded-rate-code; duplicate, validation-failed and price-unmatched counts are zero.
finance.current_daily_versions points 2026-07-21 to daily version 4.
The trace contains ARTIFACT_RESULT_COMMITTED, FINANCE_VERSION_ACTIVATED and JOB_SUCCEEDED terminal evidence.

Downstream event

The same database transaction created arr.daily_version_committed for processing run 27.
At verification time it was pending, with zero publish attempts and no published timestamp.
This is consistent with the documented absence of an automatic monthly outbox consumer.

Monthly generation and visibility

The manual monthly request generated outputs/monthly_reports/2026/07/latest.xlsx and latest.result.json at 2026-07-30 14:28:32 +08:00.
Result status is success; the workbook SHA-256 is 57160ff45d962ef348d7e9d21eafdc1f89c8b7b00d9d31eba283c2ff6bc40410.
The workbook reopens and contains LIANTAI-GROUP 26 rows, LIANTAI-FIT 25, QBD 55, DY-AI-Easy-KB 0 and FENGRUN 14: 120 data rows total. No guest values were recorded in this evidence.
The workbook contains zero formulas, matching the known formula implementation gap.
Read-only information_schema verification proved finance.report_versions is absent from booking_test.
monthly_reports.repository.PostgresReportRepository.reserve_report() creates only a deterministic in-memory generation identity; activate_report() revalidates source pins but inserts no report metadata.
arr_web.repository.MONTHLY_RUNS_SQL synthesizes a source_ready row with null report_id, filename and artifact hash. The frontend only renders a download link when an artifact hash/report ID is present.

Finding

The daily success is a real, atomic PostgreSQL commit. The monthly action also produced a real local XLSX, but its success is not persisted as a monthly report version and cannot be rediscovered or downloaded through the Web API. The frontend toast therefore overstates the end-to-end outcome: it confirms local file generation, not published report visibility.

Impact

Daily ingestion does not need repair for this run.
A monthly publication task must define and implement a database-compatible metadata/read model (or an equally durable controlled artifact index), then align list/download APIs and the success receipt with that persisted state.
Automatic dispatch remains separate: the accepted outbox event currently has no consumer.
The required TOTAL PRICE formula remains a separate workbook-generation defect.

Open Items

All three items were resolved later on 2026-07-30 by migration 012, the dedicated worker, persisted list/download identity and formula validation. This topic remains the before-state diagnosis.

3.7 KiB Raw Blame History