p24-infra Docs

reso-import-post-incident-verify

3 min read

RESO import — post-incident verification (register check)

Purpose: Prove the W3 RESO Excel import path is really working after an incident, by confirming new successful import runs appear in the import register (tasklogs) after the incident-solve timestamp. HTTP 200 on the endpoint is not sufficient — it does not prove parse → Mongo write → S3 store.

Schema pinned 2026-07-13 (discovery on bms-1). The register is tasklogs. A successful import is activityName = "Import poprawny" with status = "completed" — the phrase import udany does not exist in W3. Imported data rows themselves land in regRecords (7.5M docs).

Use after: any W3/RESO import incident (e.g. #4078, solved 2026-07-13 09:58 UTC via PR #4086). Related: v32-reso-socket-stale-image-redis-v5-crashloop.md, pinbox24-w3-operations.md.

Inputs

  • SOLVE_TS — incident-solve time in UTC (e.g. 2026-07-13T09:58:00Z).
  • Service: v32-prod-reso on bms-1 (94.23.26.113). SSH: root@94.23.26.113 (if default key fails, use ~/.ssh/vps_root_key).
  • Endpoint: https://w3.reso-integration-addrecords.pinbox24.com (expect 200).
  • DB: w3_db via V32_PMONGODB_URL, read from /opt/p24-infra/bms-1/pinbox24-w3.env. Never print the URI.
  • mongosh runs on the host (the reso container has no mongo client).

Pinned schema (tasklogs)

FieldMeaning
activityName"Import poprawny" = success; also "Import cofnięty" (reverted), "Importuj dane / import data", "Koniec importu / import end"
statuscompleted / error / not-started
createdAt / updatedAtISODate — use for time comparison
registredDataTimestring "YYYY-MM-DD HH:mm:ss" (local, not for $gt)

No S3 key is stored on the register — S3 write is handled by the s3-v32-prod-reso sidecar (see Step 4).

Step 1 — connectivity sanity (fast)

# PLAYBOOK: reso-import-post-incident-verify.md
ssh root@94.23.26.113 "docker ps --filter name=v32-prod-reso --format '{{.Names}} {{.Status}}'"
curl -s -o /dev/null -w '%{http_code}\n' https://w3.reso-integration-addrecords.pinbox24.com

Container online, 0 restarts, endpoint 200 → proceed. Else stop, this is a fresh outage.

Step 2 — schema re-confirm (skip if unchanged — already pinned above)

Only needed if the W3 schema may have changed. Read V32_PMONGODB_URL silently into $URI (grep, never echo); mongosh runs on the host:

# PLAYBOOK: reso-import-post-incident-verify.md
URI=$(grep '^V32_PMONGODB_URL=' /opt/p24-infra/bms-1/pinbox24-w3.env | cut -d= -f2-)
mongosh "$URI" --quiet --eval \
  'printjson(Object.keys(db.tasklogs.find().sort({_id:-1}).limit(1).toArray()[0]));
   printjson(db.tasklogs.distinct("status"));'
unset URI

Step 3 — the check (new successful imports after solve)

# PLAYBOOK: reso-import-post-incident-verify.md
URI=$(grep '^V32_PMONGODB_URL=' /opt/p24-infra/bms-1/pinbox24-w3.env | cut -d= -f2-)
mongosh "$URI" --quiet --eval '
  const SOLVE = ISODate("2026-07-13T09:58:00Z");           // <-- SOLVE_TS
  const q = { activityName: "Import poprawny", status: "completed",
              createdAt: { $gt: SOLVE } };
  print("count=" + db.tasklogs.countDocuments(q));
  db.tasklogs.find(q, {activityName:1, status:1, createdAt:1, registredDataTime:1})
             .sort({createdAt:-1}).limit(10).forEach(d=>printjson(d));
'
unset URI

PASS: count >= 1 — at least one Import poprawny / completed run with createdAt > SOLVE_TS. Definitive proof the import path (parse → Mongo write) works post-fix. FAIL / count=0: no successful import since the fix — path is NOT confirmed. Ask RESO to run one real upload, then re-run Step 3.

Cross-check: regRecords should also show new import docs (importUpload/excelImportRecord/importedRecordsCount) after SOLVE_TS.

Step 4 — S3 leg (register stores no S3 key)

tasklogs/regRecords do not persist an S3 object key — the source file is read transiently (fileObj.path/fileObj.bucket) and S3 storage is handled by the s3-v32-prod-reso sidecar. To confirm the S3 leg, check that the sidecar is Up and, if needed, list recent objects in Wasabi bucket s3-v32-prod-reso with timestamp after SOLVE_TS.

Step 5 — report

  • Green: N new import udany records since SOLVE_TS, newest at <ts> → incident fully verified, close the loop on the originating issue.
  • Red: 0 new successful imports → keep incident open, request a live upload test.

Schema pinned 2026-07-13 (bms-1 discovery). If a future run finds the field names changed, re-run Step 2 and update the pinned table above.

Graph View

Backlinks