Dash: [BUG] callbacks called in wrong order / too often

[maartenbreddels]

Hi plotly/dash people,

Great project, nicely designed.

Versions

dash                          1.0.1
dash-core-components          1.0.0
dash-html-components          1.0.0
dash-renderer                 1.0.0
dash-table                    4.0.1

Describe the bug

I created this demo of dash + vaex to interactively explore large datasets (150 million rows in this case):
https://github.com/maartenbreddels/dash-taxi-example

Talking to @alexcjohnson at glue-con, he suggested I use the Store, to avoid doing calculations when for instance I change between linear to log.

This seems to expose a bug, that I tried to isolate, but that didn't make it easier to digest.

I opened a PR here for that: https://github.com/maartenbreddels/dash-taxi-example/pull/2, which exposes the bug that I will try to describe.

This dash app shows a heatmap on the left containing the number of taxi trips. On the right, it shows the taxi trips per hour for the zoomed-in region and the total dataset:

Optionally, one can filter the month (not relevant now). When zooming in the heatmap, it should trigger a computation to update the heatmap and barchart.

Expected behavior

When I zoom in:

• update_limits callback should be called, which outputs to the limits store.
• update_data should now be called since it depends on limits, and it outputs to the data-heatmap store.
• update_figure_2d should be called after update_data, since it depends on the limits and data-heatmap store.
• update_figure_bar should be called as well (not relevant for the discussion).

Observed behaviour

Instead, what I see is that update_figure_2d is called before and after updata_data , as shown in the terminal output:

update_limits {'xaxis.range[0]': -73.80614443872746, 'xaxis.range[1]': -73.77961602289301, 'yaxis.range[0]': 40.6426960947285, 'yaxis.range[1]': 40.67774895854463}
update_figure_2d
updating data: limits [[-73.80614443872746, -73.77961602289301], [40.6426960947285, 40.67774895854463]]
update_figure_2d
update_figure_bars

This leads to a very bad user experience, as shown in this screen capture:

What happens in the screencapture is:

• I zoom in (and this is visually reflected in the browser, by the low res heatmap) and it also triggers the update_limits callback.
• This is followed by update_figure_2d (the one that shouldn't be triggered, only after update_data), which will update the figure, but with the new limits, and the old data. This is seen as the original heatmap, but shown at the zoomed in region.
• Now the update_data, followed by the second update_figure_2d is triggered, and the correct heatmap is shown.

This to me seems like a bug.

My workaround is to put all dependencies of update_figure_2d in the Store (as a list or dict), but this seems to go against the design of dash.

Regards,

Maarten Breddels

[alexcjohnson]

Thanks @maartenbreddels - I'll have to dive into your code in detail to figure out exactly what's going on. In general we do try to avoid calling a callback if it's just going to get called again after another callback returns, but perhaps you're hitting a case of this that we missed.

Related: https://github.com/plotly/dash/issues/635 (cc @slishak)

[audetto]

I think I've hit this same problem.

I have drop down which updates 2 separate components and they both feed into a 3rd.
The 3rd component is called with inconsistent data, then it is called again wit the correct data from the 2 code paths.

It is in the office and cant really take it out.

What was the results of the analysis for this issue?

[alexcjohnson]

Alright, took a while but I believe the reworked callback dispatch framework in #1103 resolves this issue. I'm not planning to include a specific test for this case as it's most likely covered by at least one of the tests for #1053, #1071, #1084 and #1105 🙄 but when I run your code from https://github.com/maartenbreddels/dash-taxi-example/pull/2 off the 475-wildcards branch I only see a single update of the graph.

[maartenbreddels]

Really happy to see this fixed! Hope we can try it out soon.