Company report source label and live runtime

Read-only evidence

booking.current_source_batch points to accepted Booking Excel batch 7 with 72 source rows. No reviewing extraction draft is open.
The latest August 01-10 jobs contain source: null, and all five company results report COMPANY_REPORT_PUBLISH_FAILED at stage publish. The reports reached publish after building company row counts 54/18/7/1/15, so the subset was parsed and reached report generation.
Batch 7 was activated before the failed jobs were created. The company-report repository reads booking.v_current_room_items, so the active source boundary is the new batch; the missing source field is trace metadata, not proof of an old-data report.
The live Web PID on port 8766 started on 2026-08-02 12:20. The current arr_web/company_jobs.py and company_reports/publishing.py were modified on 2026-08-03, after that process started. Refreshing the page cannot load the new Python code; a controlled Web restart is needed for future jobs to persist source metadata and use the current duplicate-publication handling.

Conclusion

The message does not by itself mean the report used the previous Excel. In this case the new subset is active, but the currently running Web process is stale and saved new job records without the source summary. The same stale process also rejected the new 01-10 publication attempts at the publish boundary. Existing null metadata should not be backfilled by guessing; future jobs should be checked after a controlled restart and one authorized rerun.

Post-restart retry recheck

The operator reported restarting port 8766 and reran 2026-08/01-10. The newest job 253ce23dc7544d34a6e0fb9405ac4d9a was created at 2026-08-03T07:09:33Z and finished at 07:10:28Z; it again built the five row sets 54/18/7/1/15, then failed all five companies at publish with COMPANY_REPORT_PUBLISH_FAILED. Earlier job c5358fa293184f5f9bad85178afada22 succeeded at 06:25Z with the same row counts and complete archive/result pairs.

The effective listener is still PID 11176, started 2026-08-02 12:20:56 +0800, under detached Screen arr2-web-8766. The current company_reports/publishing.py was modified at 2026-08-03 11:19:58 +0800, after that process started. The deterministic reservation and complete-pair reuse fix is therefore present in source but not loaded by the process that handled the retry. A browser refresh only reloads static assets; it cannot reload imported Python modules or replace the port listener.

The operator-facing publish copy was shortened to an actionable message: 数据已处理，但正式 Excel 保存失败。请重启报表服务后再生成。

No service restart, source activation, job backfill or report regeneration was performed by this recheck.

Latest retry recheck

The operator's next 2026-08/01-10 attempt created job 087dceca79e64bebb719ad06e7813465 at 2026-08-03T07:28:52Z and finished at 07:29:49Z. It again built row counts 54/18/7/1/15; every company failed only with COMPANY_REPORT_PUBLISH_FAILED at publish. The result is therefore the same stale-runtime retry signature, not a new source-validation, Booking-match or workbook-build failure.

At 2026-08-03 15:37 +0800, *:8766 was still owned by PID 11176 under Screen 11172.arr2-web-8766, both started 2026-08-02 12:20:56 +0800. The current publisher and company-job modules were modified after that start time. The existing launcher --check passes, so configuration is ready; the running listener itself has simply not been replaced.

The earlier successful c5358fa... job's five versioned XLSX files match both their result JSON artifact hashes and their current-download copies. The failed retries contain no artifact descriptors and did not overwrite the successful files. Current source's six publisher regressions pass. The safe repair is to stop the exact old listener, verify port 8766 is free, start one new Screen session through the launcher, verify its PID/start time and authenticated company readiness, then run one explicitly authorized retry. No archive deletion, metadata backfill or file repair is needed.

This check remained read-only: no service restart, report generation, artifact mutation, source activation or database write was performed.

Controlled restart and live acceptance

After explicit operator confirmation, the exact stale listener PID 11176 was stopped with SIGINT. Port 8766 was verified free, then one detached arr2-web-8766 session was started through the existing launcher. The new listener was PID 54127, started 2026-08-03 15:46:29 +0800, after the current publisher and company-job module modifications. /healthz returned 200 and authenticated /api/health reported database, processing, monthly, download, company-report and company-source readiness all true.

Exactly one new 2026-08/01-10 task was submitted: 05cc547d62854df281b0c9cac60e6f6d. It finished at 2026-08-03T07:48:37Z with succeeded; all five companies succeeded with row counts 54/18/7/1/15. The job now records non-null active Booking batch-7 source metadata, confirming the new Python process loaded the source-traceability code.

The five version numbers and artifact descriptors exactly match the earlier successful job c5358fa.... Every archive XLSX, current-download XLSX and result JSON hash matches its registered artifact identity; all five authenticated HTTP download routes returned 200 and matched those hashes. Archive mtimes remained at the original 14:24–14:25 publication times, proving the retry reused the existing publication pair without overwriting it.

The temporary authenticated session was logged out and its temporary files removed. No Booking source activation, Finance fact change, artifact deletion or repair occurred. The stale-listener incident is resolved; detached-session reboot supervision remains a separate deployment gap.

5.9 KiB Raw Blame History Unescape Escape