Help debugging "Output data no longer available, please reevaluate this cell"

[venkatd]

Hi all!

I will intermittently get errors like so:

What typically causes these errors? I am trying to come up with a reproduction, but it doesn't seem to happen consistently. Sometimes re-evaluating works, sometimes refreshing the browser tab works, sometimes it doesn't.

I read a separate discussion (#1395) on this error but I don't believe I'm doing anything fancy with processes.

[jonatanklosko]

@venkatd on the screenshot the cell status is Aborted, so I expect the runtime is restarted or terminated? Certain outputs (including Kino.Tree) have data stored in the runtime, hence they become unavailable once the runtime is gone.

[jonatanklosko]

For the 1mln data points VegaLite, the message shown for a very brief moment, like a second. If you actually have case where this takes a longer time and eventually loads, it would be interesting to hear what data and component you are dealing with :D

[venkatd]

It's our own internal data component that is similar to `Kino.Tree.new. Admittedly we load a lot of data into it (some of them are strings).

We could potentially optimize this though.

Perhaps it could be replicated with a very large Kino.Tree?

[jonatanklosko]

Yeah, this:

data =
  Process.info(self())
  |> List.duplicate(5000)
  |> Map.new(fn x -> {System.unique_integer(), x} end)

Kino.Tree.new(data)

Currently Kino.Tree is static in the sense that all the data is built/formatted and sent to the client. Perhaps it should be Kino.JS.Live where subtrees are formatted on demand.

[venkatd]

I do think the loading indicator is worth adding just to avoid confusion in the case where, for whatever reason, things take a while to load.

I think formatting subtrees on demand is a good idea!

Actually our internal viewer is very close to Kino.Tree it started out as a copy/paste then we ended up rebuilding it. Maybe we can open source it some time.

Screenshot below:

It has a few improvements over Kino.Tree

• Allows you to navigate the data structure like it is a folder
• Search
• Some keyboard shortcuts to expand/collapse nodes
• Allow passing in an initial depth
• Read out the selected value

If I were to to optimize performance, roughly what I might do

• Convert the tree data structure to a flat list and store the depth of each row
• Use a library like tanstack virtual to virtualize the list (only nodes in view would get rendered)
• The javascript side can fetch rows on demand as you scroll

This would only be useful for large datasets, but we do have times where we need to inspect/navigate a very large data structure to debug something.

[jonatanklosko]

Looks pretty cool, especially the search :D