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>
26 lines
1.3 KiB
Markdown
26 lines
1.3 KiB
Markdown
# 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.
|