Close #188: skip cleanup when inside an ExtendedTask

Author: cpsievert

CHANGELOG.md

@@ -5,6 +5,10 @@ All notable changes to shinywidgets will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [UNRELEASED]  - 2025-04-04
+
+* Constructing a widget inside of a `shiny.reactive.ExtendedTask()` no longer errors out. (#188)
+
 ## [0.5.1] - 2025-01-30
 
 * Fixes 'AttributeError: object has no attribute "_repr_mimebundle_"'. (#184)

shinywidgets/_shinywidgets.py

@@ -168,7 +168,14 @@ def on_close():
                 if id in WIDGET_INSTANCE_MAP:
                     del WIDGET_INSTANCE_MAP[id]
 
-        ctx.on_invalidate(on_close)
+        # This could be running in a shiny.reactive.ExtendedTask, in which case,
+        # the context is a DenialContext. As a result, on_invalidate() will throw
+        # (since reading/invalidating reactive sources isn't allowed in this context).
+        # For now, we just don't clean up the widget in this case.
+        # TODO: this line can likely be removed once we start closing iff we're in a
+        # output context (see TODO comment above)
+        if "DenialContext" != ctx.__class__.__name__:
+            ctx.on_invalidate(on_close)
 
     # Keep track of what session this widget belongs to (so we can close it when the
     # session ends)
@@ -208,6 +215,7 @@ def on_close():
 # Reactivity
 # --------------------------------------
 
+
 def reactive_read(widget: Widget, names: Union[str, Sequence[str]]) -> Any:
     """
     Reactively read a widget trait
@@ -273,6 +281,7 @@ def _():
 
     return w
 
+
 # Previous versions of ipywidgets (< 8.0.5) had
 #   `Widget.comm = Instance('ipykernel.comm.Comm')`
 # which meant we'd get a runtime error when setting `Widget.comm = ShinyComm()`.
@@ -300,6 +309,7 @@ def is_traitlet_instance(x: object) -> "TypeGuard[Instance[Any]]":
         return False
     return isinstance(x, Instance)
 
+
 # It doesn't, at the moment, seem feasible to establish a comm with statically rendered widgets,
 # and partially for this reason, it may not be sensible to provide an input-like API for them.