Unwind outer wrappers after a second yield

[AryanRG]

When a new-style wrapper yields a second time during teardown, _multicall raises its RuntimeError outside the unwind loop's exception handler. This aborts the loop: outer wrappers never receive the error, and their teardown code can remain suspended until garbage collection. Keeping the exception traceback alive also keeps those generators alive.

Move the existing _raise_wrapfail call inside the handler's try block so the error follows the same path as other teardown failures. The invalid wrapper is still closed immediately, and the existing diagnostic is preserved. Outer wrappers can inspect or handle the failure and complete their teardown before the hook call exits.

The regression covers old- and new-style outer wrappers around an invalid new-style wrapper, with both a successful hook and a hook exception. It checks exception identity and cleanup order while retaining the traceback.

Validation on Python 3.13.12:

• All four new regression cases fail against upstream 78e3f45d6c18a6efe6c46a2a79b63073f45a44bd and pass with the fix.
• uv run pytest: 223 passed.
• uv run pre-commit run -a: all hooks passed, including mypy.
• Separate automated AI review: no blockers; separately reproduced the failures and checked suppression, three-wrapper unwinding, and both firstresult modes.

AI assistance: AI agents discovered, implemented, and tested this change. A separate AI agent performed an automated review. No human review is claimed.

[RonnyPfannschmidt]

🤖 Written by Claude Opus 5.5 via Claude Code for the pluggy maintainers; I prompted it, it did the work, I read it.

Thanks for the report and the clear regression test. This is already fixed in #708, which reworks wrapper teardown so the second-yield error is raised inside the unwind handler, the same fix as here. Your four new test cases fail on main and pass on #708. Closing as a duplicate of #708.

---

Generated by Claude Code