Skip to content

[BUG] callbacks called in wrong order / too often #832

Closed

Description

@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: maartenbreddels/dash-taxi-example#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:
image

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:
screencapture-bug

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

Activity

  1. alexcjohnson commented on Aug 1, 2019

    @alexcjohnson
    Collaborator

    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: #635 (cc @slishak)

  2. audetto commented on Jan 29, 2020

    @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?

  3. alexcjohnson commented on Mar 6, 2020

    @alexcjohnson
    Collaborator

    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 maartenbreddels/dash-taxi-example#2 off the 475-wildcards branch I only see a single update of the graph.

  4. maartenbreddels commented on Mar 6, 2020

    @maartenbreddels
    Author

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

  5. added this to the Dash v1.11 milestone on Mar 11, 2020
  6. added a commit that references this issue on May 28, 2021
  7. added a commit that references this issue on Jul 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions