fix: refresh public dashboard and BI telemetry
This commit is contained in:
Wyndham ARR
@@ -27,6 +27,24 @@ archive/result pair remains authoritative even if a retry rebuilds different XLS
|
||||
queued downstream message explicitly says Finance database commit is complete while the outbox waits for its
|
||||
consumer. Persisted `local-...` delivery keys and existing trace fields remain unchanged. Trace/Web tests (27) plus
|
||||
Python/JavaScript syntax and diff checks pass; no live task or business data was mutated.
|
||||
- Performed a read-only live diagnosis after a user reported that Daily Report uploaded but monthly did not update.
|
||||
Daily run 39 is accepted and Finance version 14 is active with 111 retained rows for 2026-08-01; its
|
||||
`arr.daily_version_committed` outbox event was initially pending with zero attempts. The dedicated worker was then
|
||||
started in detached Screen, consumed the backlog through event 20, and published active August V01 (`更新至
|
||||
2026-08-01`, 111 rows); July V05 (`更新至 2026-07-27`, 987 rows) also became active while older July V04 was
|
||||
superseded. The registered XLSX/result pair exists and the Web health endpoint remains ready. The worker is running
|
||||
for this session, but reboot-persistent supervision is still open; no re-upload or source-code change was made.
|
||||
- Performed a second read-only BI freshness diagnosis after August publication advanced. Active August V02 is now
|
||||
`更新至 2026-08-02` with 268 rows, and a fresh repeatable-read analytics query returns the same watermark and
|
||||
`updated_at=2026-08-03 14:21:29 +08`. An already-open BI page can still show 8.1 because `app.js` loads analytics
|
||||
only at boot, first BI entry or month change; the monthly page's four-second poll does not refresh BI. This is a
|
||||
frontend freshness bug, not a monthly worker/database publication failure. No code or business data changed.
|
||||
- Implemented BI freshness detection for desktop and public H5. While visible, each surface checks its lightweight
|
||||
month metadata endpoint every five seconds and reloads full analytics only when the selected month's `updated_at`
|
||||
changes or the selected month changes. Polling pauses while hidden, resumes with an immediate check, preserves the
|
||||
last good snapshot during transient failures, and keeps the existing four-second monthly-history polling separate.
|
||||
Static BI/Web tests pass 5/5 and 19/19; both JavaScript syntax checks and `git diff --check` pass. No API, report or
|
||||
business data behavior changed.
|
||||
- Fixed company-report duplicate publication. A retry now validates the existing archive/result pair against the
|
||||
deterministic reservation and builder `semantic_sha256`, verifies the archive hash against the result JSON, and
|
||||
reuses the first successful artifact metadata instead of comparing the new XLSX binary SHA. Partial, corrupt or
|
||||
@@ -42,6 +60,49 @@ archive/result pair remains authoritative even if a retry rebuilds different XLS
|
||||
auto-generate a report. Historical jobs without source metadata remain readable and show that the source was not
|
||||
recorded. Full discovery passes 360 tests with 10 optional skips; no live upload, activation, report generation or
|
||||
service restart was performed because the available browser session was unauthenticated.
|
||||
- A read-only live follow-up found accepted Booking Excel batch 7 active with 72 rows and no review draft. The latest
|
||||
August `01-10` jobs contain `source: null` and all five company results fail at `publish` with
|
||||
`COMPANY_REPORT_PUBLISH_FAILED` after building row counts. The port-8766 Web process predates both source-traceability
|
||||
and current duplicate-publication handling, so a controlled Web restart followed by one authorized rerun is required;
|
||||
no restart or backfill was performed.
|
||||
- Clarified company-report source and publication status copy for operators. The job panel now says `本次任务使用的
|
||||
Excel`; missing metadata says `未记录，无法确认使用了哪份 Excel` and explains that the filename/batch were not saved.
|
||||
`COMPANY_REPORT_PUBLISH_FAILED` now says the data reached publication but the official Excel was not saved, and
|
||||
explicitly distinguishes that error from successful reuse of a complete identical version. Focused Web/company and
|
||||
publisher tests plus JavaScript syntax checks pass. Existing `source: null` jobs remain untraceable and no live
|
||||
restart, report rerun or business-data mutation was performed.
|
||||
- Removed the redundant Booking Excel provenance card from company-report job details and the provenance column from
|
||||
generation history. The upload/review current-source panel and server-side job `source` metadata remain intact for
|
||||
operation and audit. Web/company regression passes 29 tests, JavaScript syntax and runtime-reference checks pass,
|
||||
and no report or business data changed.
|
||||
- After the operator-reported 8766 restart and another `2026-08/01-10` attempt, job
|
||||
`253ce23dc7544d34a6e0fb9405ac4d9a` again built all five row sets (`54/18/7/1/15`) but failed at `publish`; the prior
|
||||
`c5358fa293184f5f9bad85178afada22` succeeded with the same counts and complete artifacts. Read-only process evidence
|
||||
still shows PID `11176` started on 2026-08-02 12:20, before the current duplicate-publication source change, so the
|
||||
effective 8766 listener was not replaced. Publish copy was simplified to direct restart-and-retry instructions; no
|
||||
report, database or output mutation was performed by this recheck.
|
||||
- The operator's latest `2026-08/01-10` retry, job `087dceca79e64bebb719ad06e7813465`, finished at 15:29 +08 with the
|
||||
same five row counts and the same publish-only failures. At 15:37 +08, TCP 8766 was still owned by PID 11176 under
|
||||
the 2026-08-02 Screen session; the launcher preflight is ready, but the listener still predates the current publisher
|
||||
and job-source modules. The earlier successful five archive/result pairs and current downloads all remain
|
||||
SHA-256-consistent, and six focused publisher tests pass. No restart, rerun, file repair or business-data write was
|
||||
performed; exact listener replacement remains the required operational fix.
|
||||
- With explicit operator confirmation, the exact stale PID 11176 was stopped and replaced by PID 54127 at 15:46:29
|
||||
+08 through the existing launcher. One authorized job `05cc547d62854df281b0c9cac60e6f6d` then succeeded at 15:48:37
|
||||
+08 for all five companies with row counts `54/18/7/1/15`; the new job recorded active Booking batch 7 source
|
||||
metadata, reused the same version numbers/artifact descriptors as `c5358fa...`, and all five authenticated HTTP
|
||||
downloads returned 200 with matching archive/current/result hashes. The prior files were not overwritten, the
|
||||
temporary session was logged out, and no Booking/Finance source or fact mutation occurred.
|
||||
- Confirmed the source contracts for repeated Booking/report workflows: byte-identical activated Excel uploads reuse the
|
||||
activated source; same rows with different XLSX bytes create a new reviewable source; unchanged report snapshots
|
||||
reuse their complete publication pair; changed Finance or Booking version pins create a new report version; and an
|
||||
activated subset changes Booking detail coverage without deleting the Finance fact rows. Focused source/publisher/
|
||||
integration checks pass 14 tests with two optional ArtifactTool skips. The controlled 8766 replacement and one live
|
||||
5/5 rerun now pass; reboot-persistent supervision remains a separate deployment gap.
|
||||
- Confirmed a separate operator-visibility gap: the publisher reuses the archive/result pair internally, but neither
|
||||
`PublicationOutcome`, `CompanyRunResult` nor the public company-job projection exposes a reuse disposition or prior file
|
||||
identity. A successful retry therefore looks like a normal new successful job with a download link; no code change was
|
||||
made in this read-only check.
|
||||
|
||||
## Completed On 2026-08-02
|
||||
|
||||
@@ -287,8 +348,9 @@ archive/result pair remains authoritative even if a retry rebuilds different XLS
|
||||
07-20=100, 07-21=119, 07-22=88 and 07-23=109; the user's total was right but the 07-20/07-22 labels were reversed.
|
||||
- No database repair was performed during diagnosis. The fixture should be retired from the current projection without
|
||||
deleting immutable history, followed by a clean July republication and live API verification.
|
||||
- An already-open Channel BI view does not refresh after upload or subsequent tab entry, so it can remain at the old
|
||||
308 value even though the API is 417. This frontend freshness gap is separate from the one-row fixture contamination.
|
||||
- Channel BI now checks the selected month's `updated_at` every five seconds while visible, so an already-open view
|
||||
reloads its aggregate data after a new Finance version is published. The historical 308/417 observation above is
|
||||
retained as evidence of the earlier stale-view behavior, separate from the one-row fixture contamination.
|
||||
- The BI `公司数` card actually counts worksheet channels; LianTai GROUP/FIT are separate, so six channel keys can still
|
||||
correspond to five top-level companies.
|
||||
|
||||
@@ -372,9 +434,9 @@ archive/result pair remains authoritative even if a retry rebuilds different XLS
|
||||
- The prior 8766 outage and credential gate are resolved. The current Web process is a detached local Screen session,
|
||||
not a reboot-persistent service; `/Users/chillishark/.local/bin/arr2-web-8766 --check` validates its private route and
|
||||
Keychain inputs without printing them before a controlled restart.
|
||||
- Live authentication/readiness is accepted, but no business mutation was authorized for this activation. One no-PII
|
||||
upload should still confirm migration-013 filename provenance after restart, and one controlled company-report job
|
||||
should confirm processor 1.2.0 produces all five downloads.
|
||||
- Live authentication/readiness and one controlled 5/5 company-report job with all five downloads are accepted. One
|
||||
no-PII XML upload should still confirm migration-013 filename provenance after restart; the Web/worker sessions remain
|
||||
detached and are not reboot-persistent.
|
||||
- The latest operator-selected Web credentials were rotated on 2026-07-31, but the password still matches the username.
|
||||
Rotate it again to a distinct high-entropy value in Keychain, followed by one controlled Web restart.
|
||||
- The workstation runs Web and worker as separate processes. The checked-in Compose image intentionally does not claim
|
||||
|
||||
@@ -4,6 +4,21 @@
|
||||
|
||||
| Date | Task | Outcome | Docs Updated |
|
||||
|---|---|---|---|
|
||||
| 2026-08-03 | Execute controlled fix and live-accept 2026-08 `01-10` company report | With explicit confirmation, stopped only the stale PID 11176 and started new listener PID 54127 through the existing Keychain-backed launcher. One authorized job `05cc547d…` succeeded 5/5 with row counts `54/18/7/1/15`, captured active Booking batch-7 source metadata, reused the existing version/artifact identities, and passed five HTTP download/hash checks. Logout and temporary-file cleanup completed; no Booking/Finance source or fact mutation occurred | Current state, runtime evidence/index, stale item, commitments, scoped planning record |
|
||||
| 2026-08-03 | Diagnose the latest 2026-08 `01-10` official-Excel save failure | Read-only evidence confirms newest job `087dceca...` built all five companies (`54/18/7/1/15`) and failed only at publish. Port 8766 is still PID 11176 from 2026-08-02, older than the semantic-reuse publisher fix; the earlier successful five-file archive/result/current set remains hash-consistent and intact. The launcher preflight is ready and six publisher tests pass. Repair is an exact controlled listener replacement followed by one authorized rerun; no restart, report write or business-data mutation was performed | Current state, runtime evidence/index, stale item, scoped planning record |
|
||||
| 2026-08-03 | Check whether company-report retries show reused-file identity | Confirmed the publisher can reuse an existing archive/result pair, but the outcome, job API and frontend expose only success/version/download; users cannot see that the file was reused or which prior artifact supplied it. No code or business-data change was made | Current state, retry-semantics evidence/index |
|
||||
| 2026-08-03 | Confirm repeated Booking and company-report rerun semantics | Verified by source inspection and focused tests: byte-identical activated Excel reuses the source; same rows with different XLSX bytes require a new review/activation; unchanged report snapshots reuse complete publication pairs; a subset source can be activated and rerun, leaving Finance rows present while missing Booking room details remain blank. Live acceptance remains pending the stale 8766 process replacement | Current state, retry-semantics evidence/index, stale item |
|
||||
| 2026-08-03 | Recheck 2026-08 company-report publication after reported 8766 restart | The newest `01-10` job again built all five row sets (54/18/7/1/15) but failed at `publish`; a read-only process check shows the effective listener is still PID 11176 from 2026-08-02, before the current publisher fix. Simplified the confusing duplicate-reuse error copy to direct restart-and-retry instructions; 29 Web/company tests and JavaScript checks pass, with no report or business-data write | Current state, runtime/status-copy evidence, stale item, scoped planning record |
|
||||
| 2026-08-03 | Remove redundant company-report Excel provenance module | Removed the source card from job details and the source column from generation history; retained the upload/review current-source panel and server-side source metadata. The history table and empty state now use seven columns. Web/company tests (29), JavaScript syntax checks and runtime-reference scan pass; no report or business-data write occurred | Current state, status-copy evidence/index, scoped planning record |
|
||||
| 2026-08-03 | Clarify company-report source and publish-failure copy | The job detail/history now identifies the Excel as `本次任务使用的 Excel` / `任务使用的 Excel`; missing source metadata says the Excel cannot be confirmed and explains why. Publish failures now explain that data reached publication but the official Excel was not saved, and are not presented as a normal duplicate skip; a complete identical publication remains a success reuse. Focused Web/company/publisher tests and JavaScript syntax checks pass; no live report or business-data write occurred | Current state, status-copy evidence/index, scoped planning record |
|
||||
| 2026-08-03 | Add five-second Channel BI freshness detection | Desktop and public H5 now poll lightweight month metadata every five seconds while visible, compare the selected month's `updated_at`, and reload full analytics only after a version change. Hidden tabs pause polling, visible tabs check immediately, and transient background errors retain the last good snapshot. BI visual tests pass 5/5, Web tests pass 19/19, both JavaScript syntax checks and diff checks pass; no report or business data changed | Current state/history, Channel BI freshness evidence/index, stale item |
|
||||
| 2026-08-03 | Diagnose BI remaining at 8.1 after August monthly publication | Read-only database and analytics checks confirm active August V02 is `更新至 2026-08-02` with 268 rows, while a fresh BI query returns the same watermark. The existing page only loads analytics at boot, first BI entry or month change, so an already-open view can remain at 8.1. Confirmed a frontend freshness bug; no code or business data changed | Current state/history, BI freshness evidence/index, existing stale lifecycle item |
|
||||
| 2026-08-03 | Recover automatic monthly publication | User-authorized detached `monthly_reports.worker` start consumed pending outbox events 15–20 in order. July V05 (`as_of_date=2026-07-27`, 987 rows) and active August V01 (`as_of_date=2026-08-01`, 111 rows) are registered with workbook/result artifacts; all six checked daily-commit events are `published`, the XLSX passes ZIP integrity, and Web health remains ready. Re-upload and source-code changes were not needed; reboot-persistent supervision remains open | Current state, daily-to-monthly evidence topic/index, stale supervision item, scoped planning record |
|
||||
| 2026-08-03 | Review monthly worker logging and monitoring | Confirmed Screen/stdout and Web/stderr are not durable monitoring, `/healthz` excludes worker liveness, and the existing outbox/task trace lacks heartbeat and monthly-specific end-to-end wording. Prepared a privacy-minimized structured-log, heartbeat, status and supervisor/alert recommendation; no code or runtime change was made | Monthly worker observability evidence/index, stale item, scoped planning record |
|
||||
| 2026-08-03 | Diagnose company-report source label after subset Excel activation | Read-only checks found accepted current Booking Excel batch 6 with 73 rows and no open draft; latest August jobs were created after activation but saved `source: null` because the live Web process predates the source-traceability code. The label is a metadata/runtime mismatch, not proof that the report used the old source; no restart or backfill was performed | Current state/evidence topic/index, stale item, scoped planning record |
|
||||
| 2026-08-03 | Diagnose subset-source 2026-08 `01-10` publication failures | Batch 7 is accepted/current with 72 rows and no review draft. The latest job built all five company row sets but failed all at `publish` with `COMPANY_REPORT_PUBLISH_FAILED`; the live 8766 process predates both source metadata and current duplicate-publication fixes. No restart or rerun was performed | Current state/evidence topic/index, stale item, scoped planning record |
|
||||
| 2026-08-03 | Evaluate Daily task trace for company-report publication failure | Confirmed the supplied Daily trace only covers successful Finance commit and outbox publication; it lacks company-report job linkage and publish-stage detail, shows unknown execution metadata and prints an unmasked full source hash. Recommended separate trace scopes, runtime identity and hash masking; no code/runtime change was made | Daily/company trace evidence/index, stale item, scoped planning record |
|
||||
| 2026-08-03 | Diagnose Daily Report uploaded but monthly report not updated | Read-only database/runtime inspection confirms Daily run 39 committed successfully as Finance version 14 with 111 retained rows for 2026-08-01, but outbox event 20 remains pending with zero attempts because no independent `monthly_reports.worker` process is running. Monthly history still ends at July V04; no August version exists. No restart, rerun, upload or database write was performed | Current state, daily-to-monthly diagnosis evidence/index, scoped planning record |
|
||||
| 2026-08-03 | Make the mobile H5 dashboard publicly readable | Added public H5 shell/assets and purpose-built sanitized aggregate month/analytics endpoints; desktop, generic APIs, legacy H5 APIs, detailed health, jobs/traces, downloads and writes remain protected. Anonymous H5 loading plus authenticated compatibility is covered by 71 Web tests and syntax checks; no live restart or deployment occurred | Current state/history, architecture, business rules, ADR-005, H5 public-access evidence/index, scoped planning record |
|
||||
| 2026-08-03 | Clarify ARR trace semantics for internet deployment | Added additive execution-scope, processor-mode and remote-dispatch fields; replaced misleading “本地处理” copy and clarified that a pending downstream event follows a completed Finance commit. Existing delivery IDs/trace fields remain compatible; 27 trace/Web tests plus Python/JavaScript syntax and diff checks pass, with no live mutation | Current state/history, ARR trace-semantics evidence/index, scoped planning record |
|
||||
| 2026-08-03 | Add Booking Excel to company-report traceability | New company-report jobs store the server-captured active source summary; the page shows the current source, job detail/history show the source Excel, and identical active uploads become an informational refresh instead of a generic extraction error. Old jobs remain compatible without source metadata. Focused Web/company tests and the 360-test suite pass with 10 optional skips; no live mutation or restart was performed | Current state, source-to-report traceability evidence/index, scoped planning record |
|
||||
|
||||
@@ -4,6 +4,15 @@ Use this index for searchable, traceable evidence records.
|
||||
|
||||
| Date | Topic | Status | Source | Detail |
|
||||
|---|---|---|---|---|
|
||||
| 2026-08-03 | Booking source and company-report retry semantics | Source contract confirmed; reuse visibility gap identified; live acceptance pending restart | [Evidence topic](topics/2026-08-03-company-report-retry-semantics.md) | Byte-identical XLSX uploads reuse the activated source; same rows with different file bytes are new drafts. Same report snapshots reuse complete publication pairs, changed Finance/Booking pins create new versions, and an activated subset changes Booking detail coverage while retaining Finance rows. The current API/UI do not expose whether a retry reused an existing artifact. |
|
||||
| 2026-08-03 | Company-report retry after reported 8766 restart | Resolved by controlled listener replacement and live 5/5 rerun | [Evidence topic](topics/2026-08-03-company-source-runtime-diagnosis.md) | PID 11176 was replaced by PID 54127. Job `05cc547d…` succeeded all five August `01-10` companies, reused the prior version/artifact identities, and all five authenticated downloads returned hash-matching 200 responses. No Booking/Finance source or fact changed. |
|
||||
| 2026-08-03 | Remove redundant company-report Excel provenance module | Implemented; Web/company checks pass | [Evidence topic](topics/2026-08-03-company-report-status-copy-fix.md) | The job-detail source card and history source column are removed because reports consume the Booking database snapshot; upload/review source UI and server-side provenance remain available. |
|
||||
| 2026-08-03 | Company-report source and publish-failure copy | Simplified; source display superseded by module removal | [Evidence topic](topics/2026-08-03-company-report-status-copy-fix.md) | The end-user source display was later removed. Publish failures now say the data was processed, the official Excel save failed, and the report service should be restarted before generating again; internal duplicate-reuse rules are not shown. |
|
||||
| 2026-08-03 | Channel BI freshness after August publication | Diagnosed and repaired; focused checks pass | [Evidence topic](topics/2026-08-03-channel-bi-freshness.md) | Active August V02 is `更新至 2026-08-02` with 268 rows, and a fresh analytics snapshot returns the same watermark. Desktop and public H5 now check lightweight month metadata every five seconds and reload only after selected-month `updated_at` changes; hidden views pause and transient failures preserve the last good snapshot. |
|
||||
| 2026-08-03 | Daily commit waiting for monthly worker | Recovered; persistent supervision pending | [Evidence topic](topics/2026-08-03-daily-monthly-worker-pending.md) | User-authorized detached worker recovery consumed events 15–20. July V05 is active at 987 rows and August V01 is active at 111 rows with registered workbook/result artifacts; all six checked daily-commit events are published, XLSX integrity passes, Web health is ready, and only reboot-persistent worker supervision remains open. |
|
||||
| 2026-08-03 | Monthly worker logging and observability gap | Recommendation pending implementation | [Evidence topic](topics/2026-08-03-monthly-worker-observability.md) | Worker output is sparse Screen stdout, Web request logs go to stderr, and Web readiness excludes worker liveness. Durable outbox/task-trace facts exist but lack heartbeat/process status and monthly-specific wording. Recommended next step is structured retained logs plus heartbeat, status projection and supervisor alerting; no code or runtime change was made. |
|
||||
| 2026-08-03 | Company report source label and live runtime | New runtime accepted; historical null-source jobs remain unchanged | [Evidence topic](topics/2026-08-03-company-source-runtime-diagnosis.md) | New job `05cc547d…` records active Booking batch 7 metadata and succeeds 5/5 after PID 54127 replacement. Older jobs with `source: null` remain historical records and were not guessed or backfilled. |
|
||||
| 2026-08-03 | Daily trace does not explain company-report publication failure | Logging assessment pending implementation | [Evidence topic](topics/2026-08-03-daily-trace-does-not-explain-company-publish.md) | The supplied Daily trace proves Finance commit and outbox publication but has no company-report job linkage or publish-stage detail; it also shows unknown execution metadata and an unmasked full source hash. Recommend separate Daily/monthly/company traces, runtime identity and hash masking; no code/runtime change was made. |
|
||||
| 2026-08-03 | Public mobile H5 dashboard boundary | Implemented; deployment/restart pending | [Evidence topic](topics/2026-08-03-public-h5-dashboard.md) | Anonymous H5 page/assets and purpose-built `/api/public/h5/*` aggregate routes are allowed. The projection omits `source_monthly_sha256`; desktop, generic/legacy APIs, detailed health, jobs/traces, downloads and writes remain protected. `test_arr_web*` discovery passes 71 tests; no live service or business data was changed. |
|
||||
| 2026-08-03 | ARR job trace semantics for internet deployment | Implemented; live deployment acceptance pending | [Evidence topic](topics/2026-08-03-arr-job-trace-semantics.md) | Trace projection adds `execution_scope`, `processor_mode` and `remote_dispatch`; `artifact_callback` is identified as ARR fixed-processor runtime execution and legacy `direct_mcp` as remote Agent/MCP delivery. “本地处理” copy is removed, pending downstream explicitly follows Finance commit, and persisted `local-...` delivery identities are retained. Focused trace/Web tests pass; no live task or business write occurred. |
|
||||
| 2026-08-03 | Booking Excel to company-report traceability | Implemented; authenticated browser acceptance pending | [Evidence topic](topics/2026-08-03-company-source-report-traceability.md) | New report jobs persist a safe source summary captured at submission; current source, job detail and history expose the filename/batch context. Identical active uploads refresh context without re-extraction or automatic generation. Full discovery passes 360 tests with 10 optional skips; no live mutation or restart occurred. |
|
||||
|
||||
@@ -0,0 +1,32 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,47 @@
|
||||
# Booking source and company-report retry semantics
|
||||
|
||||
## Metadata
|
||||
|
||||
- Date: 2026-08-03
|
||||
- Status: Confirmed in source; live acceptance remains pending the controlled port-8766 restart
|
||||
- Scope: Repeated identical Booking Excel uploads, company-report reruns and subset-source reruns
|
||||
- Confidence: Fact for the current source contracts and tests; live runtime is still the stale PID 11176
|
||||
- Source: `booking_ingestion/excel_review_postgres.py`, `company_reports/repository.py`, `company_reports/core.py`,
|
||||
`company_reports/publishing.py` and focused unittest suites
|
||||
- Last verified: 2026-08-03
|
||||
|
||||
## Confirmed behavior
|
||||
|
||||
1. A byte-identical `.xlsx` is identified by its file SHA-256. In the real PostgreSQL review repository, if that
|
||||
artifact has already been activated, a repeated upload returns `BOOKING_EXCEL_SOURCE_ALREADY_ACTIVATED` and does not
|
||||
create another extraction batch. If the workbook has the same Booking rows but different XLSX bytes, it is a new
|
||||
upload and must go through review/activation again; row-level semantic deduplication is not used at upload time.
|
||||
2. A company report can be generated again after a successful publication. The report reservation identity includes the
|
||||
month/period cutoff, Finance daily-version pins, Booking parse-version pins and processor/rule/schema identity. An
|
||||
unchanged identity reuses the complete archive/result pair; a changed identity creates a new version and retains the
|
||||
earlier files. Partial, corrupt or semantically conflicting publication state fails closed.
|
||||
3. A subset workbook is not a duplicate of its previous superset. After review is complete and the subset is activated,
|
||||
`booking.current_source_batch` points to it and a report rerun reads that active Booking snapshot. Finance facts remain
|
||||
the report row boundary; Group Codes missing from the subset produce rows with blank Booking Room details rather than
|
||||
silently deleting the Finance rows. Upload alone does not switch the active source, and an open review draft blocks
|
||||
company-report generation until it is activated or discarded.
|
||||
|
||||
## Runtime boundary
|
||||
|
||||
The current 8766 listener is still PID `11176`, started on 2026-08-02 before the duplicate-publication fix. The source
|
||||
contracts above are therefore the intended behavior after a controlled restart; the failed August retry is not valid live
|
||||
acceptance of the fixed publisher.
|
||||
|
||||
## User-visible reuse status
|
||||
|
||||
The current publication outcome contains the artifact and result metadata but no `reused`/`publication_disposition`
|
||||
field. `CompanyRunResult` and the public company-job projection likewise expose success, version number and download URL,
|
||||
not whether the publisher reused an existing archive/result pair. Consequently, after a successful retry the operator sees
|
||||
`成功` and a normal download link; the downloaded bytes can be the original archived file, but the page does not identify
|
||||
which prior file/version was reused.
|
||||
|
||||
## Verification
|
||||
|
||||
- Focused source-upload/publisher/integration unittest: 14 tests passed, 2 optional ArtifactTool integration tests
|
||||
skipped because the local dependency is unavailable.
|
||||
- No source activation, report rerun, output repair or business-data mutation was performed.
|
||||
@@ -0,0 +1,51 @@
|
||||
# Company-report source and publish-failure copy
|
||||
|
||||
## Metadata
|
||||
|
||||
- Date: 2026-08-03
|
||||
- Status: Implemented; source provenance module subsequently removed from the end-user result/history surface, and the
|
||||
publish-failure copy was simplified after live operator feedback
|
||||
- Scope: Desktop company-channel job detail/history copy, source-module removal and company-result error explanation
|
||||
- Confidence: Fact for source/error contracts and focused verification; no live report state was changed
|
||||
- Source: `arr_web/static/app.js`, `arr_web/static/index.html`, `arr_web/static/i18n.js`, publisher tests and company job evidence
|
||||
- Last verified: 2026-08-03
|
||||
- Stale trigger: changes to company job source metadata, publication idempotency or localized status copy
|
||||
|
||||
## Problem
|
||||
|
||||
The page displayed `来源 Excel（提交时）` with `历史任务未记录来源`, which described an internal capture detail but did
|
||||
not tell an operator whether the source was missing, old or actually used. It also displayed only
|
||||
`正式表格发布失败`, which did not explain whether this was a normal duplicate-version reuse.
|
||||
|
||||
## Implemented behavior
|
||||
|
||||
- The final end-user surface no longer renders the job-detail source card or history source column. The report page is
|
||||
explicitly database-snapshot oriented; the upload/review current-source panel is retained where the operator actually
|
||||
manages the Excel input.
|
||||
- Server-side jobs still retain the safe source summary for audit and troubleshooting. Removing the UI module does not
|
||||
backfill or delete old source metadata.
|
||||
- `COMPANY_REPORT_PUBLISH_FAILED` now appears as `正式 Excel 保存失败`. The job summary and company row use the direct
|
||||
action copy `数据已处理，但正式 Excel 保存失败。请重启报表服务后再生成。`; internal duplicate-reuse rules are
|
||||
no longer shown in the operator-facing error.
|
||||
- The wording is available in Chinese, English and Thai, and the added detail is escaped before it is inserted into the
|
||||
result table.
|
||||
|
||||
## Verification
|
||||
|
||||
- Focused unittest: Web/company regression passes 29 tests.
|
||||
- `node --check arr_web/static/app.js` and `node --check arr_web/static/i18n.js` pass.
|
||||
- Runtime static scan confirms no source-card/history-column reference remains; the upload/review source references
|
||||
remain intentionally.
|
||||
- `git diff --check` passes.
|
||||
- The project virtualenv has no `pytest` module; the repository's unittest runner was used instead.
|
||||
- A live read after the operator-reported retry found job `253ce23d…` still failed for all five companies at `publish`
|
||||
with row counts `54/18/7/1/15`. The listener remains PID `11176`, started `2026-08-02 12:20`, while the current
|
||||
publisher source was modified on `2026-08-03 11:19`; the reported restart therefore did not replace the effective
|
||||
port-8766 process.
|
||||
- No Web restart, source activation, report rerun, output backfill, database write or business-data mutation occurred.
|
||||
|
||||
## Semantics retained
|
||||
|
||||
The publisher remains idempotent for a complete semantically identical archive/result pair. Incomplete, corrupt or
|
||||
semantically conflicting publication state still fails closed; the UI reports the safe action without translating every
|
||||
publish failure into a duplicate explanation.
|
||||
@@ -21,13 +21,16 @@ without exposing workbook rows, guest data or full artifact hashes.
|
||||
source identity.
|
||||
- New job records expose only source batch id/type, safe filename, activation time, disposition and summary counts.
|
||||
- The company page shows the current active workbook and summary counts.
|
||||
- Job detail and history show the source Excel captured at submission; old job files without this field render
|
||||
`历史任务未记录来源`/an equivalent localized label.
|
||||
- The server still captures the source Excel summary at submission, but the end-user job detail/history no longer
|
||||
renders that provenance. The upload/review panel remains the place where the active Excel source is managed.
|
||||
- Re-uploading the same active workbook clears the selected file, refreshes the current-source and report-history views,
|
||||
and shows an informational message. It does not create a second extraction or automatically generate a report.
|
||||
- Report generation remains an explicit month/period action. Upload controls stay blocked while a report job is active, so
|
||||
the submission-time source remains the trace shown for that job.
|
||||
|
||||
The later UI simplification intentionally removes only the result/history display; it does not remove the server-side
|
||||
source metadata or change the report's database-backed input behavior.
|
||||
|
||||
## Verification
|
||||
|
||||
- `./.venv/bin/python -m unittest tests.test_arr_web_company_reports tests.test_arr_web`: 28 tests passed.
|
||||
|
||||
@@ -0,0 +1,84 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,42 @@
|
||||
# Daily commit waiting for monthly worker
|
||||
|
||||
## User question
|
||||
|
||||
The operator reported that a Daily Report upload appeared complete but the monthly report did not update.
|
||||
|
||||
## Read-only checks
|
||||
|
||||
- Port 8766 returned `ready`; the active process list showed the ARR Web service but no independent
|
||||
`monthly_reports.worker` / `arr-monthly-worker` process.
|
||||
- The newest `opera_daily` processing run is run 39. It finished at 2026-08-03 10:49:01 +08 with `accepted` status and
|
||||
no failure code.
|
||||
- Finance daily version 14 is `active` for business date 2026-08-01 and contains 111 retained rows. Its retained
|
||||
`ARRIVAL` scope is 2026-08-01, so the automatic worker would derive an August 2026 monthly request.
|
||||
- Outbox event 20 (`processing-run:39:accepted`, `arr.daily_version_committed`) is still `pending`, has zero publish
|
||||
attempts and no error code, and has been available since 2026-08-03 10:49:01 +08.
|
||||
- `reporting.monthly_runs` contains only July versions. July V04 is active with `as_of_date=2026-07-27`; no August
|
||||
version is present.
|
||||
- A second read-only check found a backlog of five daily-commit events, IDs 16–20, all `pending` with zero attempts
|
||||
and no error. Events 16–19 derive the July request through 2026-07-27; event 20 derives the August request through
|
||||
2026-08-01. Recovery should let the worker consume them in order and retain its idempotent publication behavior.
|
||||
- The controlled database file, Python runtime, Node binary and artifact-tool module pass preflight checks. The focused
|
||||
monthly suite passes 27 tests with two optional skips. No worker was started and no monthly publication or database
|
||||
write was performed.
|
||||
- The monthly page polls every four seconds only while its tab is visible. That can delay page display, but it cannot
|
||||
explain the missing database row because event 20 has not been consumed.
|
||||
|
||||
## Recovery
|
||||
|
||||
- The user authorized recovery. A detached `arr2-monthly-worker` Screen session was started with the controlled
|
||||
`booking_test` configuration and the verified Node/artifact-tool paths.
|
||||
- The worker consumed outbox events 15–20 in order. Each is now `published` with one attempt and no error code.
|
||||
- July V05 is `active` at `as_of_date=2026-07-27` with 987 rows; older July V04 is `superseded`. August V01 is
|
||||
`active` at `as_of_date=2026-08-01` with 111 rows.
|
||||
- The August registered workbook/result pair exists under the controlled project output, the XLSX passes ZIP
|
||||
integrity, the result JSON reports `success`, and Web `/healthz` remains `ready`.
|
||||
|
||||
## Conclusion
|
||||
|
||||
The Daily Report was correct; the missing monthly update was caused by the absent worker process. The report is now
|
||||
updated without re-uploading the source. The remaining operational gap is reboot-persistent supervision of the
|
||||
detached worker, which is intentionally separate from this recovery and from the later logging work.
|
||||
@@ -0,0 +1,20 @@
|
||||
# Daily trace does not explain company-report publication failure
|
||||
|
||||
## Evidence
|
||||
|
||||
- The supplied `arr trace` for the Daily job ends `status=succeeded`, with Finance daily version 15 active, all
|
||||
validation/database stages successful, and `arr.daily_version_committed` marked published.
|
||||
- That trace contains no company-report job id, report month/period, per-company result, publish-stage error or artifact
|
||||
publication identity. It therefore cannot explain the separate `正式表格发布失败2026-08` message.
|
||||
- The trace reports `execution_scope=unknown`, `processor_mode=unknown` and `remote_dispatch=unknown` for an
|
||||
`artifact_callback`, despite the current trace contract having explicit values. It also prints a full source hash in
|
||||
the default CLI output.
|
||||
|
||||
## Logging assessment
|
||||
|
||||
This is a scope/observability gap, not evidence that the Daily task failed. Keep the Daily trace focused on Daily and
|
||||
the outbox boundary, add monthly report id/version/as-of results to the monthly event projection, and add a separate
|
||||
company-report trace with job id, source batch, period, per-company publish stage and safe error code/message. Include
|
||||
runtime process/build identity and mask full hashes in default output.
|
||||
|
||||
No code or runtime change was made during this assessment.
|
||||
@@ -0,0 +1,24 @@
|
||||
# Monthly worker logging and observability gap
|
||||
|
||||
## Scope
|
||||
|
||||
Review of the logging and monitoring surfaces after user-authorized recovery of the independent monthly worker.
|
||||
|
||||
## Confirmed gaps
|
||||
|
||||
- The worker emits sparse JSON outcomes only when it is not idle; it does not emit startup, heartbeat, claim, duration or
|
||||
private exception-detail records. Detached Screen is the current process owner and is not durable application logging.
|
||||
- Web request logs go through the standard handler's stderr logger with path-only request data. The checked-in local
|
||||
runtime has no service-specific rotating log file.
|
||||
- Anonymous `/healthz` checks Web database/upload readiness only. Authenticated `monthly_ready` describes Web's manual
|
||||
monthly coordinator, not the separate worker process.
|
||||
- PostgreSQL outbox status and the daily task trace are durable and privacy-minimized, but they cannot prove the worker
|
||||
is alive. The trace also uses generic downstream wording for the monthly event.
|
||||
|
||||
## Recommendation
|
||||
|
||||
Add structured worker/Web logs with bounded retention, a durable worker heartbeat/status surface, monthly-specific task
|
||||
trace states, and supervisor/alert checks for stale heartbeat, old pending events, expired leases and dead events. Keep
|
||||
database lifecycle state authoritative and keep raw business/source payloads, secrets and full hashes out of logs.
|
||||
|
||||
No code, migration, supervisor or runtime change was made during this review.
|
||||
@@ -4,8 +4,8 @@ No timed or externally delegated commitment is currently active.
|
||||
|
||||
## Open Product Work (not a promise in this task)
|
||||
|
||||
- Login credentials, port-8766 activation, authenticated history and logout are complete. One controlled no-PII upload
|
||||
filename check and one released 5/5 company-report job under processor 1.2.0 remain open product acceptance work.
|
||||
- Login credentials, port-8766 activation, authenticated history/logout and one released 5/5 company-report job under
|
||||
processor 1.2.0 are complete. One controlled no-PII XML upload filename check remains open product acceptance work.
|
||||
- The Booking extraction/review program is source-complete, migrated and transaction-tested against live PostgreSQL with
|
||||
an outer rollback. One operator-authorized real upload/edit/delete/activate flow remains open product acceptance work;
|
||||
this record is not authorization to change the current Booking source.
|
||||
|
||||
@@ -8,10 +8,13 @@
|
||||
| 2026-07-31 | Booking review audit depth | Migration 015 stores current confirmed/pending/deleted state but no reviewer, reason, explicit review event, old/new values or immutable revision history. Repository logic serializes and gates activation, but declarative DB guards are limited and same-artifact re-extraction deletes earlier unactivated edits | Confirm whether single-operator latest-state editing is sufficient. If review must be auditable, add actor/reason/event or revision tables, optimistic concurrency and DB transition guards before migration acceptance |
|
||||
| 2026-07-31 | Booking Excel current-source runtime acceptance | Current port 8766 loads the review composition with all readiness flags true; migrations 014/015 are recorded and `booking.current_source_batch` still selects Markdown batch 1. A 14:14 +08 read-only recheck found no reviewing draft; the prior draft is no longer an active task-creation blocker and did not switch the current source. The Markdown five-workbook baseline has been frozen with exact hashes | Run one Markdown-backed five-company Web job after the July period completes if a final-period snapshot is desired, then verify downloads. Keep any later complete-workbook activation operator-authorized, then compare its five overlapping Group Codes with the frozen baseline |
|
||||
| 2026-07-31 | Booking Group Code uniqueness invariant | Current views globally merge the same Group Code across worksheets. The fixture has 23 codes shared by `DY-AI-Easy-KB` and `LIANTAI-FIT`; none is used by current Finance, so current output is unaffected but real-source semantics are not confirmed | Confirm whether those rows are intentionally additive. If Group Code can vary by channel or stay segment, add explicit business dimensions to the Excel contract, schema and report join before real imports |
|
||||
| 2026-07-30 | Port-8766 business acceptance / supervision | Authenticated Web on `*:8766` now loads Booking review and all readiness flags are true; the detached Screen session is not reboot-persistent. July month-end completion is 2026-08-01 00:00 Bangkok | Run one controlled real review flow plus one company-report job/all five downloads, preferably after the period completes for a final snapshot; separately choose a managed reboot-persistent supervisor that can access the Desktop-hosted project |
|
||||
| 2026-07-30 | Port-8766 business acceptance / supervision | Authenticated Web on `*:8766` loads Booking review and all readiness flags are true. The dedicated monthly worker was recovered in a detached Screen session and drained the pending daily-commit backlog; the Screen session, like the Web session, is not reboot-persistent | Choose and install a managed reboot-persistent supervisor that can access the Desktop-hosted project, then verify worker restart/heartbeat behavior before the next controlled real review/company-report acceptance |
|
||||
| 2026-08-03 | Monthly worker logging / observability | Worker outcomes are sparse Screen stdout; Web request lines go to stderr; `/healthz` and authenticated `monthly_ready` do not represent independent worker liveness. Outbox/task-trace facts are durable but have no worker heartbeat or monthly-specific end-to-end state | Add privacy-minimized structured logs with rotation, durable worker heartbeat/status, monthly-specific trace wording and stale-queue/dead-event checks; validate retention and restart detection before treating worker monitoring as complete |
|
||||
| 2026-08-03 | Daily trace versus company-report failure visibility | The Daily `arr trace` proves Finance commit/outbox publication but cannot identify an independent company-report job or its publish-stage error; it also exposes unknown execution metadata and a full source hash | Add separate company-report trace linkage, monthly report identity fields, runtime/build identity and default hash masking; verify the operator can diagnose a publish failure without reading private job files |
|
||||
| 2026-08-03 | Company-report source trace/runtime freshness | Resolved 2026-08-03: PID 11176 was replaced by PID 54127; job `05cc547d…` captured active batch-7 source metadata, succeeded 5/5 and passed five download/hash checks. Historical `source: null` records remain intentionally unchanged | Keep historical null-source jobs as-is; do not backfill by guessing. Reboot-persistent Web/worker supervision remains a separate deployment task |
|
||||
| 2026-07-31 | Web credential strength | The requested Keychain-only rotation and controlled restart passed, but the newly selected password still satisfies only the minimum-length rule and remains identical to the username | When the operator chooses a distinct high-entropy password, update only the existing Keychain item and repeat the controlled Web restart/login/logout check |
|
||||
| 2026-07-30 | `booking_test` current Finance projection | The earlier 417-row snapshot included accepted run `mvp-v1-fixture-20260727` from `synthetic.xml`/`local_fixture`. A 2026-07-31 14:17 read-only company-report recheck found 986 current supported-company facts, so the old 416/417 remediation target is no longer a complete description of current Finance state | Re-audit current daily-version pins and source provenance before any fixture retirement; require explicit authorization for version changes, then verify the clean target and watermark |
|
||||
| 2026-07-30 | Channel BI refresh lifecycle | Analytics loads only at boot/month change/first tab entry; successful XML upload and later BI-tab entries do not reload it. The original 308-versus-417 observation is historical, and the current company projection has since advanced to 986 supported-company facts | Refresh analytics after successful upload and on visible BI-tab entry, with non-overlap/error handling and focused frontend coverage |
|
||||
| 2026-07-30 | Channel BI refresh lifecycle | Resolved 2026-08-03. Desktop and public H5 now check selected-month metadata every five seconds while visible and reload full analytics only after `updated_at` changes; hidden views pause and transient failures preserve the last good snapshot | Refresh the browser once to load the new static assets, then observe the next authorized publication as a live acceptance check |
|
||||
| 2026-07-30 | Channel BI KPI label | The card labeled `公司数` renders worksheet-level `channel_count`; LianTai GROUP/FIT are two channels, so six does not mean six companies | Decide whether to relabel it `渠道/子表数` or implement an explicit five-company aggregation |
|
||||
| 2026-07-30 | Production worker packaging | Local Web/worker separation is live, but the checked-in Compose image does not contain the workstation-only Node/artifact-tool runtime required by the XLSX builder | Package an approved builder runtime and shared output volume before adding/enabling the managed production worker service |
|
||||
|
||||
|
||||
Reference in New Issue
Block a user