ManikandanandClaude Opus 5.5
ba15a574ab
Snapshot of the working project as of 2026-10-23 (local 2d4d4fc), one commit with no earlier history: the tracked files were de-identified first (synthetic claim ids and patient data only; see Context.md section 7). Credentials, run logs, screenshots, claim reports and client workbooks are gitignored and not included. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1.3 KiB
1.3 KiB
Run events go to a file per Run, not to SQL
Every Run writes its events (eCW Login Attempt steps, Run Errors, Claim
Errors, Warnings, each with its time) to Logs\events_<run>.jsonl, and the
Portal's Runs page reads those files — while the Charge Summary rows, Portal
Users and Sign-in history live in SQL Server (Charge_Validation). We chose
files because the events matter most exactly when things go wrong: during
the eCW login (before the database is touched at all), when SQL Server is
down, and when a Run is killed or the browser crashes — a line flushed to a
file survives all of those, the same way Logs\run_<ts>.log already does.
Considered Options
- SQL table (
CV_RunEvent): easier filtering across months, but a Run with no database would lose its own failure record, and the bot's results write is deliberately never fatal — events would inherit that "maybe". - Parse the existing run logs: no bot change, but the log lines carry no time, so login durations and error times could not be shown.
Consequences
- The Runs page reads one small file per Run; if that ever gets slow, load the files into SQL as a copy, keeping the files as the source.
- Portal Users and Sign-ins are in SQL because the Portal already needs SQL for its results; a Portal with no database shows nothing either way.