Callback is not registered, when multiple callbacks have the same output

[cserteGT3]

I'm having an issue, where two callbacks have the same output, but one of them is not registered.
Example code is below, tested with Dash v1.1.1, Julia 1.7.2 (on Windows).

With the below code running, I can click on button1, but it doesn't do anything. If I check the callbacks in the browser (using debug mode), button1 is not even on the graph, only button2 is shown.
If I change the order in the code, then button2 is not working, so my guess is, that the latest (in the code) is kept.
Should my concept (two callbacks with the same output chained to a new callback) even work or is that an edge case, that haven't been found yet?

I hope my description is understandable and my MWE is minimal enough. If not, I'm happy to provide any more details.

using Dash

app = dash()

dfc = [Dict("name" => "c$i", "id" => "c$i") for i in 1:5]
dfd = [Dict(("c$j"=> rand()) for j in 1:5) for i in 1:7]

app.layout = html_div() do
    html_h1("Test table"),
    dash_datatable(
        id="table",
        columns=dfc,
        data = dfd,
    ),
    html_button("button 1", id="button-1"),
    html_button("button 2", id="button-2"),
    html_div(id = "id-string", children=""),
    html_div(id = "id-string2", children="")
end

# button 1
callback!(
	app,
	Output("id-string", "children"),
	Input("button-1", "n_clicks")
) do buttonvalue
	return "Button 1: $buttonvalue."
end

# button2
callback!(
	app,
	Output("id-string", "children"),
	Input("button-2", "n_clicks")
) do buttonvalue
	return "Button 2: $buttonvalue."
end

# callback based on result of button2 and button1
callback!(
	app,
	Output("id-string2", "children"),
	Input("id-string", "children")
) do stringval
	return "Common button callback: $stringval"
end

run_server(app, "0.0.0.0", 8050, debug=true)

[alexcjohnson]

Hmm, ideally this should actually be an error - if it's passing silently that's a bug we should fix.

The way to handle a situation like this is to combine them into one callback https://dash.plotly.com/julia/advanced-callbacks#determining-which-input-has-fired-with-dash.callback_context

The reason for this is with multiple callbacks targeting the same output it's ambiguous what to do in certain cases, like when the page initially renders - which callback should we fire?

[cserteGT3]

Hmm, ideally this should actually be an error - if it's passing silently that's a bug we should fix.

If you could provide some guidance on what to search for in the code, and we could define behaviours and testcases, I would happily look into it. I use Dash.jl only for personal projects, but so far I'm really happy with it and would happily contribute.

The way to handle a situation like this is to combine them into one callback https://dash.plotly.com/julia/advanced-callbacks#determining-which-input-has-fired-with-dash.callback_context

Thanks, I can do that. (Though in this particular case it doesn't matter which input -- which button -- has fired.)

The reason for this is with multiple callbacks targeting the same output it's ambiguous what to do in certain cases, like when the page initially renders - which callback should we fire?

In the case that is in my head: both should be fired. Maybe in their definition's order. But I see this problem only through my specific use-case, I can not really generalize the problem and solutions.

[alexcjohnson]

Hmm, looks like here:

Dash.jl/src/app/callbacks.jl

Lines 131 to 142 in 0a9e25f

	out_symbol = Symbol(output_string(deps))
	callback_func = make_callback_func!(app, func, deps)
	push!(
	app.callbacks,
	out_symbol => Callback(
	callback_func,
	deps,
	isnothing(prevent_initial_call) ?
	get_setting(app, :prevent_initial_callbacks) :
	prevent_initial_call
	)
	)

If out_symbol is the same for two callbacks, the second overwrites the first. We could have this throw an error. On the Python side we don't throw an error at this point; instead we push both callback definitions up to the browser so we can throw the error there. But it seems like that would require a bigger refactoring here so it probably isn't worth it.

[cserteGT3]

Thanks for the pointer! I'll open a MR in a day or two.