Describe the bug?
When an input guardrail triggers a rephrase_needed response, the system prematurely returns a BlockResult without saving the LlmCall record in the database. This results in lost data regarding the original user input and the rephrased text.
Describe the solution you'd like
- Restore the original input value after detecting a rephrase response
- Call create_llm_call and update_llm_call_response before returning
- Store both the original query and the rephrased output
- Include the resulting llm_call_id in the returned BlockResult
Original issue
Description:
When an input guardrail fires and returns a rephrase_needed response, the execution path returned a BlockResult early without creating an LlmCall record in the database. This meant the guardrail bypass event — including the original user input and the safe rephrased text — was silently dropped with no trace in the DB.
Root cause:
In execute_llm_call, the early-return path for guardrail rephrase responses skipped the create_llm_call / update_llm_call_response steps that the normal execution path runs. The llm_call_id was also not being passed back in the BlockResult.
Impact:
Guardrail rephrase events are invisible in the database — no audit trail of what the original input was or what safe text was returned.
Downstream consumers relying on llm_call_id from BlockResult received None.
Fix:
After detecting a rephrase response, restore the original (pre-template-interpolation) input value, then call create_llm_call and update_llm_call_response before returning, storing both the original query and the rephrased output. The resulting llm_call_id is included in the returned BlockResult.
Describe the bug?
When an input guardrail triggers a rephrase_needed response, the system prematurely returns a BlockResult without saving the LlmCall record in the database. This results in lost data regarding the original user input and the rephrased text.
Describe the solution you'd like
Original issue
Description:
When an input guardrail fires and returns a rephrase_needed response, the execution path returned a BlockResult early without creating an LlmCall record in the database. This meant the guardrail bypass event — including the original user input and the safe rephrased text — was silently dropped with no trace in the DB.
Root cause:
In execute_llm_call, the early-return path for guardrail rephrase responses skipped the create_llm_call / update_llm_call_response steps that the normal execution path runs. The llm_call_id was also not being passed back in the BlockResult.
Impact:
Guardrail rephrase events are invisible in the database — no audit trail of what the original input was or what safe text was returned.
Downstream consumers relying on llm_call_id from BlockResult received None.
Fix:
After detecting a rephrase response, restore the original (pre-template-interpolation) input value, then call create_llm_call and update_llm_call_response before returning, storing both the original query and the rephrased output. The resulting llm_call_id is included in the returned BlockResult.