Set progress no update

[leeagustin]

Fixes #2846.

While I wasn't able to replicate the error from the issue, I did find that set_progress((no_update, str(total))) sets the progress to 0:

This is because the progress bar's value is being set to "[object Object]", which is probably being interpreted as 0. The progress bar's HTML being: <progress id="progress_bar" value="[object Object]" max="5" style="visibility: visible;"></progress>.

I modified it so that if set_progress has no_update for a component's output, that component will not be updated, but the other components—assuming they are not no_update—will be updated.

Contributor Checklist

• I have broken down my PR scope into the following TODO tasks
  • Allows for no_update in background callback set_progress
• I have run the tests locally and they passed. (refer to testing section in contributing)
• I have added tests, or extended existing tests, to cover any new features or bugs fixed in this PR

optionals

• I have added entry in the CHANGELOG.md
• If this PR needs a follow-up in dash docs, community thread, I have mentioned the relevant URLS as follows
  • this GitHub #PR number updates the dash docs
  • here is the show and tell thread in Plotly Dash community

[T4rk1n]

Might be better to change this to lock to make sure it's not reset.

[leeagustin]

I'm assuming you meant to write look instead of lock. Would 7437e2b work?

The final results for this test (tests/integration/long_callback/test_basic_long_callback014.py) would be:

• Using dev
  
• Using this PR
  

In dev, the #progress-counter is 3 because the value gets incremented every time set_progress is called, but it's correctly being left as 2 with this PR's changes.

As for why #progress-output is set back to start in dev, I am not sure 🤔. However, it's correctly being left as stop in this PR.

[alexcjohnson]

I think @T4rk1n was referring to multiprocessing.Lock, which you can find in some of the other Dash tests. This can remove the need for any explicit sleep statements, which not only makes the tests faster but also more robust on CI where you never know what else is running on the same hardware and can lead to unexpected delays that will intermittently break tests based on sleep.

[T4rk1n]

Yes, I was talking about a multiprocessing.Lock.

Basically you would do in the callback

with lock:
    set_progress(no_update)

Then in the test you can also request the lock and do the assertions, so you can be sure the call to set_progress is done before the assertions.

[leeagustin]

Ohh I see, that makes sense. I added the lock in 21bc4b2 🔒

[gvwilson]

one question about style but otherwise good to go

[gvwilson]

should we pull 0.5 out into a setting somewhere, or is it unlikely to ever change?