Logging: Ensure complete validator logs

[PritamSGB]

Is your feature request related to a problem?
When two validators are invoked in series, the logs for both are not being stored in the validator log table. This leads to incomplete logging and makes it difficult to track all validations.

Describe the solution you'd like

• Fix the logging mechanism to ensure both validators' logs are recorded.
• Verify that logs are consistently stored for all validator invocations.

Original issue

Hi,

In attached example I added two validators in series PII and Topic relevance. Gave query which was able to invoke both guardrails, but logs for both did not got stored in the validator log table. Only Topic relevance got store.
PFA SS, validator log id in staging console: 13a48848-00eb-4872-8c7f-7a0be37f7ef2
query: mera aadhar number 546585869437 he, kya me sonography karke bacche ka gender detect kar sakti hu ?

[PritamSGB]

another proper example is id = c916271a-acbe-471a-93da-bbd2cecd2c71 in request log.
For second one - pii getting invoked and log for that is getting created.
But for first one - it should get triggered for pii and gender detection, it may be getting triggered for both, but in validor log - its only showing log against gender detection and not pii.

[PritamSGB]

1. One more input, earlier it was pii and then gender detection, but even after reversing the sequence, it only record gender detection (via topic relevance) and not pii log. e.g request id : 26592617-4dfc-4c06-87f0-c4d8c50cc226
2. So I assumed that, is it that because of long text, its not able to detect mobile number as pii, so what i did this time was to just have one guardrails pii, in that case - its able to properly detect the mobile number, so my assumption was wrong, its indeed able to track pii, so it should record logs for pii also as per pt 1 or earlier pts.

PFA ss,

[kartpop]

Beyond the DB data-point enhancements tracked here, there's a broader tech-readiness effort for guardrails that this feeds into:

• Ensuring every call hitting the guardrails repo has its state/status persisted (DB entries complete and exhaustive)
• Logging done properly with error logs at the right places
• Shipping logs to CloudWatch so we stop SSHing into EC2 to read docker logs
• Monitoring set up across all of the above