New Messaging for Tool Form Modal Errors

[hujambo-dunia]

Your error has been logged in Sentry to improve your experience.

Added clarity for errors before Job ID or Dataset ID creation:

• Componentized for: default (ErrorPlugin) or third-party (Sentry)
• Extensible for future user error-tracking (Event-ID) information

Reported by @hexylena in issue
#17560

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[davelopez]

Remember you can run make client-format to fix all the formatting issues.

[davelopez]

I wouldn't explicitly mention Sentry, users may not know what it is. Maybe something like:

Suggested change

	return "Your error has been logged in Sentry to improve your experience.";
	return "The error has been logged in our issue tracker system, and our team is investigating to fix it as soon as possible.";

Or something similar :)

[mvdbeek]

Users don't know what Sentry is, and this is also not logged to Sentry at all, as it is not a bug but a response to a user action that isn't possible. All the actionable information is in the message, but it could be explained better. My suggestion

That message could be improved (this would absolutely be a worthwhile project, the API response is structured so you could mount a nice little component that explains this further),

was to create a component that can expand on the error message by explaining what auto means in this case.
I would also remove the API transcript in that case or hide it under an expandable section, it's not useful to users when what they need to know is already in the message.

The link with Sentry is for when there is actually a bug (a.k.a unhandled exception), for that you'd have to augment the backend response with the backend's sentry clients last_event_id() id (https://github.com/getsentry/sentry-python/blob/bc72f78eea76a77bfd4b445a0424767223d76787/sentry_sdk/scope.py#L326-L340). This would like require a custom FastAPI middleware / exception handler.

[mvdbeek]

This just means we have a sentry client that is able to submit client errors, but that doesn't mean entirely expected things like this error are captured in sentry.