Callback order resolution issue when using multi-outputs?

Hi,

I believe I’m experiencing a bug in the resolving of the callback chain order. Possibly pertinent is that the issue is coming from a component which is receiving a multi-output, and then multiple of those outputs become inputs to the subsequent component callback in the chain.

Are there any know issues with callback chain resolution when using multi-ouputs -> multi-inputs? Or anyone else experienced issues?

Thanks.
p.s. the multi-output is awesome obvs :slight_smile:

1 Like

Details on my possible bug/issue:
Below you can see the callback graph, and a screencap of the logs from the app.
The timeseries element is updated by set_graphs callback (present in logs). I think that it shouldn’t fire until all the values that it takes as inputs (as seen in the callback graph) have successfully been set by their preceding callbacks. Yet set_graphsis called before set_date_picker_attributes (the callback from app_start_trigger component and date_picker_range), and thus you get the log that the values of start_dt and end_dt in set_graphs are both None - causing an error. This error on appears on the initial load of the app, and everything works correctly after that (i.e. once start_dt and end_dt having been set).

This seems like a callback order resolution error to me, - set_graphs should wait until set_date_picker_attributes has returned - but as always could just be a user (me) error!

Any thoughts appreciated.


1 Like

I’ve seen this error as well sometimes. I should probably do more than just put a band-aid on it…but I just figure if my other checks (making sure the trigger value doesn’t trigger functions before it exists, etc.) don’t work, it’s something to do with threads. So I just add

if my_val == None:
    raise PreventUpdate
    # or
    return ... , no_update ...

to function calls that are affected.

I use the same band-aid :slight_smile: Thanks for corroborating the issue and similarly for a possible mitigation of it.

1 Like