fix(core): retry invalid structured model responses

[BlueCatPro]

Link to Issue or Description of Change

1. Link to an existing issue:

• Closes: SetModelResponseTool: schema validation failure terminates the tool flow instead of returning feedback #1430

Problem:

When set_model_response arguments fail output-schema validation, the validation exception prevents the model from receiving actionable feedback and retrying with a corrected structured response.

Solution:

• Return concise schema-validation feedback from set_model_response so the model can retry.
• Record successfully validated responses in EventActions.
• Promote only validated responses to the final structured model output.
• Remove the appended full schema from validation feedback to keep it concise.
• Add unit and Runner-level regression tests covering validation failure, feedback propagation, retry, and successful final output.

Testing Plan

Unit Tests:

• I have added or updated unit tests for my change.
• The unit tests relevant to this change pass locally.

Tests executed:

• EventActionsTest
• OutputSchemaTest
• SetModelResponseToolTest

Result:

• BUILD SUCCESS
• 27 tests
• 0 failures
• 0 errors

Manual End-to-End (E2E) Tests:

Not run against a live model. A Runner-level regression test using the scripted TestLlm verifies that validation feedback from the invalid call is included in the retry request and that only the corrected, validated response becomes the final structured output.

Checklist

• I have read the CONTRIBUTING.md document.
• My pull request contains a single commit.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have added tests that prove my fix is effective.
• New and existing tests relevant to this change pass locally.
• I have manually tested the change end-to-end with a live model.
• No dependent downstream changes are required.

Additional context

This is my first open-source contribution and my first contribution to adk-java. I may have missed some repository conventions, so I would appreciate any guidance and am happy to make follow-up changes. Thank you for your time and review!

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[hemasekhar-p]

Hi @BlueCatPro, thank you for your contribution! We appreciate you taking the time to submit this pull request. Currently this PR is under review by our team, we will keep you posted if any additional information is required. thank you.

[sherryfox]

Hey @BlueCatPro, thanks for this — and for the issue write-up that preceded it.

I left one parity question about what gets stored so please take a look 🙏

[sherryfox]

Python records the validated and dumped object here, not the input:

validated_response = self.output_schema.model_validate(args)
result = validated_response.model_dump(exclude_none=True)
...
tool_context.actions.set_model_response = result

SchemaUtils.validateMapOnSchema returns void, so there's nothing to store here but args. Confirmed on this branch: {"a":"x","b":null} passes validation unchanged and lands in setSetModelResponse as-is, where Python would emit {"a":"x"}.

Is the difference intended?

[BlueCatPro]

Thanks for catching this, and sorry I missed this distinction. The difference was not intended.
I’ve updated SetModelResponseTool to create a copy after successful validation, omit null-valued fields to match the concrete model_dump(exclude_none=True) behavior you identified, and use the same result both as the tool return value and the value stored in EventActions.