Fix BaseSerialization double-wrapping args for builtin exceptions

[bujjibabukatta]

Ran into this from #69743 — BaseSerialization was mangling args for
built-in exceptions like KeyError on the round trip.

Turns out the exception-serialization branch for KeyError/AttributeError
was storing args as [var.args]. Since var.args is already a tuple
(e.g. ("boom",)), that wraps it in an extra layer. When deserializing,
exc_cls(*args) unpacks that as a single positional arg — so you get
KeyError(("boom",)) instead of KeyError("boom"), and .args comes back
as (("boom",),) instead of ("boom",).

Fix is a one-liner: store list(var.args) instead of [var.args] so it
stays flat.

Added a parametrized test covering single-arg, multi-arg, and no-arg
KeyError/AttributeError round-trips so this doesn't regress.

closes: #69743

AI Disclosure

• This contribution used AI assistance.

Model(s) used: Codex (GPT-5.5) Following by the guidelines

AI was used for:

• Drafting the PR description.
• Verifying test cases locally.
• Reviewing the implementation from a performance perspective.

The implementation and code changes were developed and validated by me.

[aaron-y-chen]

Hi @bujjibabukatta, thanks for the contribution! I'm a bit concerned this might introduce a regression. Could you please double-check to ensure this change won't break existing behavior? Thanks!

[bujjibabukatta]

Hi @nailo2c
Thanks for the review!
I actually went and traced through it before replying instead of just saying "should be fine." Deserialize is untouched, only serialize changed, so anything already sitting in the db from old runs deserializes exactly the same as before, no breakage there. Also checked where this actually gets used (trigger failure handling, xcom etc) and nothing depends on the old broken args shape. The only real difference is the error message itself is correct now instead of showing up wrapped in a weird extra tuple, which was the whole bug. Threw in a newsfragment too so it shows up in release notes. Happy to add more tests if you've got a specific case in mind.

[shahar1]

See #70264 (review)

[bujjibabukatta]

Hi @shahar1 , I've updated the AI disclosure section as requested and addressed the concern mentioned in #70264.

Please let me know if there's anything else I need to update from my side for this PR to be ready for maintainer review again.

Thanks!

[github-actions]

This pull request has been automatically marked as stale because the author has not responded to a request for more information. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This pull request has been closed because the author has not responded to a request for more information.