Add a tasks manager status for plugins actions and napari processes #8211

dalthviz · 2025-08-13T17:41:23Z

References and relevant issues

Supersedes #6993
Related to napari/napari-plugin-manager#174
Part of napari/napari-plugin-manager#53

Description

Add functionality to allow plugins and napari itself to register and handle tasks status as a way to provide a GUI to inform users that there are tasks in progress while closing napari

Preview

Warning dialog
General behavior:

codecov · 2025-08-13T19:22:10Z

Codecov Report

❌ Patch coverage is 97.34513% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 93.05%. Comparing base (2554b31) to head (e4eea2e).
⚠️ Report is 9 commits behind head on main.

Files with missing lines	Patch %	Lines
src/napari/utils/task_status.py	95.31%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8211      +/-   ##
==========================================
+ Coverage   92.98%   93.05%   +0.06%     
==========================================
  Files         703      705       +2     
  Lines       63365    63474     +109     
==========================================
+ Hits        58920    59063     +143     
+ Misses       4445     4411      -34

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

jaimergp · 2025-08-20T11:10:01Z

src/napari/utils/task_status.py

+    _tasks: dict[uuid.UUID, TaskStatusItem]
+
+    def __init__(self) -> None:
+        self._tasks: dict[uuid.UUID, TaskStatusItem] = {}


Any concerns about concurrent access here? Would it be better to have a Queue of small dataclasses that bundle the uuid and the status?

For the moment not much since to add and update an item uuids are being used and I think the only point where this dict gets iterated is when calling is_busy, get_status and cancel_all (logic that currently only gets triggered when wanting to close the whole app which I think is a point where not other task can get added? 🤔). However, if using a queue to handle the addition of tasks still makes sense let me know!

Fair enough. I'll let others chime in in case they share these concerns, but for now a comment would suffice. Something along the lines "note we are using a dict here that may not be thread-safe; however given the XXX conditions, it should be ok as long as we only perform XXXX tasks in XXX endpoints".

jaimergp · 2025-08-20T11:12:39Z

src/napari/utils/task_status.py

+class Status(StringEnum):
+    PENDING = auto()
+    BUSY = auto()
+    DONE = auto()
+    CANCELLED = auto()
+    FAILED = auto()


This is also present in https://github.com/napari/napari-plugin-manager/pull/174/files#diff-845746c74ed93a04bf7677b33b197c4a3086400268ab1f18e2223e6c73730ea7R66 (as a fallback?). Same comments apply.

Yep, over napari-plugin-manager a sort of fallback of this enum is in place. Over the comment there, I left this comment regarding the match between different scenarios and the statuses: napari/napari-plugin-manager#174 (comment)

Note: This enum should be updated following the discussion at napari/napari-plugin-manager#174

…urrency concerns

TimMonko

Cursory review of the code looks good to me.
Functionality I definitely approve of.
This requires the napari-plugin-manager PR, correct? If so, we need to make a plugin-manager release and update pins after this is merged.
Also, is this task status something we can expose to public API / document for this reason? That way someone could have a plugin tell napari that its busy doing some process, and for this dialog to show (especially important if they use multi-threading for their plugin) on close. I think that's what you intend here, so I'd love to see a follow-up in docs, and maybe a suggested blurb that we can add to release notes highlights.

TimMonko · 2025-08-26T16:58:28Z

src/napari/_qt/qt_main_window.py

+        task_status = task_status_manager.get_status()
        if (
+            task_status
+            and ConfirmCloseDialog(
+                self,
+                close_app=False,
+                extra_info='\n'.join(task_status),
+                display_checkbox=False,
+            ).exec_()
+            != QDialog.Accepted
+        ) or (


Just confirming that this means the tasks busy dialog box will always be shown regardless of the user's preference to show the warning on a regular close

Yep, as long as there are tasks with a PENDING or BUSY status the dialog asking to confirm the application close (with a description of the tasks being processed) will be shown

And it means that it is shown even if action is connected to another napari window?

If the napari windows are in the same process I think they could end up sharing the task manager instance indeed 🤔 It is possible to have multiple napari windows launched from the same process? Do you have a code snippet I could use to check this?

Note: the multiple_viewers_.py is an example of this possibility

dalthviz · 2025-08-26T17:22:41Z

This requires the napari-plugin-manager PR, correct?

To be able to see the behavior described in the OP yes!

Also, is this task status something we can expose to public API / document for this reason?

I would say so 👍

Czaki

Hm. In the context of examples. I still think that we should add somehow the teardown to the examples. Either in the script or in a separate script that matches the file name.

Without this, we need to make a PR to docs too.

Czaki · 2025-09-10T11:01:23Z

src/napari/_qt/qthreading.py

+        cancel_callback=worker.quit,
+    )
+    worker.started.connect(
+        lambda: update_task_status(


Partial?

In general, connecting lambda to signals is not a best practice, and we may think how to avoid it in codebase to not inspire other devs.

src/napari/utils/task_status.py

Czaki · 2025-09-10T12:00:08Z

src/napari/_tests/test_examples.py

+    monkeypatch.setattr(
+        ConfirmCloseDialog,
+        'exec_',
+        lambda *args: ConfirmCloseDialog.DialogCode.Accepted,
+    )


I prefer to patch get_status as it will close the path triggered by the update from this PR and not hide other problems.

Co-authored-by: Grzegorz Bokota <[email protected]>

…pecific examples instead. Add partial usage when connecting with worker signals

dalthviz · 2025-09-16T17:14:28Z

I think this is ready for another review @Czaki , let me know if there is something else to do here!

brisvag · 2025-09-23T10:13:01Z

@Czaki do you think this is close enough to go in by the end of the week? Otherwise, we'll have to postpone to the next release.

Czaki · 2025-09-23T16:04:25Z

examples/fourier_transform_playground.py

+# prevent showing `ConfirmCloseDialog` even when there are task being done
+# needed to prevent napari CI (tests and docs building) from getting stuck
+def no_status():
+    return []
+
+task_status_manager.get_status = no_status


I don't like this. It shows patching of internals in a bad way...

Another approach that occurs to me is to add some sort of kwarg to the thread_worker decorator to prevent registration of the task and use it for the examples 🤔 Does that make sense to you? If you have any other idea let me know!

My idea.

In a separate PR, modify the Viewer.close and Viewer.close_all methods to accept the force argument. It will disable all questions about closing.

Modify docs conf to use Viewer.close_all(force=True)
https://github.com/napari/docs/blob/00aefd3a7b9134f72e296a5d15f1cbbcf0e7b473/docs/conf.py#L368

Come back to this PR and reimplement the check to don't ask questions on force quit.

If you implement 1. I will review it and merge fast.

I would also support this change to viewer.close and close_all

Thanks for the idea @Czaki ! However, while implementing it, I noticed that it is not necessary to do changes to the viewer.close and viewer.close_all methods! Seems like those methods already have the capability to close things without showing the confirm dialog even when the option to show it is enabled. What was missing here, and I just noticed while checking the validation logic to add the force flag 😅, is to take into account the event.spontaneous() value. If that value is used also over the task status check no dialog will be shown. Last commit takes into account that and seems like it makes possible for the docs and the tests to run without showing the confirm dialog (no need to patch anything over the tests either) 🎉

Anyhow, let me know if that is good enough or if we should actually go with the force flag idea (and probably recheck the usage of the event.spontaneous() value as well as give a general check to the window close logic)

Czaki · 2025-09-23T16:11:42Z

src/napari/utils/task_status.py

+            item.cancel()
+
+
+task_status_manager = TaskStatusManager()


I do not have a feeling like introducing this as a part of the public API with a global variable does not feel like a proper solution.

So if I'm understanding correctly, having this as module constant doesn't feel appropiate, right? Maybe is better to instanciate a task manager per window? That makes sense to me (and more if it is possible to launch multiple napari windows at the same time from the same process) but let me know what you think!

Yes. It is possible to launch multiple napari windows in one process. And when providing such a public API, it needs to be ready for a multi-window environment.

We may introduce some private API for the meantime if we want to iterate over to provide a solution.

There is no need to provide a public API for such a feature at the beginning. And even possible future API may be functional.

Czaki · 2025-09-23T16:12:45Z

src/napari/_qt/qt_main_window.py

+        task_status = task_status_manager.get_status()
        if (
+            task_status
+            and ConfirmCloseDialog(
+                self,
+                close_app=False,
+                extra_info='\n'.join(task_status),
+                display_checkbox=False,
+            ).exec_()
+            != QDialog.Accepted
+        ) or (


And it means that it is shown even if action is connected to another napari window?

…pdate calls to register/update task status

…e without showing confirm close dialog with task status info

brisvag · 2025-09-25T07:33:56Z

Is there already a docs PR to update the docs with this feature?

dalthviz · 2025-09-25T14:43:52Z

While working on the force flag approach I noticed that no other change besides the latests ones in this PR are need so I did not create a docs PR or any other PR in the napari side of things (full explanation: #8211 (comment)). Basically, with the latest changes here, the confirm dialog doesn't show when running the test or the examples (including when those are run when building the docs) :)

Edit: Or maybe you meant like adding some docs explaining that now the napari window has methods to register task status (_register_task_status and _update_task_status)? 🤔 In the current state of this PR technically no public API is available but let me know if making those methods public (and then adding some info about them over the docs) could be worthy!

Czaki · 2025-09-25T15:00:20Z

Edit: Or maybe you meant like adding some docs explaining that now the napari window has methods to register task status (_register_task_status and _update_task_status)? 🤔

At least documentation that will explain that currently we register tasks executed by thread_worker. To explain to users what happened.

brisvag · 2025-09-25T15:11:20Z

What @Czaki said, but also I forgot we ultimately made the api private, so all good on that 💪 So we're good to approve here @Czaki?

Czaki · 2025-09-25T15:15:31Z

We may think about adding a public API. But I want this API to enforce providing to which viewer the thread is connected. Even if we do not use this information, we would like to use this in the future.

dalthviz · 2025-09-25T15:47:43Z

Here a PR over the docs repo adding a note about the workers task registration and the possibility of a confirm close dialog appearing if a worker is still running when closing the GUI via the window close button: napari/docs#851

@napari-bot

…ialog when closing napari GUI via close button (#851) # References and relevant issues  Depends on napari/napari#8211 # Description    Adds a note over the threading page (`Graceful exit` section) mentioning that starting with napari 0.6.5 workers get registered as task and a confirm close dialog is shown if they are still running when closing napari via the GUI close button   Co-authored-by: Lorenzo Gaifas <[email protected]>

imagesc-bot · 2025-10-02T11:45:18Z

This pull request has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/napari-v0-6-5-is-out/116715/1

goanpeca and others added 7 commits July 29, 2024 00:20

Check if plugin manager is busy on close

7198ede

Fix typing

433d298

Fix test

2a412dd

Add process status manager

3784987

Fix typing

3711c4c

Update API to include callbkacs and history of updates

cd5bb9c

Merge branch 'main' into enh/check-plugin-manager-on-close

fe708c5

dalthviz self-assigned this Aug 13, 2025

Fix typing

61643a4

dalthviz added 4 commits August 18, 2025 09:58

Merge branch 'main' into enh/check-plugin-manager-on-close

db40eb7

Update logic to trigger cancel tasks on close if needed

44192f5

Fix typing

11498c7

Add cancelled status. Add a test

dfa3c92

github-actions bot added the tests Something related to our tests label Aug 19, 2025

dalthviz added the enhancement label Aug 19, 2025

dalthviz mentioned this pull request Aug 19, 2025

Add logic to allow napari to know that plugin actions are being done napari/napari-plugin-manager#174

Open

dalthviz changed the title ~~[WIP] Add a tasks manager for plugins and napari processes~~ [WIP] Add a tasks manager status for plugins actions and napari processes Aug 19, 2025

dalthviz marked this pull request as ready for review August 19, 2025 18:24

dalthviz requested a review from a team as a code owner August 19, 2025 18:24

dalthviz changed the title ~~[WIP] Add a tasks manager status for plugins actions and napari processes~~ Add a tasks manager status for plugins actions and napari processes Aug 19, 2025

jaimergp reviewed Aug 20, 2025

View reviewed changes

Add comment about dict usage to hold task status information and conc…

619a6b5

…urrency concerns

TimMonko approved these changes Aug 26, 2025

View reviewed changes

TimMonko reviewed Aug 26, 2025

View reviewed changes

TimMonko added this to the 0.6.5 milestone Aug 26, 2025

Merge branch 'main' into enh/check-plugin-manager-on-close

5b01321

dalthviz changed the title ~~Add a tasks manager status for plugins actions and napari processes~~ [WIP] Add a tasks manager status for plugins actions and napari processes Aug 27, 2025

Czaki reviewed Sep 10, 2025

View reviewed changes

dalthviz and others added 2 commits September 10, 2025 11:05

Apply suggestions from code review

617474b

Co-authored-by: Grzegorz Bokota <[email protected]>

Remove test_examples monkeypatch and patch task status manager over s…

8f55526

…pecific examples instead. Add partial usage when connecting with worker signals

dalthviz requested review from lucyleeow, melissawm and psobolewskiPhD as code owners September 10, 2025 17:23

Merge branch 'main' into enh/check-plugin-manager-on-close

fb8473e

Merge branch 'main' into enh/check-plugin-manager-on-close

f191660

Merge branch 'main' into enh/check-plugin-manager-on-close

b76e8e8

Czaki reviewed Sep 23, 2025

View reviewed changes

dalthviz added 4 commits September 23, 2025 13:46

Revert changes to examples. Make task status manager per window and u…

ea7d4e8

…pdate calls to register/update task status

Some code cleanup

025e50a

Testing

77686ee

Revert track_status kwarg for worker creation. Allow programatic clos…

7f61ada

…e without showing confirm close dialog with task status info

dalthviz mentioned this pull request Sep 25, 2025

Add note about workers registration as tasks and close confirmation dialog when closing napari GUI via close button napari/docs#851

Merged

brisvag added the ready to merge Last chance for comments! Will be merged in ~24h label Sep 26, 2025

brisvag added 2 commits September 26, 2025 10:18

Merge branch 'main' into enh/check-plugin-manager-on-close

fbaa5df

Merge branch 'main' into enh/check-plugin-manager-on-close

e4eea2e

brisvag merged commit 36b84d0 into napari:main Sep 26, 2025
37 of 38 checks passed

github-actions bot removed the ready to merge Last chance for comments! Will be merged in ~24h label Sep 26, 2025

Uh oh!

Add a tasks manager status for plugins actions and napari processes #8211

Add a tasks manager status for plugins actions and napari processes #8211

Uh oh!

Conversation

dalthviz commented Aug 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

References and relevant issues

Description

Preview

Uh oh!

codecov bot commented Aug 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TimMonko left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dalthviz Aug 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dalthviz commented Aug 26, 2025

Uh oh!

Czaki left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dalthviz commented Sep 16, 2025

Uh oh!

brisvag commented Sep 23, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

brisvag commented Sep 25, 2025

Uh oh!

dalthviz commented Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

dalthviz commented Aug 13, 2025 •

edited

Loading

codecov bot commented Aug 13, 2025 •

edited

Loading

TimMonko left a comment •

edited

Loading

dalthviz Aug 26, 2025 •

edited

Loading

dalthviz commented Sep 25, 2025 •

edited

Loading