feat(iswf): Adds exceptions_to_silence parameter to tasks, exposes this and report_timeout_errors in task registration

[GabeVillalobos]

Exposes the previously added report_timeout_errors via task registration method.

Adds a new exceptions_to_silence parameter, which should put us at feature parity with the remainder of fields in @retry:

| Parameter          | Retry | Report | Raise | Description |
|--------------------|-------|--------|-------|-------------|
| on                 | Yes   | Yes    | No    | Exceptions that will trigger a retry & report to Sentry. |
| on_silent          | Yes   | No     | No    | Exceptions that will trigger a retry but not be captured to Sentry. |
| exclude            | No    | No     | Yes   | Exceptions that will not trigger a retry and will be raised. |
| ignore             | No    | No     | No    | Exceptions that will be ignored and not trigger a retry & not report to Sentry. |
| ignore_and_capture | No    | Yes    | No    | Exceptions that will not trigger a retry and will be captured to Sentry. |

To emulate each of these previous parameters:
on

namespace.register(
    ...,
    retry=Retry(times=3, on=(MyCoolException,)),
)

on_silent

namespace.register(
    ...,
    retry=Retry(times=3, on=(MyCoolException,)),
    exceptions_to_silence(MyCoolException,)
)

exclude

namespace.register(
    ...,
    retry=Retry(times=3, on=(...), ignore=(IgnoreMeException,)),
)

ignore

namespace.register(
    ...,
    retry=Retry(times=3, ignore=(IgnoreMeException,)),
    exceptions_to_silence(IgnoreMeException,)
)

ignore_and_capture
.... It's actually not entirely clear to me how this is supposed to behave compared to exclude

[GabeVillalobos]

This name is a little verbose, but the intention here is just to silence sentry errors for some list of exceptions. It should give us the blanket coverage to phase out the remaining options in our retry decorators.

[markstory]

What about expected_errors? These are errors we expect to happen and don't need observability into.

[markstory]

Could these new parameters be added to the docstring as well?

[GabeVillalobos]

Good call, just renamed this and added docstring comments.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 7aa4820. Configure here.}

[markstory]

ignore_and_capture

Can this state just cease to exist? There is a single usage of it in sentry.

[sentry]

Bug: The new expected_exceptions and report_timeout_errors parameters on ExternalNamespace.register() have no effect because ExternalTask instances are not executed locally.
_{Severity: MEDIUM}

Suggested Fix

Raise a TypeError or ValueError if expected_exceptions or report_timeout_errors are passed to ExternalNamespace.register(), as these parameters are not supported for external tasks. Alternatively, document this limitation clearly in the method's docstring to prevent misuse.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: clients/python/src/taskbroker_client/registry.py#L283-L290

Potential issue: The `ExternalNamespace.register()` method now accepts
`expected_exceptions` and `report_timeout_errors` parameters. However, these are
silently ignored for external tasks. These parameters control task execution behavior,
but `ExternalTask` instances are only dispatched, not executed, by the local worker; the
remote application's task registration governs error handling. A developer setting
`expected_exceptions` on an external task stub will incorrectly believe they have
suppressed certain error reports, when in fact the setting has no effect at runtime.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[GabeVillalobos]

Can this state just cease to exist? There is a single usage of it in sentry.

@markstory Yeah we can. I think this change still make sense, excluding that use case, since we won't always want to be notified if we retry a retriable exception.

[evanh]

Could you add some tests for this behaviour?

[GabeVillalobos]

@evanh Added some testing. I think this should cover the major use cases we care about, but can add more if needed.