Logging/traceability

[Prajna1999]

Summary

Target issue is #123 #124
Adds end-to-end traceability to run_guardrails: every call now records which validators ran, in what order, against which stage, and with what config and result — and every failure path finalizes the request log and leaves an error log line instead of dying silently or getting stuck at PROCESSING.

How: each request stores the payload it arrived with, and each validator run is written to the DB with its execution position, the stage it checked, its type and family, and the exact configuration it executed with — so a single request id reconstructs the whole run after the fact.

Passing validators are now logged by default (not just failures), errors along the way are caught, logged, and turned into normal failure responses rather than exceptions, and a DB hiccup while writing one trace row can't take down the response or the rest of the trace.

Checklist

Before submitting a pull request, please ensure that you mark these task.

• Ran fastapi run --reload app/main.py or docker compose up in the repository root and test.
• If you've fixed a bug or added code that is tested and has test cases.

Notes

Please add here if any other information is required for the reviewer.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Team

Run ID: cdafe2e8-97ec-4a8e-89c0-9040c31eced5

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}