I tested....LGTM

The expected behavior I would expect is the "Before" one. If I ask for a result, it should be consistent, whatever page I navigate in between.

I would prefer a discussion on the mailing list to gather user feedback on this.

Shouldn't all output be captured? Is there a reason we want to clear it when the user navigates out? Perhaps I'm not fully understanding the behavior change?

Rebasing this on latest master should let current CI failure go.

Maybe the GIFs are not obvious enough :)

The PR is mainly trying to improve the rendering of the streaming capability introduced in #611.

So I will try to explain more in detail what is happening and how things work on the front-end side.

How It Works

First of all, its good to know that this is only a case for TEXT type of return values.

The way the back-end communicates data to the front-end end is through 2 different websocket events:

• PARAGRAPH_UPDATE_OUTPUT: Which remove previous result and replace it by the event content
• PARAGRAPH_APPEND_OUTPUT: Which add to the end of previous result

So for example, if we take this code:

(1 to 40).foreach{ i=>
    Thread.sleep(1000)
    println(i) 
}

It would send numbers from 1 to 40 with 1000ms interval, and this is what would happen:

- PARAGRAPH_UPDATE_OUTPUT (sent: "")

  -- PARAGRAPH_APPEND_OUTPUT (sent: "1")

  -- PARAGRAPH_APPEND_OUTPUT (sent: "2")

  -- PARAGRAPH_APPEND_OUTPUT (sent: "3")

  ...

- PARAGRAPH_UPDATE_OUTPUT (sent: "1/n2/n3/n......40")

So the way it works is that the job results are never persisted inside the Notebook before the end of the job.

The Current Problem

Since the temporary results are not persisted, whenever you navigate in and out of the Running Notebook, it will first reload the previous saved result in that paragraph.

So if you did run a loop through the ABC before, The paragraph will render that result.

Then you will receive some PARAGRAPH_APPEND_OUTPUT events from your running job, which will transform the result you see in your paragraph into something like:

A
B
...
Z
21 (PARAGRAPH_APPEND_OUTPUT)
22 (PARAGRAPH_APPEND_OUTPUT)
23 (PARAGRAPH_APPEND_OUTPUT)

Mainly because the flush of previous result (visually) was done in the PARAGRAPH_UPDATE_OUTPUT event at the beginning of the job.

What the PR achieve

In this PR, we try to clear the previous unrelated result of the paragraph when the paragraph receives an PARAGRAPH_APPEND_OUTPUT event for the first time in the Notebook, in order to keep result of that job only.

@felixcheung @echarles does that explain a bit better?

Ah that makes perfect sense, thanks for the detailed explanation.
LGTM.