Isolate Sentry instrumentation from task run by potiuk · Pull Request #67505 · apache/airflow

potiuk · 2026-05-25T21:59:36Z

In ConfiguredSentry.enrich_errors, prepare_to_enrich_errors, add_tagging and add_breadcrumbs ran either outside any try block (line 142, pre-fix) or inside the same try-block as the wrapped run(...). An exception raised by any of them propagated through the wrapper, so:

A failure in non-critical Sentry instrumentation was indistinguishable from a real task failure.
The wrapped run never executed — instrumentation could effectively prevent the task from running.

Reported as F-006 in the apache/tooling-agents L3 task-sdk sweep 0920c77.

Change

Wrap each instrumentation step (prepare_to_enrich_errors, add_tagging, add_breadcrumbs) in its own try/except and log a structured warning on failure (sentry_prepare_failed, sentry_add_tagging_failed, sentry_add_breadcrumbs_failed). The wrapped run still runs inside sentry_sdk.new_scope and its exceptions are captured via sentry_sdk.capture_exception(e) and re-raised — that path is unchanged.

Test plan

test_enrich_errors_isolates_instrumentation_from_task_run (parametrised across all three instrumentation steps) — asserts (a) the wrapped run() still executes when each step raises, (b) the structured warning is emitted on the task log.
test_enrich_errors_captures_and_reraises_task_failure — asserts the wrapped-run failure path is unchanged: sentry_sdk.capture_exception is called, exception re-raised.
prek run ruff clean.
prek run mypy-task-sdk clean.
Full test_sentry.py suite: 10 passed.

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

ashb

Can those methods ever realistically fail?

Has this ever happened that we know of?

ashb · 2026-06-04T04:32:17Z

+ except Exception:
+ log.warning("sentry_add_tagging_failed", exc_info=True)
+ try:
 self.add_breadcrumbs(ti)
+ except Exception:
+ log.warning("sentry_add_breadcrumbs_failed", exc_info=True)


A try/except for each is overkill.
Doubly so as these are all local operations. I don't think these can "ever" fail

potiuk · 2026-06-05T01:13:05Z

Good call on the granularity — collapsed it. prepare_to_enrich_errors stays in its own guard (it runs sentry_sdk.init()), and add_tagging + add_breadcrumbs now share a single try/except (one sentry_enrichment_failed warning) instead of one each.

On "can these ever fail / all local operations" though — two of the three aren't local:

add_breadcrumbs isn't local at all: it calls RuntimeTaskInstance.get_task_breadcrumbs(...), which does SUPERVISOR_COMMS.send(GetTaskBreadcrumbs(...)) — a blocking Execution-API/IPC round-trip to the supervisor. That can raise (IPC/API error), and today it would surface as a task failure.
prepare_to_enrich_errors runs sentry_sdk.init(dsn=…) plus conf.getimport("sentry", "before_send"/"transport") — SDK/transport init and importing a configured callable can fail on misconfiguration.
add_tagging is the one that's genuinely local (scope.set_tag + attribute reads), so you're right there — which is partly why it's now folded into the shared guard rather than its own.

So this isn't purely defensive against the impossible — add_breadcrumbs in particular is a remote call we don't want taking down a task. Mind another look?

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

ashb · 2026-06-08T16:59:35Z

+ sentry_sdk_module = sys.modules["sentry_sdk"]
+ sentry_sdk_module.new_scope = mock.MagicMock()
+ sentry_sdk_module.new_scope.return_value.__enter__ = mock.MagicMock()
+ sentry_sdk_module.new_scope.return_value.__exit__ = mock.MagicMock(return_value=False)


This leaks fixtures outside of this test.
This already exist as mock_sentry_sdk fixture and is used in the test right above this one.

In ``ConfiguredSentry.enrich_errors``, ``prepare_to_enrich_errors``, ``add_tagging`` and ``add_breadcrumbs`` ran inside (or alongside) the same try-block as the wrapped ``run(...)``. An exception raised by any of them propagated through the wrapper, so a failure in non-critical Sentry instrumentation looked indistinguishable from a real task failure and the wrapped ``run`` never executed. Wrap each instrumentation step in its own ``try/except`` and log a structured warning on failure. The wrapped ``run`` still runs inside ``sentry_sdk.new_scope`` and its exceptions are captured and re-raised — that part is unchanged.

potiuk · 2026-06-14T01:40:29Z

Fair question — I don't have a production occurrence. This is defensive: add_tagging/add_breadcrumbs call into the Sentry SDK, which can in principle raise (SDK bugs, odd tag-value serialization), and today such a raise is indistinguishable from a real task failure and can stop the wrapped run() from executing at all. The value is decoupling non-critical instrumentation from the critical run path, not fixing an observed bug. If the bar is a demonstrated failure, I'm happy to close it — no strong attachment.

potiuk · 2026-06-21T22:36:23Z

Closing then.

potiuk · 2026-05-25T21:59:36Z

In ConfiguredSentry.enrich_errors, prepare_to_enrich_errors, add_tagging and add_breadcrumbs ran either outside any try block (line 142, pre-fix) or inside the same try-block as the wrapped run(...). An exception raised by any of them propagated through the wrapper, so:

A failure in non-critical Sentry instrumentation was indistinguishable from a real task failure.
The wrapped run never executed — instrumentation could effectively prevent the task from running.

Reported as F-006 in the apache/tooling-agents L3 task-sdk sweep 0920c77.

Change

Wrap each instrumentation step (prepare_to_enrich_errors, add_tagging, add_breadcrumbs) in its own try/except and log a structured warning on failure (sentry_prepare_failed, sentry_add_tagging_failed, sentry_add_breadcrumbs_failed). The wrapped run still runs inside sentry_sdk.new_scope and its exceptions are captured via sentry_sdk.capture_exception(e) and re-raised — that path is unchanged.

Test plan

test_enrich_errors_isolates_instrumentation_from_task_run (parametrised across all three instrumentation steps) — asserts (a) the wrapped run() still executes when each step raises, (b) the structured warning is emitted on the task log.
test_enrich_errors_captures_and_reraises_task_failure — asserts the wrapped-run failure path is unchanged: sentry_sdk.capture_exception is called, exception re-raised.
prek run ruff clean.
prek run mypy-task-sdk clean.
Full test_sentry.py suite: 10 passed.

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

ashb

Can those methods ever realistically fail?

Has this ever happened that we know of?

ashb · 2026-06-04T04:32:17Z

+ except Exception:
+ log.warning("sentry_add_tagging_failed", exc_info=True)
+ try:
 self.add_breadcrumbs(ti)
+ except Exception:
+ log.warning("sentry_add_breadcrumbs_failed", exc_info=True)


A try/except for each is overkill.
Doubly so as these are all local operations. I don't think these can "ever" fail

potiuk · 2026-06-05T01:13:05Z

Good call on the granularity — collapsed it. prepare_to_enrich_errors stays in its own guard (it runs sentry_sdk.init()), and add_tagging + add_breadcrumbs now share a single try/except (one sentry_enrichment_failed warning) instead of one each.

On "can these ever fail / all local operations" though — two of the three aren't local:

add_breadcrumbs isn't local at all: it calls RuntimeTaskInstance.get_task_breadcrumbs(...), which does SUPERVISOR_COMMS.send(GetTaskBreadcrumbs(...)) — a blocking Execution-API/IPC round-trip to the supervisor. That can raise (IPC/API error), and today it would surface as a task failure.
prepare_to_enrich_errors runs sentry_sdk.init(dsn=…) plus conf.getimport("sentry", "before_send"/"transport") — SDK/transport init and importing a configured callable can fail on misconfiguration.
add_tagging is the one that's genuinely local (scope.set_tag + attribute reads), so you're right there — which is partly why it's now folded into the shared guard rather than its own.

So this isn't purely defensive against the impossible — add_breadcrumbs in particular is a remote call we don't want taking down a task. Mind another look?

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

ashb · 2026-06-08T16:59:35Z

+ sentry_sdk_module = sys.modules["sentry_sdk"]
+ sentry_sdk_module.new_scope = mock.MagicMock()
+ sentry_sdk_module.new_scope.return_value.__enter__ = mock.MagicMock()
+ sentry_sdk_module.new_scope.return_value.__exit__ = mock.MagicMock(return_value=False)


This leaks fixtures outside of this test.
This already exist as mock_sentry_sdk fixture and is used in the test right above this one.

In ``ConfiguredSentry.enrich_errors``, ``prepare_to_enrich_errors``, ``add_tagging`` and ``add_breadcrumbs`` ran inside (or alongside) the same try-block as the wrapped ``run(...)``. An exception raised by any of them propagated through the wrapper, so a failure in non-critical Sentry instrumentation looked indistinguishable from a real task failure and the wrapped ``run`` never executed. Wrap each instrumentation step in its own ``try/except`` and log a structured warning on failure. The wrapped ``run`` still runs inside ``sentry_sdk.new_scope`` and its exceptions are captured and re-raised — that part is unchanged.

potiuk · 2026-06-14T01:40:29Z

Fair question — I don't have a production occurrence. This is defensive: add_tagging/add_breadcrumbs call into the Sentry SDK, which can in principle raise (SDK bugs, odd tag-value serialization), and today such a raise is indistinguishable from a real task failure and can stop the wrapped run() from executing at all. The value is decoupling non-critical instrumentation from the critical run path, not fixing an observed bug. If the bar is a demonstrated failure, I'm happy to close it — no strong attachment.

potiuk · 2026-06-21T22:36:23Z

Closing then.

potiuk · 2026-05-25T21:59:36Z

In ConfiguredSentry.enrich_errors, prepare_to_enrich_errors, add_tagging and add_breadcrumbs ran either outside any try block (line 142, pre-fix) or inside the same try-block as the wrapped run(...). An exception raised by any of them propagated through the wrapper, so:

A failure in non-critical Sentry instrumentation was indistinguishable from a real task failure.
The wrapped run never executed — instrumentation could effectively prevent the task from running.

Reported as F-006 in the apache/tooling-agents L3 task-sdk sweep 0920c77.

Change

Wrap each instrumentation step (prepare_to_enrich_errors, add_tagging, add_breadcrumbs) in its own try/except and log a structured warning on failure (sentry_prepare_failed, sentry_add_tagging_failed, sentry_add_breadcrumbs_failed). The wrapped run still runs inside sentry_sdk.new_scope and its exceptions are captured via sentry_sdk.capture_exception(e) and re-raised — that path is unchanged.

Test plan

test_enrich_errors_isolates_instrumentation_from_task_run (parametrised across all three instrumentation steps) — asserts (a) the wrapped run() still executes when each step raises, (b) the structured warning is emitted on the task log.
test_enrich_errors_captures_and_reraises_task_failure — asserts the wrapped-run failure path is unchanged: sentry_sdk.capture_exception is called, exception re-raised.
prek run ruff clean.
prek run mypy-task-sdk clean.
Full test_sentry.py suite: 10 passed.

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

ashb

Can those methods ever realistically fail?

Has this ever happened that we know of?

ashb · 2026-06-04T04:32:17Z

+ except Exception:
+ log.warning("sentry_add_tagging_failed", exc_info=True)
+ try:
 self.add_breadcrumbs(ti)
+ except Exception:
+ log.warning("sentry_add_breadcrumbs_failed", exc_info=True)


A try/except for each is overkill.
Doubly so as these are all local operations. I don't think these can "ever" fail

potiuk · 2026-06-05T01:13:05Z

Good call on the granularity — collapsed it. prepare_to_enrich_errors stays in its own guard (it runs sentry_sdk.init()), and add_tagging + add_breadcrumbs now share a single try/except (one sentry_enrichment_failed warning) instead of one each.

On "can these ever fail / all local operations" though — two of the three aren't local:

add_breadcrumbs isn't local at all: it calls RuntimeTaskInstance.get_task_breadcrumbs(...), which does SUPERVISOR_COMMS.send(GetTaskBreadcrumbs(...)) — a blocking Execution-API/IPC round-trip to the supervisor. That can raise (IPC/API error), and today it would surface as a task failure.
prepare_to_enrich_errors runs sentry_sdk.init(dsn=…) plus conf.getimport("sentry", "before_send"/"transport") — SDK/transport init and importing a configured callable can fail on misconfiguration.
add_tagging is the one that's genuinely local (scope.set_tag + attribute reads), so you're right there — which is partly why it's now folded into the shared guard rather than its own.

So this isn't purely defensive against the impossible — add_breadcrumbs in particular is a remote call we don't want taking down a task. Mind another look?

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

ashb · 2026-06-08T16:59:35Z

+ sentry_sdk_module = sys.modules["sentry_sdk"]
+ sentry_sdk_module.new_scope = mock.MagicMock()
+ sentry_sdk_module.new_scope.return_value.__enter__ = mock.MagicMock()
+ sentry_sdk_module.new_scope.return_value.__exit__ = mock.MagicMock(return_value=False)


This leaks fixtures outside of this test.
This already exist as mock_sentry_sdk fixture and is used in the test right above this one.

In ``ConfiguredSentry.enrich_errors``, ``prepare_to_enrich_errors``, ``add_tagging`` and ``add_breadcrumbs`` ran inside (or alongside) the same try-block as the wrapped ``run(...)``. An exception raised by any of them propagated through the wrapper, so a failure in non-critical Sentry instrumentation looked indistinguishable from a real task failure and the wrapped ``run`` never executed. Wrap each instrumentation step in its own ``try/except`` and log a structured warning on failure. The wrapped ``run`` still runs inside ``sentry_sdk.new_scope`` and its exceptions are captured and re-raised — that part is unchanged.

potiuk · 2026-06-14T01:40:29Z

Fair question — I don't have a production occurrence. This is defensive: add_tagging/add_breadcrumbs call into the Sentry SDK, which can in principle raise (SDK bugs, odd tag-value serialization), and today such a raise is indistinguishable from a real task failure and can stop the wrapped run() from executing at all. The value is decoupling non-critical instrumentation from the critical run path, not fixing an observed bug. If the bar is a demonstrated failure, I'm happy to close it — no strong attachment.

potiuk · 2026-06-21T22:36:23Z

Closing then.

potiuk · 2026-05-25T21:59:36Z

In ConfiguredSentry.enrich_errors, prepare_to_enrich_errors, add_tagging and add_breadcrumbs ran either outside any try block (line 142, pre-fix) or inside the same try-block as the wrapped run(...). An exception raised by any of them propagated through the wrapper, so:

A failure in non-critical Sentry instrumentation was indistinguishable from a real task failure.
The wrapped run never executed — instrumentation could effectively prevent the task from running.

Reported as F-006 in the apache/tooling-agents L3 task-sdk sweep 0920c77.

Change

Wrap each instrumentation step (prepare_to_enrich_errors, add_tagging, add_breadcrumbs) in its own try/except and log a structured warning on failure (sentry_prepare_failed, sentry_add_tagging_failed, sentry_add_breadcrumbs_failed). The wrapped run still runs inside sentry_sdk.new_scope and its exceptions are captured via sentry_sdk.capture_exception(e) and re-raised — that path is unchanged.

Test plan

test_enrich_errors_isolates_instrumentation_from_task_run (parametrised across all three instrumentation steps) — asserts (a) the wrapped run() still executes when each step raises, (b) the structured warning is emitted on the task log.
test_enrich_errors_captures_and_reraises_task_failure — asserts the wrapped-run failure path is unchanged: sentry_sdk.capture_exception is called, exception re-raised.
prek run ruff clean.
prek run mypy-task-sdk clean.
Full test_sentry.py suite: 10 passed.

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

ashb

Can those methods ever realistically fail?

Has this ever happened that we know of?

ashb · 2026-06-04T04:32:17Z

+ except Exception:
+ log.warning("sentry_add_tagging_failed", exc_info=True)
+ try:
 self.add_breadcrumbs(ti)
+ except Exception:
+ log.warning("sentry_add_breadcrumbs_failed", exc_info=True)


A try/except for each is overkill.
Doubly so as these are all local operations. I don't think these can "ever" fail

potiuk · 2026-06-05T01:13:05Z

Good call on the granularity — collapsed it. prepare_to_enrich_errors stays in its own guard (it runs sentry_sdk.init()), and add_tagging + add_breadcrumbs now share a single try/except (one sentry_enrichment_failed warning) instead of one each.

On "can these ever fail / all local operations" though — two of the three aren't local:

add_breadcrumbs isn't local at all: it calls RuntimeTaskInstance.get_task_breadcrumbs(...), which does SUPERVISOR_COMMS.send(GetTaskBreadcrumbs(...)) — a blocking Execution-API/IPC round-trip to the supervisor. That can raise (IPC/API error), and today it would surface as a task failure.
prepare_to_enrich_errors runs sentry_sdk.init(dsn=…) plus conf.getimport("sentry", "before_send"/"transport") — SDK/transport init and importing a configured callable can fail on misconfiguration.
add_tagging is the one that's genuinely local (scope.set_tag + attribute reads), so you're right there — which is partly why it's now folded into the shared guard rather than its own.

So this isn't purely defensive against the impossible — add_breadcrumbs in particular is a remote call we don't want taking down a task. Mind another look?

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

ashb · 2026-06-08T16:59:35Z

+ sentry_sdk_module = sys.modules["sentry_sdk"]
+ sentry_sdk_module.new_scope = mock.MagicMock()
+ sentry_sdk_module.new_scope.return_value.__enter__ = mock.MagicMock()
+ sentry_sdk_module.new_scope.return_value.__exit__ = mock.MagicMock(return_value=False)


This leaks fixtures outside of this test.
This already exist as mock_sentry_sdk fixture and is used in the test right above this one.

In ``ConfiguredSentry.enrich_errors``, ``prepare_to_enrich_errors``, ``add_tagging`` and ``add_breadcrumbs`` ran inside (or alongside) the same try-block as the wrapped ``run(...)``. An exception raised by any of them propagated through the wrapper, so a failure in non-critical Sentry instrumentation looked indistinguishable from a real task failure and the wrapped ``run`` never executed. Wrap each instrumentation step in its own ``try/except`` and log a structured warning on failure. The wrapped ``run`` still runs inside ``sentry_sdk.new_scope`` and its exceptions are captured and re-raised — that part is unchanged.

potiuk · 2026-06-14T01:40:29Z

Fair question — I don't have a production occurrence. This is defensive: add_tagging/add_breadcrumbs call into the Sentry SDK, which can in principle raise (SDK bugs, odd tag-value serialization), and today such a raise is indistinguishable from a real task failure and can stop the wrapped run() from executing at all. The value is decoupling non-critical instrumentation from the critical run path, not fixing an observed bug. If the bar is a demonstrated failure, I'm happy to close it — no strong attachment.

potiuk · 2026-06-21T22:36:23Z

Closing then.

potiuk · 2026-05-25T21:59:36Z

In ConfiguredSentry.enrich_errors, prepare_to_enrich_errors, add_tagging and add_breadcrumbs ran either outside any try block (line 142, pre-fix) or inside the same try-block as the wrapped run(...). An exception raised by any of them propagated through the wrapper, so:

A failure in non-critical Sentry instrumentation was indistinguishable from a real task failure.
The wrapped run never executed — instrumentation could effectively prevent the task from running.

Reported as F-006 in the apache/tooling-agents L3 task-sdk sweep 0920c77.

Change

Wrap each instrumentation step (prepare_to_enrich_errors, add_tagging, add_breadcrumbs) in its own try/except and log a structured warning on failure (sentry_prepare_failed, sentry_add_tagging_failed, sentry_add_breadcrumbs_failed). The wrapped run still runs inside sentry_sdk.new_scope and its exceptions are captured via sentry_sdk.capture_exception(e) and re-raised — that path is unchanged.

Test plan

test_enrich_errors_isolates_instrumentation_from_task_run (parametrised across all three instrumentation steps) — asserts (a) the wrapped run() still executes when each step raises, (b) the structured warning is emitted on the task log.
test_enrich_errors_captures_and_reraises_task_failure — asserts the wrapped-run failure path is unchanged: sentry_sdk.capture_exception is called, exception re-raised.
prek run ruff clean.
prek run mypy-task-sdk clean.
Full test_sentry.py suite: 10 passed.

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

ashb

Can those methods ever realistically fail?

Has this ever happened that we know of?

ashb · 2026-06-04T04:32:17Z

+ except Exception:
+ log.warning("sentry_add_tagging_failed", exc_info=True)
+ try:
 self.add_breadcrumbs(ti)
+ except Exception:
+ log.warning("sentry_add_breadcrumbs_failed", exc_info=True)


A try/except for each is overkill.
Doubly so as these are all local operations. I don't think these can "ever" fail

potiuk · 2026-06-05T01:13:05Z

Good call on the granularity — collapsed it. prepare_to_enrich_errors stays in its own guard (it runs sentry_sdk.init()), and add_tagging + add_breadcrumbs now share a single try/except (one sentry_enrichment_failed warning) instead of one each.

On "can these ever fail / all local operations" though — two of the three aren't local:

add_breadcrumbs isn't local at all: it calls RuntimeTaskInstance.get_task_breadcrumbs(...), which does SUPERVISOR_COMMS.send(GetTaskBreadcrumbs(...)) — a blocking Execution-API/IPC round-trip to the supervisor. That can raise (IPC/API error), and today it would surface as a task failure.
prepare_to_enrich_errors runs sentry_sdk.init(dsn=…) plus conf.getimport("sentry", "before_send"/"transport") — SDK/transport init and importing a configured callable can fail on misconfiguration.
add_tagging is the one that's genuinely local (scope.set_tag + attribute reads), so you're right there — which is partly why it's now folded into the shared guard rather than its own.

So this isn't purely defensive against the impossible — add_breadcrumbs in particular is a remote call we don't want taking down a task. Mind another look?

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

ashb · 2026-06-08T16:59:35Z

+ sentry_sdk_module = sys.modules["sentry_sdk"]
+ sentry_sdk_module.new_scope = mock.MagicMock()
+ sentry_sdk_module.new_scope.return_value.__enter__ = mock.MagicMock()
+ sentry_sdk_module.new_scope.return_value.__exit__ = mock.MagicMock(return_value=False)


This leaks fixtures outside of this test.
This already exist as mock_sentry_sdk fixture and is used in the test right above this one.

In ``ConfiguredSentry.enrich_errors``, ``prepare_to_enrich_errors``, ``add_tagging`` and ``add_breadcrumbs`` ran inside (or alongside) the same try-block as the wrapped ``run(...)``. An exception raised by any of them propagated through the wrapper, so a failure in non-critical Sentry instrumentation looked indistinguishable from a real task failure and the wrapped ``run`` never executed. Wrap each instrumentation step in its own ``try/except`` and log a structured warning on failure. The wrapped ``run`` still runs inside ``sentry_sdk.new_scope`` and its exceptions are captured and re-raised — that part is unchanged.

potiuk · 2026-06-14T01:40:29Z

Fair question — I don't have a production occurrence. This is defensive: add_tagging/add_breadcrumbs call into the Sentry SDK, which can in principle raise (SDK bugs, odd tag-value serialization), and today such a raise is indistinguishable from a real task failure and can stop the wrapped run() from executing at all. The value is decoupling non-critical instrumentation from the critical run path, not fixing an observed bug. If the bar is a demonstrated failure, I'm happy to close it — no strong attachment.

potiuk · 2026-06-21T22:36:23Z

Closing then.

potiuk · 2026-05-25T21:59:36Z

In ConfiguredSentry.enrich_errors, prepare_to_enrich_errors, add_tagging and add_breadcrumbs ran either outside any try block (line 142, pre-fix) or inside the same try-block as the wrapped run(...). An exception raised by any of them propagated through the wrapper, so:

A failure in non-critical Sentry instrumentation was indistinguishable from a real task failure.
The wrapped run never executed — instrumentation could effectively prevent the task from running.

Reported as F-006 in the apache/tooling-agents L3 task-sdk sweep 0920c77.

Change

Wrap each instrumentation step (prepare_to_enrich_errors, add_tagging, add_breadcrumbs) in its own try/except and log a structured warning on failure (sentry_prepare_failed, sentry_add_tagging_failed, sentry_add_breadcrumbs_failed). The wrapped run still runs inside sentry_sdk.new_scope and its exceptions are captured via sentry_sdk.capture_exception(e) and re-raised — that path is unchanged.

Test plan

test_enrich_errors_isolates_instrumentation_from_task_run (parametrised across all three instrumentation steps) — asserts (a) the wrapped run() still executes when each step raises, (b) the structured warning is emitted on the task log.
test_enrich_errors_captures_and_reraises_task_failure — asserts the wrapped-run failure path is unchanged: sentry_sdk.capture_exception is called, exception re-raised.
prek run ruff clean.
prek run mypy-task-sdk clean.
Full test_sentry.py suite: 10 passed.

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

ashb

Can those methods ever realistically fail?

Has this ever happened that we know of?

ashb · 2026-06-04T04:32:17Z

+ except Exception:
+ log.warning("sentry_add_tagging_failed", exc_info=True)
+ try:
 self.add_breadcrumbs(ti)
+ except Exception:
+ log.warning("sentry_add_breadcrumbs_failed", exc_info=True)


A try/except for each is overkill.
Doubly so as these are all local operations. I don't think these can "ever" fail

potiuk · 2026-06-05T01:13:05Z

Good call on the granularity — collapsed it. prepare_to_enrich_errors stays in its own guard (it runs sentry_sdk.init()), and add_tagging + add_breadcrumbs now share a single try/except (one sentry_enrichment_failed warning) instead of one each.

On "can these ever fail / all local operations" though — two of the three aren't local:

add_breadcrumbs isn't local at all: it calls RuntimeTaskInstance.get_task_breadcrumbs(...), which does SUPERVISOR_COMMS.send(GetTaskBreadcrumbs(...)) — a blocking Execution-API/IPC round-trip to the supervisor. That can raise (IPC/API error), and today it would surface as a task failure.
prepare_to_enrich_errors runs sentry_sdk.init(dsn=…) plus conf.getimport("sentry", "before_send"/"transport") — SDK/transport init and importing a configured callable can fail on misconfiguration.
add_tagging is the one that's genuinely local (scope.set_tag + attribute reads), so you're right there — which is partly why it's now folded into the shared guard rather than its own.

So this isn't purely defensive against the impossible — add_breadcrumbs in particular is a remote call we don't want taking down a task. Mind another look?

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

ashb · 2026-06-08T16:59:35Z

+ sentry_sdk_module = sys.modules["sentry_sdk"]
+ sentry_sdk_module.new_scope = mock.MagicMock()
+ sentry_sdk_module.new_scope.return_value.__enter__ = mock.MagicMock()
+ sentry_sdk_module.new_scope.return_value.__exit__ = mock.MagicMock(return_value=False)


This leaks fixtures outside of this test.
This already exist as mock_sentry_sdk fixture and is used in the test right above this one.

In ``ConfiguredSentry.enrich_errors``, ``prepare_to_enrich_errors``, ``add_tagging`` and ``add_breadcrumbs`` ran inside (or alongside) the same try-block as the wrapped ``run(...)``. An exception raised by any of them propagated through the wrapper, so a failure in non-critical Sentry instrumentation looked indistinguishable from a real task failure and the wrapped ``run`` never executed. Wrap each instrumentation step in its own ``try/except`` and log a structured warning on failure. The wrapped ``run`` still runs inside ``sentry_sdk.new_scope`` and its exceptions are captured and re-raised — that part is unchanged.

potiuk · 2026-06-14T01:40:29Z

Fair question — I don't have a production occurrence. This is defensive: add_tagging/add_breadcrumbs call into the Sentry SDK, which can in principle raise (SDK bugs, odd tag-value serialization), and today such a raise is indistinguishable from a real task failure and can stop the wrapped run() from executing at all. The value is decoupling non-critical instrumentation from the critical run path, not fixing an observed bug. If the bar is a demonstrated failure, I'm happy to close it — no strong attachment.

potiuk · 2026-06-21T22:36:23Z

Closing then.

potiuk · 2026-05-25T21:59:36Z

In ConfiguredSentry.enrich_errors, prepare_to_enrich_errors, add_tagging and add_breadcrumbs ran either outside any try block (line 142, pre-fix) or inside the same try-block as the wrapped run(...). An exception raised by any of them propagated through the wrapper, so:

A failure in non-critical Sentry instrumentation was indistinguishable from a real task failure.
The wrapped run never executed — instrumentation could effectively prevent the task from running.

Reported as F-006 in the apache/tooling-agents L3 task-sdk sweep 0920c77.

Change

Wrap each instrumentation step (prepare_to_enrich_errors, add_tagging, add_breadcrumbs) in its own try/except and log a structured warning on failure (sentry_prepare_failed, sentry_add_tagging_failed, sentry_add_breadcrumbs_failed). The wrapped run still runs inside sentry_sdk.new_scope and its exceptions are captured via sentry_sdk.capture_exception(e) and re-raised — that path is unchanged.

Test plan

test_enrich_errors_isolates_instrumentation_from_task_run (parametrised across all three instrumentation steps) — asserts (a) the wrapped run() still executes when each step raises, (b) the structured warning is emitted on the task log.
test_enrich_errors_captures_and_reraises_task_failure — asserts the wrapped-run failure path is unchanged: sentry_sdk.capture_exception is called, exception re-raised.
prek run ruff clean.
prek run mypy-task-sdk clean.
Full test_sentry.py suite: 10 passed.

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

ashb

Can those methods ever realistically fail?

Has this ever happened that we know of?

ashb · 2026-06-04T04:32:17Z

+ except Exception:
+ log.warning("sentry_add_tagging_failed", exc_info=True)
+ try:
 self.add_breadcrumbs(ti)
+ except Exception:
+ log.warning("sentry_add_breadcrumbs_failed", exc_info=True)


A try/except for each is overkill.
Doubly so as these are all local operations. I don't think these can "ever" fail

potiuk · 2026-06-05T01:13:05Z

Good call on the granularity — collapsed it. prepare_to_enrich_errors stays in its own guard (it runs sentry_sdk.init()), and add_tagging + add_breadcrumbs now share a single try/except (one sentry_enrichment_failed warning) instead of one each.

On "can these ever fail / all local operations" though — two of the three aren't local:

add_breadcrumbs isn't local at all: it calls RuntimeTaskInstance.get_task_breadcrumbs(...), which does SUPERVISOR_COMMS.send(GetTaskBreadcrumbs(...)) — a blocking Execution-API/IPC round-trip to the supervisor. That can raise (IPC/API error), and today it would surface as a task failure.
prepare_to_enrich_errors runs sentry_sdk.init(dsn=…) plus conf.getimport("sentry", "before_send"/"transport") — SDK/transport init and importing a configured callable can fail on misconfiguration.
add_tagging is the one that's genuinely local (scope.set_tag + attribute reads), so you're right there — which is partly why it's now folded into the shared guard rather than its own.

So this isn't purely defensive against the impossible — add_breadcrumbs in particular is a remote call we don't want taking down a task. Mind another look?

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

ashb · 2026-06-08T16:59:35Z

+ sentry_sdk_module = sys.modules["sentry_sdk"]
+ sentry_sdk_module.new_scope = mock.MagicMock()
+ sentry_sdk_module.new_scope.return_value.__enter__ = mock.MagicMock()
+ sentry_sdk_module.new_scope.return_value.__exit__ = mock.MagicMock(return_value=False)


This leaks fixtures outside of this test.
This already exist as mock_sentry_sdk fixture and is used in the test right above this one.

In ``ConfiguredSentry.enrich_errors``, ``prepare_to_enrich_errors``, ``add_tagging`` and ``add_breadcrumbs`` ran inside (or alongside) the same try-block as the wrapped ``run(...)``. An exception raised by any of them propagated through the wrapper, so a failure in non-critical Sentry instrumentation looked indistinguishable from a real task failure and the wrapped ``run`` never executed. Wrap each instrumentation step in its own ``try/except`` and log a structured warning on failure. The wrapped ``run`` still runs inside ``sentry_sdk.new_scope`` and its exceptions are captured and re-raised — that part is unchanged.

potiuk · 2026-06-14T01:40:29Z

Fair question — I don't have a production occurrence. This is defensive: add_tagging/add_breadcrumbs call into the Sentry SDK, which can in principle raise (SDK bugs, odd tag-value serialization), and today such a raise is indistinguishable from a real task failure and can stop the wrapped run() from executing at all. The value is decoupling non-critical instrumentation from the critical run path, not fixing an observed bug. If the bar is a demonstrated failure, I'm happy to close it — no strong attachment.

potiuk · 2026-06-21T22:36:23Z

Closing then.

potiuk · 2026-05-25T21:59:36Z

In ConfiguredSentry.enrich_errors, prepare_to_enrich_errors, add_tagging and add_breadcrumbs ran either outside any try block (line 142, pre-fix) or inside the same try-block as the wrapped run(...). An exception raised by any of them propagated through the wrapper, so:

A failure in non-critical Sentry instrumentation was indistinguishable from a real task failure.
The wrapped run never executed — instrumentation could effectively prevent the task from running.

Reported as F-006 in the apache/tooling-agents L3 task-sdk sweep 0920c77.

Change

Wrap each instrumentation step (prepare_to_enrich_errors, add_tagging, add_breadcrumbs) in its own try/except and log a structured warning on failure (sentry_prepare_failed, sentry_add_tagging_failed, sentry_add_breadcrumbs_failed). The wrapped run still runs inside sentry_sdk.new_scope and its exceptions are captured via sentry_sdk.capture_exception(e) and re-raised — that path is unchanged.

Test plan

test_enrich_errors_isolates_instrumentation_from_task_run (parametrised across all three instrumentation steps) — asserts (a) the wrapped run() still executes when each step raises, (b) the structured warning is emitted on the task log.
test_enrich_errors_captures_and_reraises_task_failure — asserts the wrapped-run failure path is unchanged: sentry_sdk.capture_exception is called, exception re-raised.
prek run ruff clean.
prek run mypy-task-sdk clean.
Full test_sentry.py suite: 10 passed.

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

ashb

Can those methods ever realistically fail?

Has this ever happened that we know of?

ashb · 2026-06-04T04:32:17Z

+ except Exception:
+ log.warning("sentry_add_tagging_failed", exc_info=True)
+ try:
 self.add_breadcrumbs(ti)
+ except Exception:
+ log.warning("sentry_add_breadcrumbs_failed", exc_info=True)


A try/except for each is overkill.
Doubly so as these are all local operations. I don't think these can "ever" fail

potiuk · 2026-06-05T01:13:05Z

Good call on the granularity — collapsed it. prepare_to_enrich_errors stays in its own guard (it runs sentry_sdk.init()), and add_tagging + add_breadcrumbs now share a single try/except (one sentry_enrichment_failed warning) instead of one each.

On "can these ever fail / all local operations" though — two of the three aren't local:

add_breadcrumbs isn't local at all: it calls RuntimeTaskInstance.get_task_breadcrumbs(...), which does SUPERVISOR_COMMS.send(GetTaskBreadcrumbs(...)) — a blocking Execution-API/IPC round-trip to the supervisor. That can raise (IPC/API error), and today it would surface as a task failure.
prepare_to_enrich_errors runs sentry_sdk.init(dsn=…) plus conf.getimport("sentry", "before_send"/"transport") — SDK/transport init and importing a configured callable can fail on misconfiguration.
add_tagging is the one that's genuinely local (scope.set_tag + attribute reads), so you're right there — which is partly why it's now folded into the shared guard rather than its own.

So this isn't purely defensive against the impossible — add_breadcrumbs in particular is a remote call we don't want taking down a task. Mind another look?

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

ashb · 2026-06-08T16:59:35Z

+ sentry_sdk_module = sys.modules["sentry_sdk"]
+ sentry_sdk_module.new_scope = mock.MagicMock()
+ sentry_sdk_module.new_scope.return_value.__enter__ = mock.MagicMock()
+ sentry_sdk_module.new_scope.return_value.__exit__ = mock.MagicMock(return_value=False)


This leaks fixtures outside of this test.
This already exist as mock_sentry_sdk fixture and is used in the test right above this one.

In ``ConfiguredSentry.enrich_errors``, ``prepare_to_enrich_errors``, ``add_tagging`` and ``add_breadcrumbs`` ran inside (or alongside) the same try-block as the wrapped ``run(...)``. An exception raised by any of them propagated through the wrapper, so a failure in non-critical Sentry instrumentation looked indistinguishable from a real task failure and the wrapped ``run`` never executed. Wrap each instrumentation step in its own ``try/except`` and log a structured warning on failure. The wrapped ``run`` still runs inside ``sentry_sdk.new_scope`` and its exceptions are captured and re-raised — that part is unchanged.

potiuk · 2026-06-14T01:40:29Z

Fair question — I don't have a production occurrence. This is defensive: add_tagging/add_breadcrumbs call into the Sentry SDK, which can in principle raise (SDK bugs, odd tag-value serialization), and today such a raise is indistinguishable from a real task failure and can stop the wrapped run() from executing at all. The value is decoupling non-critical instrumentation from the critical run path, not fixing an observed bug. If the bar is a demonstrated failure, I'm happy to close it — no strong attachment.

potiuk · 2026-06-21T22:36:23Z

Closing then.

potiuk requested review from amoghrajesh, ashb and kaxil as code owners May 25, 2026 21:59

boring-cyborgBot added the area:task-sdk label May 25, 2026

potiuk mentioned this pull request Jun 3, 2026
Warn when supervisor-side mask_secret IPC send fails #67503
Closed
7 tasks

ashb requested changes Jun 4, 2026
View reviewed changes

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from 7b93c6b to ab8fbb6Compare June 5, 2026 01:10

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ab8fbb6 to ca897a8Compare June 5, 2026 14:03

ashb reviewed Jun 8, 2026
View reviewed changes

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ca897a8 to ac9dd53Compare June 11, 2026 01:28

potiuk marked this pull request as draft June 11, 2026 01:36

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ac9dd53 to 2fd2f54Compare June 11, 2026 01:37

potiuk marked this pull request as ready for review June 11, 2026 17:33

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from 2fd2f54 to 4822f54Compare June 11, 2026 17:33

potiuk closed this Jun 21, 2026

potiuk requested review from amoghrajesh, ashb and kaxil as code owners May 25, 2026 21:59

boring-cyborgBot added the area:task-sdk label May 25, 2026

potiuk mentioned this pull request Jun 3, 2026
Warn when supervisor-side mask_secret IPC send fails #67503
Closed
7 tasks

ashb requested changes Jun 4, 2026
View reviewed changes

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from 7b93c6b to ab8fbb6Compare June 5, 2026 01:10

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ab8fbb6 to ca897a8Compare June 5, 2026 14:03

ashb reviewed Jun 8, 2026
View reviewed changes

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ca897a8 to ac9dd53Compare June 11, 2026 01:28

potiuk marked this pull request as draft June 11, 2026 01:36

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ac9dd53 to 2fd2f54Compare June 11, 2026 01:37

potiuk marked this pull request as ready for review June 11, 2026 17:33

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from 2fd2f54 to 4822f54Compare June 11, 2026 17:33

potiuk closed this Jun 21, 2026

potiuk requested review from amoghrajesh, ashb and kaxil as code owners May 25, 2026 21:59

boring-cyborgBot added the area:task-sdk label May 25, 2026

potiuk mentioned this pull request Jun 3, 2026
Warn when supervisor-side mask_secret IPC send fails #67503
Closed
7 tasks

ashb requested changes Jun 4, 2026
View reviewed changes

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from 7b93c6b to ab8fbb6Compare June 5, 2026 01:10

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ab8fbb6 to ca897a8Compare June 5, 2026 14:03

ashb reviewed Jun 8, 2026
View reviewed changes

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ca897a8 to ac9dd53Compare June 11, 2026 01:28

potiuk marked this pull request as draft June 11, 2026 01:36

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ac9dd53 to 2fd2f54Compare June 11, 2026 01:37

potiuk marked this pull request as ready for review June 11, 2026 17:33

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from 2fd2f54 to 4822f54Compare June 11, 2026 17:33

potiuk closed this Jun 21, 2026

potiuk requested review from amoghrajesh, ashb and kaxil as code owners May 25, 2026 21:59

boring-cyborgBot added the area:task-sdk label May 25, 2026

potiuk mentioned this pull request Jun 3, 2026
Warn when supervisor-side mask_secret IPC send fails #67503
Closed
7 tasks

ashb requested changes Jun 4, 2026
View reviewed changes

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from 7b93c6b to ab8fbb6Compare June 5, 2026 01:10

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ab8fbb6 to ca897a8Compare June 5, 2026 14:03

ashb reviewed Jun 8, 2026
View reviewed changes

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ca897a8 to ac9dd53Compare June 11, 2026 01:28

potiuk marked this pull request as draft June 11, 2026 01:36

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ac9dd53 to 2fd2f54Compare June 11, 2026 01:37

potiuk marked this pull request as ready for review June 11, 2026 17:33

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from 2fd2f54 to 4822f54Compare June 11, 2026 17:33

potiuk closed this Jun 21, 2026

potiuk requested review from amoghrajesh, ashb and kaxil as code owners May 25, 2026 21:59

boring-cyborgBot added the area:task-sdk label May 25, 2026

potiuk mentioned this pull request Jun 3, 2026
Warn when supervisor-side mask_secret IPC send fails #67503
Closed
7 tasks

ashb requested changes Jun 4, 2026
View reviewed changes

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from 7b93c6b to ab8fbb6Compare June 5, 2026 01:10

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ab8fbb6 to ca897a8Compare June 5, 2026 14:03

ashb reviewed Jun 8, 2026
View reviewed changes

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ca897a8 to ac9dd53Compare June 11, 2026 01:28

potiuk marked this pull request as draft June 11, 2026 01:36

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ac9dd53 to 2fd2f54Compare June 11, 2026 01:37

potiuk marked this pull request as ready for review June 11, 2026 17:33

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from 2fd2f54 to 4822f54Compare June 11, 2026 17:33

potiuk closed this Jun 21, 2026

potiuk requested review from amoghrajesh, ashb and kaxil as code owners May 25, 2026 21:59

boring-cyborgBot added the area:task-sdk label May 25, 2026

potiuk mentioned this pull request Jun 3, 2026
Warn when supervisor-side mask_secret IPC send fails #67503
Closed
7 tasks

ashb requested changes Jun 4, 2026
View reviewed changes

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from 7b93c6b to ab8fbb6Compare June 5, 2026 01:10

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ab8fbb6 to ca897a8Compare June 5, 2026 14:03

ashb reviewed Jun 8, 2026
View reviewed changes

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ca897a8 to ac9dd53Compare June 11, 2026 01:28

potiuk marked this pull request as draft June 11, 2026 01:36

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ac9dd53 to 2fd2f54Compare June 11, 2026 01:37

potiuk marked this pull request as ready for review June 11, 2026 17:33

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from 2fd2f54 to 4822f54Compare June 11, 2026 17:33

potiuk closed this Jun 21, 2026

potiuk requested review from amoghrajesh, ashb and kaxil as code owners May 25, 2026 21:59

boring-cyborgBot added the area:task-sdk label May 25, 2026

potiuk mentioned this pull request Jun 3, 2026
Warn when supervisor-side mask_secret IPC send fails #67503
Closed
7 tasks

ashb requested changes Jun 4, 2026
View reviewed changes

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from 7b93c6b to ab8fbb6Compare June 5, 2026 01:10

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ab8fbb6 to ca897a8Compare June 5, 2026 14:03

ashb reviewed Jun 8, 2026
View reviewed changes

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ca897a8 to ac9dd53Compare June 11, 2026 01:28

potiuk marked this pull request as draft June 11, 2026 01:36

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ac9dd53 to 2fd2f54Compare June 11, 2026 01:37

potiuk marked this pull request as ready for review June 11, 2026 17:33

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from 2fd2f54 to 4822f54Compare June 11, 2026 17:33

potiuk closed this Jun 21, 2026

potiuk requested review from amoghrajesh, ashb and kaxil as code owners May 25, 2026 21:59

boring-cyborgBot added the area:task-sdk label May 25, 2026

potiuk mentioned this pull request Jun 3, 2026
Warn when supervisor-side mask_secret IPC send fails #67503
Closed
7 tasks

ashb requested changes Jun 4, 2026
View reviewed changes

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from 7b93c6b to ab8fbb6Compare June 5, 2026 01:10

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ab8fbb6 to ca897a8Compare June 5, 2026 14:03

ashb reviewed Jun 8, 2026
View reviewed changes

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ca897a8 to ac9dd53Compare June 11, 2026 01:28

potiuk marked this pull request as draft June 11, 2026 01:36

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from ac9dd53 to 2fd2f54Compare June 11, 2026 01:37

potiuk marked this pull request as ready for review June 11, 2026 17:33

potiuk force-pushed the isolate-sentry-instrumentation-from-task-run branch from 2fd2f54 to 4822f54Compare June 11, 2026 17:33

potiuk closed this Jun 21, 2026

Uh oh!

Conversation

potiuk commented May 25, 2026

Change

Test plan

Was generative AI tooling used to co-author this PR?

Uh oh!

ashb left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

potiuk commented Jun 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

potiuk commented Jun 14, 2026

Uh oh!

potiuk commented Jun 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

potiuk commented May 25, 2026

Change

Test plan

Was generative AI tooling used to co-author this PR?

Uh oh!

ashb left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

potiuk commented Jun 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

potiuk commented Jun 14, 2026

Uh oh!

potiuk commented Jun 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

potiuk commented May 25, 2026

Change

Test plan

Was generative AI tooling used to co-author this PR?

Uh oh!

ashb left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

potiuk commented Jun 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

potiuk commented Jun 14, 2026

Uh oh!

potiuk commented Jun 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects