shiyuyun/wyndham-ARR
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
wyndham-ARR/.project-docs/50-evidence/topics/2026-08-04-deployed-monthly-download-diagnosis.md
Wyndham ARR a2b86cdf10 feat: move report artifacts to OSS storage
2026-08-04 12:37:26 +08:00

3.7 KiB
Raw Permalink Blame History

Deployed monthly-report download diagnosis

Metadata

  • Date: 2026-08-04
  • Status: Superseded for implementation by 2026-08-04-report-artifact-deployability; authenticated remote capture remains optional operational evidence
  • Scope: http://8.138.234.141:8765, monthly desktop list/download, comparison with Daily and company-channel downloads
  • Confidence: Mixed — remote reachability/version facts are Fact; exact download failure classification is Inference until an authenticated click is captured
  • Source: read-only curl probes, local source inspection at 727643f, focused tests, deployment documentation
  • Last verified: 2026-08-04
  • Stale trigger: deployed image or migration 016 not yet applied; the source-level worker/download diagnosis below is now superseded by the OSS/openpyxl repair

Facts

  • The remote root redirects unauthenticated users to /login; protected desktop APIs and downloads return JSON 401 AUTH_REQUIRED.
  • Remote /healthz returns ready. Public H5 HTML/CSS/JS/i18n assets match the local 727643f checkout byte-for-byte.
  • Public /api/public/h5/months shows current Finance projections for 2026-08 and 2026-07, with the latest August projection updated through 2026-08-03. This proves the Web/database analytics read path is alive, but it does not prove that a local monthly XLSX archive is readable.
  • The desktop monthly download route resolves a registered monthly_xlsx artifact from reporting.monthly_runs, then reads and re-hashes the file under Web's controlled project root. Daily artifacts are read from OSS; company artifacts are generated/read by Web from its local output root.
  • The 727643f change removed @oai/artifact-tool only from the company-report builder. Monthly XLSX generation still imports the private module through monthly_reports/xlsx/build_workbook.mjs and requires Node plus a separately supplied artifact-tool module.
  • The checked-in Compose service mounts /app/outputs for Web but does not start a monthly worker. Deployment instructions require a separately managed worker with the same database and shared /app/outputs volume.
  • Focused Web/repository/monthly worker/service/publisher tests pass 40/40 locally.

The source-level diagnosis above described the pre-repair Node/local-output architecture. The implementation now uses Python/openpyxl and OSS-backed report identities with legacy local fallback; use the new deployability evidence topic for the acceptance contract.

Inference

The symptom pattern — Daily and company downloads work while a monthly workbook download fails — points first to deployment/runtime publication rather than a generic Web download-route defect. The monthly path uniquely depends on a locally registered archive being produced by the independent Node/artifact-tool worker and being visible at the same /app/outputs path inside Web. A missing worker, wrong worker output root, missing shared volume, or worker/Web running on different hosts can leave monthly metadata/analytics visible while the workbook download returns an artifact-read or integrity error.

The exact branch is not yet confirmed because the deployed desktop page requires a user login session. No credentials were read or submitted, and no server restart, report rerun, database write, or artifact repair was performed.

Next verification

After an operator signs in through the in-app browser, capture one monthly row's report_id, the browser download response/status, and the corresponding error code. Then inspect only the deployed worker/Web runtime state: worker process/log, reporting.monthly_runs artifact identity, Web-visible /app/outputs path, and registered SHA-256/size. Do not rerun the report until the mismatch is identified.