fix: improve misleading warning for progress callback exceptions

[lorenzocesconetto]

Currently if the progress notification callback throws an exception we get a misleading warning message.
This PR aims to fix it.

Motivation and Context

How Has This Been Tested?

Ran a few tests locally.

Breaking Changes

No breaking changes.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[ihrpr]

Thank you so much for working on this!

There are some suggestion would be good to address before merging:

• please can you add tests
• replace use of try-except-else to make it consistent in the project

[lorenzocesconetto]

Hi @ihrpr thank you for the review. I'll add the tests.

[lorenzocesconetto]

Hi @ihrpr, ready for another pass!
I've added the unit test and removed the try-except-else as you've requested.

[Kludex]

Why is it misleading? Do you have a MRE that I can check this locally?

Also, if this makes sense, we should except on ValidationError, not on Exception.

[ihrpr]

Thank you for adding tests! Few things to address - please see comments in PR

1. As Kludex pointed out, the PR catches Exception which is too broad.
2. The warning could include more context about which progress token/request triggered the exception.

[lorenzocesconetto]

Thank you for your reviews and comments @Kludex and @ihrpr!
Totally agree with you guys and changed to ValidationError in the try-except.
I only kept the generic Exception around the callback execution since we don't know what kind of exception might be raised in there.

@Kludex the "misleading" part is that it prints Failed to validate notification... when the user's callback raises an exception. When I saw that for the first time I thought the server notification message was not following the protocol's standard (or the client validation was broken). That message is very misleading. The root cause was a bad implementation of the callback.

[lorenzocesconetto]

@ihrpr can you take another look?

[felixweinberger]

Hi @lorenzocesconetto - thank you for your contribution!

Apologies for the time it took to get back to this - would you be able to update the PR to ensure tests pass and merge conflicts are resolved?

Happy to get back to this quickly if you have the bandwidth to update this PR!

[lorenzocesconetto]

Hi @felixweinberger, thanks for getting back to me, I'll update this PR.
I am actually interested in contributing more to this repo as long as core contributors are willing to provide quick feedback.
Lmk if there's any other issues across the repo that could use an extra pair of hands.

[felixweinberger]

Hi @felixweinberger, thanks for getting back to me, I'll update this PR. I am actually interested in contributing more to this repo as long as core contributors are willing to provide quick feedback. Lmk if there's any other issues across the repo that could use an extra pair of hands.

Thank you for the feedback and yes it's something we're currently working on the team to improve coverage for (so we can get back to people more quickly). I'll be sure to get back to you quickly on this PR.

Thank you for the offer of making more contributions! I'm currently trying to get a handle on clusters of issues on the python SDK worth prioritizing, I'll let you know if I find something suitable that needs some help!

[lorenzocesconetto]

@felixweinberger pulled the latest changes and resolved the conflicts.
But it seems that one of the tests is breaking for python 3.10 but runs successfully for other versions, interesting...

[felixweinberger]

@felixweinberger pulled the latest changes and resolved the conflicts. But it seems that one of the tests is breaking for python 3.10 but runs successfully for other versions, interesting...

Thanks! There is occasional flakiness in the tests, I restarted it let's see if it was one of those.

[Kludex]

There's an outer exception block 🤔

[felixweinberger]

Fair - how would you propose addressing the misleading part here instead? The callback could be anything, so it could throw any kind of exception.

We could potentially replace 410 to just be a generic logging.exception(e) without any additional decoration? In order to be more broad without adding misleading commentary?