change strict_exception_groups default to True #2886

jakkdl · 2023-11-24T17:38:02Z

this commit ... is a monster. I could try to split it up some things into separate PRs, but a lot of it is hard to separate.

See discussion in Remove MultiError and set strict_exception_groups=True by default #2785, which this fixes most of.
I've written an implementation for pytest.raises that handles exceptiongroups. This should probably be added upstream, or in a separate package, or do a way less illegal way of interaction. mypy also goes mad on it, as it should. Don't focus on reviewing _exceptiongroup_util.py for now. See Allow pytest.raises cooperate with ExceptionGroups pytest-dev/pytest#11538
A ton of tests had to be changed with the functionality change. I started out by passing strict_exception_groups=False, but decided that embracing the future is much better in the long term and it unveiled a bunch of issues.
Most tests are fine, but I haven't looked super closely at all instances where exceptiongroups now get raised, or don't, so the tests diff should be looked over very closely I've marked a couple instances where it seemed clearly suspect that exceptions did or didn't get wrapped - even got an instance of triple-wrapped exceptions that probably should be fixed in a separate PR.
_assert_raises has been removed. It seems to be a relic with no reason for existing
several tests were likewise ... weirdly written, or simply didn't have the almighty power of ExpectedExceptionGroup, and have been simplified.
I left actually removing MultiError and changing nurseries etc to raise ExceptionGroups instead to a separate PR. But changed some tests to check for identity with ExceptionGroup instead of MultiError. (ignore the name of the branch >.>)

This is a pretty big change, and touches on lots and lots of stuff, and should figure out a solution for raises/ExpectedExceptionGroup, so I expect this to stay as a draft for quite a while - maybe with other PRs splitting out from it and implementing parts of it or fixing weird [non-]wrapping.

codecov · 2023-11-24T17:40:04Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (e4c8eb2) 99.64% compared to head (0b45ec9) 99.64%.
Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2886   +/-   ##
=======================================
  Coverage   99.64%   99.64%           
=======================================
  Files         116      116           
  Lines       17477    17499   +22     
  Branches     3133     3147   +14     
=======================================
+ Hits        17415    17437   +22     
  Misses         43       43           
  Partials       19       19

Files	Coverage Δ
src/trio/_core/_run.py	`99.66% <ø> (ø)`
src/trio/_core/_tests/test_ki.py	`97.83% <100.00%> (+<0.01%)`	⬆️
src/trio/_core/_tests/test_run.py	`100.00% <100.00%> (ø)`
src/trio/_subprocess.py	`100.00% <100.00%> (ø)`
src/trio/_tests/test_highlevel_open_tcp_stream.py	`100.00% <100.00%> (ø)`
src/trio/_tests/test_highlevel_serve_listeners.py	`100.00% <100.00%> (ø)`
src/trio/_tests/test_signals.py	`100.00% <100.00%> (ø)`
src/trio/_tests/test_socket.py	`100.00% <100.00%> (ø)`
src/trio/_tests/test_ssl.py	`99.85% <100.00%> (ø)`
src/trio/_tests/test_subprocess.py	`99.23% <100.00%> (+0.04%)`	⬆️
... and 4 more

jakkdl · 2023-11-24T17:44:38Z

Other than ExpectedExceptionGroup not being final, all tests pass for me locally. Remains to see if I messed up some mac/windows/pypy-only test

A5rocks

Some initial comments

A5rocks · 2023-11-25T01:59:03Z

docs/source/reference-core.rst

+of ``TaskGroup`` in asyncio and anyio. This is also to avoid any bugs caused by only
+catching one type of exceptions/exceptiongroups.


Suggested change

of ``TaskGroup`` in asyncio and anyio. This is also to avoid any bugs caused by only

catching one type of exceptions/exceptiongroups.

of ``TaskGroup`` in asyncio and anyio. This is also to avoid any bugs caused by only

catching single exceptions in a concurrent scenario.

I'm not thrilled about either wording (proposed or original) though.

I think that we'll eventually want to rewrite this whole section from the new strict-by-default perspective, under the heading "Deprecated: non-strict ExceptionGroups" - to explain that it only exists for backwards-compatibility, will be removed in future, and that we recommend against it for all new code.

I don't want to delay this PR further though, so let's open an issue to revisit the docs on this topic rather than waiting to merge.

src/trio/_core/_tests/test_ki.py

src/trio/_core/_tests/test_run.py

src/trio/testing/_exceptiongroup_util.py

Zac-HD

Nice work!

I've left my thoughts on the raises() context manager over in pytest-dev/pytest#11538 (comment).

If you could pull out the _assert_raises removal and any other test improvements that don't need this to be merged, I'd love to get them in sooner and reduce the size of this diff 🙂

Zac-HD · 2023-11-25T18:33:29Z

newsfragments/2786.breaking.rst

@@ -0,0 +1,2 @@
+``strict_exception_groups`` now defaults to True in ``trio.run`` and ``trio.start_guest_run``, as well as ``trio.open_nursery`` as a result of that.


As as result of that what?

I'd also use rst cross-references here.

kinda awkward wording, but should be better now

Zac-HD · 2023-11-25T18:36:00Z

src/trio/_core/_run.py

+      strict_exception_groups (bool): Unless set to false, nurseries will always wrap
+          even a single raised exception in an exception group. This can be overridden
+          on the level of individual nurseries.


I prefer this to the phrasing in the open_nursery() docs above - replace that with this? It would also be good to note that strict_exception_groups=False is deprecated and will eventually be removed.

I think it's important to add that "=False is deprecated, and will be removed in a future version of Trio."

I think we need to add a DeprecationWarning when specifying False to use a wording like that. But if we wanna do that as well in the same release I can get going on it in a separate PR.

added note about =False being deprecated&removed in the future, and updated open_nursery docstring.

src/trio/_core/_tests/test_run.py

docs/source/reference-core.rst

…ups, and noted by reviewers

jakkdl · 2023-12-11T14:03:31Z

Reviewed two cases where I thought ExceptionGroups were missing, and they turned out to be fairly simple cases. Next steps:

update comments & docs from review
rebase on top of Add RaisesGroup, a helper for catching ExceptionGroups in tests #2898 once merged
rebase on top of remove multierror #2891 once merged

CoolCat467 · 2023-12-13T20:57:53Z

pre-commit.ci autofix

jakkdl · 2023-12-14T16:27:55Z

Ah right, a plethora of PT012. Well, first gotta settle on what message to add to them. PT017 in the helper is pretty amusing.

src/trio/_core/_tests/test_run.py

and fix various errors, also disabling PT012.

Note that this has *both* RaisesGroup and ExpectedExceptionGroup

jakkdl · 2024-01-07T14:23:40Z

src/trio/_core/_tests/test_run.py

-    assert RaisesGroup(KeyError, ValueError).matches(excinfo.value.__cause__)
+    # TODO: triple-wrapped exceptions ?!?!
+    assert RaisesGroup(RaisesGroup(RaisesGroup(KeyError, ValueError))).matches(
+        excinfo.value.__cause__
+    )


The reason for the triple-wrapping turns out to be quite straightforward:

trio/src/trio/_core/_run.py

Lines 1903 to 1913 in aadd1ea

async def init(

self,

async_fn: Callable[[Unpack[PosArgT]], Awaitable[object]],

args: tuple[Unpack[PosArgT]],

) -> None:

# run_sync_soon task runs here:

async with open_nursery() as run_sync_soon_nursery:

# All other system tasks run here:

async with open_nursery() as self.system_nursery:

# Only the main task runs here:

async with open_nursery() as main_task_nursery:

doesn't make for the cleanest __cause__s on TrioInternalErrors, but don't think it's a problem. Updating comments.

jakkdl

I've been procrastinating on cleaning up the language in docstrings/documentation. But other than that I think this is the only remaining problem, where run_process sometimes raises an exceptiongroup and sometimes doesn't.
There's maybe better solutions, but I'd just wrap the nursery call in a try/except and raise a new error with the caught exceptiongroup as a cause, as I described in the comment in _subprocess.py.

jakkdl · 2024-01-07T15:29:10Z

src/trio/_subprocess.py

+    # TODO: if this nursery raises an exceptiongroup, manually raise a CalledProcessError,
+    # or maybe a InternalTrioError, with the exceptiongroup as a cause, so run_process
+    # never raises an exceptiongroup. (?)
    async with trio.open_nursery() as nursery:
        # options needs a complex TypedDict. The overload error only occurs on Unix.
        proc = await open_process(command, **options)  # type: ignore[arg-type, call-overload, unused-ignore]


(surfacing from an ~hour-long dive into run_process()) I think it's sufficiently unlikely to get an ExceptionGroup here from any reasonable usage, that I'd favor raise InternalTrioError from the_group.

Getting multiple exceptions from inside the nursery may be unlikely, but it seems relatively straightforward to pass a bad command that will get an exception from open_process - and we probably don't want to raise InternalTrioError in those cases. Pushing a commit with a suggested fix, but I suspect there might be a reason the open_process call was placed inside the nursery in the first place (?).

(the PermissionError in the test is raised inside open_process, and there's validation of inputs that run_process punts to open_process as well)

src/trio/_tests/test_subprocess.py

Co-authored-by: Zac Hatfield-Dodds <zac.hatfield.dodds@gmail.com>

jakkdl

Thorough rewrite of docs and an eventual DeprecationWarning for setting strict_exception_groups=False will have to wait for another PR. But other than uncertainty on messing with the nursery in open_process I think everything has been resolved.

src/trio/_subprocess.py

richardsheridan · 2024-01-11T16:00:12Z

I think this PR should just allow an EG to propagate without the TrioInternalError complication, and we should make a new issue for the desired semantics of deliver cancel and EGs from this function.

…

On Thu, Jan 11, 2024 at 10:56 AM John Litborn ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/trio/_subprocess.py <#2886 (comment)>: > - async with trio.open_nursery() as nursery: - # options needs a complex TypedDict. The overload error only occurs on Unix. - proc = await open_process(command, **options) # type: ignore[arg-type, call-overload, unused-ignore] - try: - if input is not None: - assert proc.stdin is not None - nursery.start_soon(feed_input, proc.stdin) - proc.stdin = None - proc.stdio = None - if capture_stdout: - assert proc.stdout is not None - nursery.start_soon(read_output, proc.stdout, stdout_chunks) - proc.stdout = None - proc.stdio = None - if capture_stderr: - assert proc.stderr is not None - nursery.start_soon(read_output, proc.stderr, stderr_chunks) - proc.stderr = None - task_status.started(proc) - await proc.wait() - except BaseException: - with trio.CancelScope(shield=True): - killer_cscope = trio.CancelScope(shield=True) - - async def killer() -> None: - with killer_cscope: - await deliver_cancel(proc) - - nursery.start_soon(killer) + # Opening the process does not need to be inside the nursery, so we put it outside + # so any exceptions get directly seen by users. + # options needs a complex TypedDict. The overload error only occurs on Unix. + proc = await open_process(command, **options) # type: ignore[arg-type, call-overload, unused-ignore] + try: + async with trio.open_nursery() as nursery: + try: + if input is not None: + assert proc.stdin is not None + nursery.start_soon(feed_input, proc.stdin) + proc.stdin = None + proc.stdio = None + if capture_stdout: + assert proc.stdout is not None + nursery.start_soon(read_output, proc.stdout, stdout_chunks) + proc.stdout = None + proc.stdio = None + if capture_stderr: + assert proc.stderr is not None + nursery.start_soon(read_output, proc.stderr, stderr_chunks) + proc.stderr = None + task_status.started(proc) await proc.wait() - killer_cscope.cancel() - raise + except BaseException: + with trio.CancelScope(shield=True): + killer_cscope = trio.CancelScope(shield=True) + + async def killer() -> None: + with killer_cscope: + await deliver_cancel(proc) + + nursery.start_soon(killer) + await proc.wait() + killer_cscope.cancel() + raise + except BaseExceptionGroup as exc: + if all(isinstance(e, Cancelled) for e in exc.exceptions): + raise exc + raise TrioInternalError("Error interacting with opened process") from exc but passing a bad deliver_cancel is indeed a very trivial way to get an EG atm, hrm. — Reply to this email directly, view it on GitHub <#2886 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5BHRSFUG6MZUZCYQQ72OLYOADULAVCNFSM6AAAAAA7ZNHN56VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTQMJVHEZDSMZZG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

richardsheridan · 2024-01-11T16:00:42Z

oh and I meant the nursery in _subprocess line ~771

…

On Thu, Jan 11, 2024 at 10:55 AM John Litborn ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/trio/_subprocess.py <#2886 (comment)>: > - async with trio.open_nursery() as nursery: - # options needs a complex TypedDict. The overload error only occurs on Unix. - proc = await open_process(command, **options) # type: ignore[arg-type, call-overload, unused-ignore] - try: - if input is not None: - assert proc.stdin is not None - nursery.start_soon(feed_input, proc.stdin) - proc.stdin = None - proc.stdio = None - if capture_stdout: - assert proc.stdout is not None - nursery.start_soon(read_output, proc.stdout, stdout_chunks) - proc.stdout = None - proc.stdio = None - if capture_stderr: - assert proc.stderr is not None - nursery.start_soon(read_output, proc.stderr, stderr_chunks) - proc.stderr = None - task_status.started(proc) - await proc.wait() - except BaseException: - with trio.CancelScope(shield=True): - killer_cscope = trio.CancelScope(shield=True) - - async def killer() -> None: - with killer_cscope: - await deliver_cancel(proc) - - nursery.start_soon(killer) + # Opening the process does not need to be inside the nursery, so we put it outside + # so any exceptions get directly seen by users. + # options needs a complex TypedDict. The overload error only occurs on Unix. + proc = await open_process(command, **options) # type: ignore[arg-type, call-overload, unused-ignore] + try: + async with trio.open_nursery() as nursery: + try: + if input is not None: + assert proc.stdin is not None + nursery.start_soon(feed_input, proc.stdin) + proc.stdin = None + proc.stdio = None + if capture_stdout: + assert proc.stdout is not None + nursery.start_soon(read_output, proc.stdout, stdout_chunks) + proc.stdout = None + proc.stdio = None + if capture_stderr: + assert proc.stderr is not None + nursery.start_soon(read_output, proc.stderr, stderr_chunks) + proc.stderr = None + task_status.started(proc) await proc.wait() - killer_cscope.cancel() - raise + except BaseException: + with trio.CancelScope(shield=True): + killer_cscope = trio.CancelScope(shield=True) + + async def killer() -> None: + with killer_cscope: + await deliver_cancel(proc) + + nursery.start_soon(killer) + await proc.wait() + killer_cscope.cancel() + raise + except BaseExceptionGroup as exc: + if all(isinstance(e, Cancelled) for e in exc.exceptions): + raise exc + raise TrioInternalError("Error interacting with opened process") from exc which nursery is "the nursery in question", the one in test_subprocess L591, or the one in _subprocess line ~771? If you're changing the former, you should get an EG, because it doesn't set the global contect of strict_exception_groups=False, so the one on 771 will use the default of True (in this PR). — Reply to this email directly, view it on GitHub <#2886 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5BHRU7YSAURZWUL4P4HADYOADOHAVCNFSM6AAAAAA7ZNHN56VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTQMJVHEZDKOJVHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

jakkdl · 2024-01-11T16:18:09Z

oh and I meant the nursery in _subprocess line ~771

huh, then I'm confused.

…it may raise exceptiongroup in docstring

jakkdl · 2024-01-11T17:29:01Z

oh and I meant the nursery in _subprocess line ~771

huh, then I'm confused.

I added a test which is doing what you described, afaict, and it's working as expected.

jakkdl · 2024-01-21T12:45:46Z

Any remaining semi-blockers have been cleared for this:

https://github.com/python-trio/trio/releases/tag/v0.24.0 was released with remove multierror #2891, and that has not seen much (any?) negative responses.
Exception semantics of run_process with strict_exception_groups #2923 seems to be settling down to preserving status quo of sometimes raising an ExceptionGroup in run_process

So I'll rebump review request from @A5rocks and/or @TeamSpen210. But unless @Zac-HD finds anything else on a re-review I think this can be merged.

Zac-HD

Looks great! Since this PR has been open and at times growing for two months, I'm going to merge, and open an issue for the docs followup mentioned above. Post-merge reviews entirely welcome; I suggest comments here if you want to discuss or just open an issue for some followup action if you spot something we should change further.

Huge thanks to @jakkdl for all your work on this, and to @A5rocks, @CoolCat467, @richardsheridan, and @TeamSpen210 for reviews 🤩 I'm really looking forward to getting this into production at work, and seeing the ecosystem improve handling of concurrent errors!

change strict_exception_groups default to True

cfc0755

jakkdl requested a review from Zac-HD November 24, 2023 17:38

get rid of the last vestiges of _assert_raises

84fb527

jakkdl force-pushed the remove_multierror branch from 14d23d1 to 84fb527 Compare November 24, 2023 17:43

agronholm mentioned this pull request Nov 24, 2023

Reinstate "collapse exception group" in TaskGroup exception handling agronholm/anyio#641

Closed

1 task

A5rocks reviewed Nov 25, 2023

View reviewed changes

Zac-HD reviewed Nov 27, 2023

View reviewed changes

This was referenced Nov 27, 2023

Cleanup of tests, and removal of _assert_raises #2890

Merged

remove multierror #2891

Merged

jakkdl added 3 commits November 28, 2023 18:06

Merge remote-tracking branch 'origin/master' into remove_multierror

c4548bd

fix check for @Final

2437d1e

add typeguard to ExpectedExceptionGroup.matches

dcadc87

This was referenced Dec 2, 2023

Allow pytest.raises cooperate with ExceptionGroups pytest-dev/pytest#11538

Open

Add RaisesGroup, a helper for catching ExceptionGroups in tests #2898

Merged

update comments/tests where I was confused about lack of ExceptionGro…

a39732f

…ups, and noted by reviewers

Merge branch 'master' into remove_multierror

669c345

pre-commit-ci bot and others added 2 commits December 13, 2023 20:58

[pre-commit.ci] auto fixes from pre-commit.com hooks

f7e0b8f

Fix ruff issues

38f47a5

jakkdl commented Dec 16, 2023

View reviewed changes

src/trio/_core/_tests/test_run.py Outdated Show resolved Hide resolved

jakkdl added 3 commits December 22, 2023 16:30

Merge remote-tracking branch 'origin/master' into remove_multierror

d455a45

and fix various errors, also disabling PT012.

Merge remote-tracking branch 'origin/master' into remove_multierror

4232be2

Note that this has *both* RaisesGroup and ExpectedExceptionGroup

replace all instances of ExpectedExceptionGroup with RaisesGroup

5caf49f

jakkdl commented Jan 7, 2024

View reviewed changes

gone through the whole PR and cleaned it up

f50386c

jakkdl commented Jan 7, 2024

View reviewed changes

jakkdl and others added 5 commits January 8, 2024 13:43

Apply suggestions from code review

26a9c62

Co-authored-by: Zac Hatfield-Dodds <zac.hatfield.dodds@gmail.com>

rephrase newsfragment, and add rst cross-references

a93a185

update docstrings

b3d5aa3

add comment with TODO about rewriting strict_exception_groups section

c00a05f

parametrize run/nursery strictness tests

4b393ed

jakkdl marked this pull request as ready for review January 8, 2024 14:02

jakkdl commented Jan 8, 2024

View reviewed changes

src/trio/_subprocess.py Outdated Show resolved Hide resolved

jakkdl requested review from A5rocks and TeamSpen210 January 8, 2024 14:14

jakkdl added 4 commits January 11, 2024 17:36

revert reraising exceptiongroup as a TrioInternalError, mention that …

e64d508

…it may raise exceptiongroup in docstring

Merge remote-tracking branch 'origin/master' into remove_multierror

0547313

fix test_run_process_internal_error, add test_bad_deliver_cancel

22e4765

fix docstring

79754b8

jakkdl mentioned this pull request Jan 11, 2024

Exception semantics of run_process with strict_exception_groups #2923

Closed

Merge branch 'master' into remove_multierror

506e211

CoolCat467 linked an issue Jan 19, 2024 that may be closed by this pull request

Exception semantics of run_process with strict_exception_groups #2923

Closed

jakkdl added 3 commits January 21, 2024 13:49

revert accidental removal of empty line

ea48cf0

Add a bunch of words to the newsfragment

3f519f8

Merge remote-tracking branch 'origin/master' into remove_multierror

0b45ec9

Zac-HD approved these changes Jan 22, 2024

View reviewed changes

Zac-HD merged commit e0d8edf into python-trio:master Jan 22, 2024
29 checks passed

Zac-HD mentioned this pull request Jan 22, 2024

Ensure that our docs present strict_exception_groups=True as the natural default #2929

Closed

jakkdl deleted the remove_multierror branch January 24, 2024 12:33

jakkdl mentioned this pull request Jan 31, 2024

add deprecation warning for specifying strict_exception_groups=False #2941

Merged

A5rocks mentioned this pull request Feb 19, 2024

Please switch to v1.0 and start using semantic version numbers #2961

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

change strict_exception_groups default to True #2886

change strict_exception_groups default to True #2886

jakkdl commented Nov 24, 2023 •

edited

Loading

codecov bot commented Nov 24, 2023 •

edited

Loading

jakkdl commented Nov 24, 2023

A5rocks left a comment

A5rocks Nov 25, 2023

Zac-HD Jan 8, 2024

Zac-HD left a comment

Zac-HD Nov 25, 2023

jakkdl Jan 8, 2024

Zac-HD Nov 25, 2023

Zac-HD Jan 8, 2024

jakkdl Jan 8, 2024

jakkdl Jan 8, 2024

jakkdl commented Dec 11, 2023 •

edited

Loading

CoolCat467 commented Dec 13, 2023

jakkdl commented Dec 14, 2023

jakkdl Jan 7, 2024

jakkdl left a comment •

edited

Loading

jakkdl Jan 7, 2024

Zac-HD Jan 8, 2024

jakkdl Jan 8, 2024

jakkdl Jan 8, 2024

jakkdl left a comment

richardsheridan commented Jan 11, 2024 via email

richardsheridan commented Jan 11, 2024 via email

jakkdl commented Jan 11, 2024

jakkdl commented Jan 11, 2024

jakkdl commented Jan 21, 2024

Zac-HD left a comment •

edited

Loading

		of ``TaskGroup`` in asyncio and anyio. This is also to avoid any bugs caused by only
		catching one type of exceptions/exceptiongroups.

		@@ -0,0 +1,2 @@
		``strict_exception_groups`` now defaults to True in ``trio.run`` and ``trio.start_guest_run``, as well as ``trio.open_nursery`` as a result of that.

	async def init(
	self,
	async_fn: Callable[[Unpack[PosArgT]], Awaitable[object]],
	args: tuple[Unpack[PosArgT]],
	) -> None:
	# run_sync_soon task runs here:
	async with open_nursery() as run_sync_soon_nursery:
	# All other system tasks run here:
	async with open_nursery() as self.system_nursery:
	# Only the main task runs here:
	async with open_nursery() as main_task_nursery:

change strict_exception_groups default to True #2886

change strict_exception_groups default to True #2886

Conversation

jakkdl commented Nov 24, 2023 • edited Loading

codecov bot commented Nov 24, 2023 • edited Loading

Codecov Report

jakkdl commented Nov 24, 2023

A5rocks left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Zac-HD left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jakkdl commented Dec 11, 2023 • edited Loading

CoolCat467 commented Dec 13, 2023

jakkdl commented Dec 14, 2023

Choose a reason for hiding this comment

jakkdl left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jakkdl left a comment

Choose a reason for hiding this comment

richardsheridan commented Jan 11, 2024 via email

richardsheridan commented Jan 11, 2024 via email

jakkdl commented Jan 11, 2024

jakkdl commented Jan 11, 2024

jakkdl commented Jan 21, 2024

Zac-HD left a comment • edited Loading

Choose a reason for hiding this comment

jakkdl commented Nov 24, 2023 •

edited

Loading

codecov bot commented Nov 24, 2023 •

edited

Loading

jakkdl commented Dec 11, 2023 •

edited

Loading

jakkdl left a comment •

edited

Loading

Zac-HD left a comment •

edited

Loading