mo.stop propagation breaks

[dmadisetti]

Describe the bug

I'm not able to replicate this without sharing my notebook.

It's a pretty large notebook. I have a stop that should effectively stop the whole notebook, but I start getting name errors at some point since the stop doesn't propagate as far as it should.

Name error for projections

The cell that defines projections

Rerunning the stop cell then works! It feels like maybe a race condition somewhere

Environment

0.6.11

Code to reproduce

Large notebook with many parts, since stop condition that should halt everything. Restarting my notebook kernel reliably triggers the incorrect name errors

[dmadisetti]

OK- I think it's because I reference UI elements in the "stopped" code, which triggers a rerun on load. Found 2 bugs:

1. Stop doesn't stop
2. Stop doesn't resolve deps when UI element is present.

Replication with much smaller notebook:

https://marimo.app/l/6joyrm

I'm not using refresh, but I do have some interdependent UI elements that I think end up triggering change

[akshayka]

I think a fix could be to not run a cell if any of its ancestors are stopped.

We do this with disabled cells, but not for stopped cells.

[dmadisetti]

I think "stop" itself is fine, but something is up with resolving the dependency graph. In the example I gave, marimo should have realized that a is not accessible and not tried to run the cells. Also, b is not accessible because a is not accessible.

I think more aggressive checking of refs could solve this. Here's a silly example that shows how the dep, ref checking is a little broken (beyond stop):

https://marimo.app/l/tq20qa

---

edit: Yes, this is a special weird case, but I think it shows lack of guards that would catch the stop case as well

[akshayka]

I think more aggressive checking of refs could solve this. Here's a silly example that shows how the dep, ref checking is a little broken (beyond stop):

What would you expect refs and defs to be in your example?

[dmadisetti]

I would expect it not to run. Maybe throw an "Unsatisfable context" or even "This cell is in a cycle: cell-0 -> x -> cell-0".

because even in this case (similar to the original example): https://marimo.app/l/pdym22

marimo doesn't check to see if x exists, just that the cell that declares the def has run. It should check:

• the variable exists
• the cell has run
• the cell is not "stopped."

Right? I don't know—these are weird edge cases, but I think they might surface in cases like we're seeing with stop. A sloppy "except all" could also make this pop up.

Or maybe this is getting unrelated to the stop issue (I can open another issue)

---

edit, simpler case

Even without exceptions, you can do something like:

if False:
    b = 12
mo.defs()

Which is fine by itself (I think), but trying to use b in another cell should raise an error (beyond the NameError)

[mscolnick]

@dmadisetti is this good to close now with this https://github.com/marimo-team/marimo/pull/1580 (again, awesome work!)

[akshayka]

I think this can be solved for the "relaxed" runtime too, without the machinery of strict.

[dmadisetti]

Closing out, because I had a notebook that seems to pretty reliable trip this, but doesn't anymore :tada: