@alexcjohnson Initial reaction is also that prevent_initial_callback != PreventUpdate. By setting prevent_initial_callback=True you are excluding these callbacks from the initial callback graph and effectively making follow up callbacks the initial ones.

As we want to conserve backward compatibility, we will want prevent_initial_callback=False to be the default. This raises the issue that once you set True for one callback it might be necessary for the app developer to set all other callbacks to True explicitly to avoid the runaway behavior described above. Would it be possible to add a global prevent_initial_callback as part of this PR. The callback parameter would then serve to override the global/default one as needed. Allowing full flexibility / minimal code changes from the app developer in all scenarios.

As we want to conserve backward compatibility, we will want prevent_initial_callback=False to be the default.

Absolutely.

Would it be possible to add a global prevent_initial_callback as part of this PR. The callback parameter would then serve to override the global/default one as needed.

That's a good idea, should be an easy add. I'd call the global one prevent_intitial_callbacks though.

If you do want C to fire and we automatically prevent it, you'd have to do something super hacky like add an extra input. On the other hand, if we allow it to fire and you don't want that, all you have to do is set prevent_initial_call=True on C as well.

Personally I also prefer that C should fire -- I can imagine why an app developer would want to take advantage of this, and if I understand correctly, this seems to be what a more experienced user of Dash would expect (outside of suspending initial execution of A and B) under the circumstances.

👍 That reasoning is sound to me

I also agree, I would expect C to fire unless explicitly silenced. I also think that this is a more advanced dash feature.
My use case did not involve callback chains so far, but was to silence callbacks for dynamic inputs (pattern matching) for performance reasons, e.g. if you dynamically add many inputs (several dozens) to the layout the app gets unresponsive for a few seconds because all callbacks are called.