Files
wyndham-ARR/.project-docs/50-evidence/topics/2026-08-03-channel-bi-freshness.md
2026-08-03 16:08:14 +08:00

1.9 KiB

Channel BI freshness after August publication

Question

The operator reported that the monthly report had updated but Channel BI still showed 8.1.

Read-only evidence

  • reporting.monthly_runs has active August V02 with as_of_date=2026-08-02, 268 rows and 6 channels. August V01 at 2026-08-01 is superseded.
  • A fresh PostgresAnalyticsRepository.read_dashboard("2026-08") repeatable-read query returns max_arrival_date=2026-08-02, min_arrival_date=2026-08-01, updated_at=2026-08-03T14:21:29+08:00 and 268 retained rows. The source projection and database publication are therefore current.
  • arr_web/static/app.js calls loadAnalytics() during initial boot, on the first BI tab entry only when state.analytics is empty, and when the month selector changes. The existing four-second timer belongs to the monthly-history list and does not refresh BI analytics.

Conclusion

This is a frontend freshness bug, not an operator mistake and not a current monthly-worker/database publication failure. A BI page opened before V02 was published can keep rendering the cached 8.1 payload until the page reloads or the month selector changes. No code, runtime, report or business data was changed during diagnosis.

Repair implemented

arr_web/static/app.js and arr_web/static/h5.js now check the selected month's lightweight updated_at metadata every five seconds while visible. They reload the full analytics payload only when the selected month changes or its updated_at changes, pause while hidden, check immediately when visible again and preserve the last good snapshot on transient background failures. The desktop monthly-history timer remains four seconds and is independent from BI.

Focused verification passes: BI visual/static contract 5/5, Web contract 19/19, both JavaScript syntax checks and git diff --check. No API, report or business data behavior changed.