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 
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_graphs
is 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
Thanks for corroborating the issue and similarly for a possible mitigation of it.
1 Like