You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm aware that this is an edge case, but it's something we believe should be documented (and eventually fixed) in case someone runs into a similar issue.
The general recommendation would be to choose between @app.callback and @callback to use consistently across the app, even though combining them sometimes works, like in the following case:
any callback defined with @callback will not work. Every callback defined with @app.callback will still work.
The code for the video app is at the end of this message.
Screen.Recording.2025-08-28.at.12.21.57.mov
Defining duplicate callbacks like this is wrong according to the documentation. However, instead of this "all @callbacks not working" behaviour, we should see a "duplicate output warning" (see next section for more details).
Variations of the issue:
The order in which the @app.callback and @callback callbacks are defined for the duplicate output doesn't affect the occurrence of the issue (it happens either way).
If prevent_initial_call=True is not specified for (at least) @app.callback (the one with the duplicate output), the expected error will be raised:
dash.exceptions.DuplicateCallback: The callback `div1.children` provided with `dash.callback` was already assigned with `app.callback`.
However, if prevent_initial_call=True is specified for @app.callback and not for @callback (the ones for the duplicate outputs), the issue will still occur, i.e. no error will be raised.
If both callbacks are defined with @callback or @app.callback, the (expected) error appears in the debug menu. The app is loaded but no callback (not even the ones defined with @app.callback work:
Screen.Recording.2025-08-28.at.13.26.45.mov
If the callbacks are defined as the docs specify, with prevent_initial_call=True and allow_duplicate=True, like this, every callback will work (no matter if they are defined with @callback or @app.callback`):
I'm aware that this is an edge case, but it's something we believe should be documented (and eventually fixed) in case someone runs into a similar issue.
The general recommendation would be to choose between
@app.callbackand@callbackto use consistently across the app, even though combining them sometimes works, like in the following case:Description of the issue
If we have something like this in the code:
any callback defined with
@callbackwill not work. Every callback defined with@app.callbackwill still work.The code for the video app is at the end of this message.
Screen.Recording.2025-08-28.at.12.21.57.mov
Defining duplicate callbacks like this is wrong according to the documentation. However, instead of this "all @callbacks not working" behaviour, we should see a "duplicate output warning" (see next section for more details).
Variations of the issue:
@app.callbackand@callbackcallbacks are defined for the duplicate output doesn't affect the occurrence of the issue (it happens either way).prevent_initial_call=Trueis not specified for (at least)@app.callback(the one with the duplicate output), the expected error will be raised:prevent_initial_call=Trueis specified for@app.callbackand not for@callback(the ones for the duplicate outputs), the issue will still occur, i.e. no error will be raised.The last two points mean that:
@callbackwill not work.If both callbacks are defined with
@callbackor@app.callback, the (expected) error appears in the debug menu. The app is loaded but no callback (not even the ones defined with@app.callbackwork:Screen.Recording.2025-08-28.at.13.26.45.mov
If the callbacks are defined as the docs specify, with
prevent_initial_call=Trueandallow_duplicate=True, like this, every callback will work (no matter if they are defined with@callbackor @app.callback`):Expected behavior
Any case where callbacks with duplicate outputs are defined incorrectly should raise the below exception or an error in the debug menu:
So these two cases (and potentially more) should raise the exception:
Code to reproduce the issue
dash==3.2.0