Allow Duplicate = True, How to determine Initial Duplicate?

I have a dash app with multiple pages, and have split my callbacks across multiple python files.

I’m getting “Duplicate callback outputs” error, despite having allow_duplicate=True on the necessary outputs for all but one.

  1. Will this callback without allow_duplicate=True automatically be the initial duplicate (which doesn’t take allow_duplicate=True, but still should have prevent_initial_call=True, as far as I understand)?
  2. If there is more going on behind the scenes to determine the initial callback, how can I see which order the callbacks are in, to determine which one is the initial one?


Hello @faulty13 and welcome to the forum!

Just in case you didn’t started from the documentation here is the link:

From my understanding if you use in your callback 5 times the sime id - prop combination you have to at least at 4 of them set allow_duplicate = True and prevent_initial_call = True at the callback. If you don’t set it in your 5th callback it will be the callback that get triggered in the initial run. Although you can also set prevent_initial_call = True at all of them. Then triggering of the callbacks will be only dependent on the inputs. And thats it :slight_smile:

Generally order of callback execution can be seen in the callbacks graf in console if the dabug = True mode is active.

Turns out that this was linked to this issue: [BUG] Duplicate callback outputs with identical inputs (and potentially different states) fail · Issue #2486 · plotly/dash · GitHub.

The issue was actually not with the outputs, but rather with the inputs. Dash generates the hash for the allow_duplicate outputs based on the input(s) (not the states) for a callback and based on what order the inputs are in. So, that was causing the issue. The workaround is to either switch the orders of the inputs wherever possible, or add a dummy input wherever necessary.


Thanks, this workaround helped in my case (adding dummy input) as I had three callbacks sharing same outputs (wasn’t an issue when I just had two callbacks sharing the same output)