@Marc-Andre-Rivet this PR appears to MOSTLY fix the issue @bpostlethwaite encountered 🎉 🏆 🍹

Would you mind including the app below (and its corrected behavior) as a test case?

The premise: when prop A affects prop B, and both of them affect prop C, then the C callback should list both A and B as triggers. In the app below, there are in fact two primary inputs (A and A') affecting B, and the important thing - the reason we care about having both inputs appear as triggers - is for C to know whether it was A or A' that caused the callback to fire.

Ben's problem: only B was being listed as a trigger.

What I see on this branch:

• On initial load, only B seems to be a trigger, when it should be all three: A, A', and B. But I bet Ben doesn't care about this case ;)
• Later on, when the user changes A, both A and B appear as triggers 🎉

Here's Ben's app:

import dash
import dash_core_components as dcc
import dash_html_components as html
from dash.dependencies import Input, Output


app = dash.Dash(__name__)
app.layout = html.Div(
    [
        html.Div(
            style={"display": "block"},
            children=[
                html.Div(
                    [
                        html.Label("ID: input-number-1"),
                        dcc.Input(id="input-number-1", type="number", value=0),
                    ]
                ),
                html.Div(
                    [
                        html.Label("ID: input-number-2"),
                        dcc.Input(id="input-number-2", type="number", value=0),
                    ]
                ),
                html.Div(
                    [
                        html.Label("ID: sum-number"),
                        dcc.Input(
                            id="sum-number", type="number", value=0, disabled=True
                        ),
                    ]
                ),
            ],
        ),
        html.Div(
            id="results",
            style={
                "border": "antiquewhite",
                "borderStyle": "dashed",
                "height": "200px",
                "width": "475px",
            },
        ),
    ]
)


@app.callback(
    Output("sum-number", "value"),
    [Input("input-number-1", "value"), Input("input-number-2", "value")],
)
def update_sum_number(n1, n2):
    return n1 + n2


@app.callback(
    Output("results", "children"),
    [
        Input("input-number-1", "value"),
        Input("input-number-2", "value"),
        Input("sum-number", "value"),
    ],
)
def update_results(n1, n2, nsum):
    ctx = dash.callback_context
    return [
        "{} + {} = {}".format(n1, n2, nsum),
        html.Br(),
        "ctx.triggered={}".format(ctx.triggered)
    ]


if __name__ == "__main__":
    app.run_server()

@alexcjohnson Dash version breakdown of callback context

Dash v1.5.0 to Dash v1.10.0 (pre PMC)
[{'prop_id': 'input-number-2.value', 'value': 0}]
[{'prop_id': 'sum-number.value', 'value': 0}]

Dash v1.11.0 and above
[{'prop_id': '.', 'value': None}]
[{'prop_id': 'sum-number.value', 'value': 0}]

After discussion, having initial callbacks without predecessors have no context feels like what was desired (triggered neither by user action of another callback). Callbacks with predecessors (e.g. sum-number.value above) will have triggers corresponding to the input props that got updated in previous callbacks. The Dash v1.11.0+ behavior will be locked in with a test and be considered the desired behavior.

@alexcjohnson Wondering why we override the "no trigger context" case with https://github.com/plotly/dash/blob/dev/dash/_callback_context.py#L31

After discussion, having initial callbacks without predecessors have no context feels like what was desired (triggered neither by user action of another callback).

Yep right, I was forgetting this behavior is exactly what we decided during the original callback refactor back in #1103 - so as of this PR we can consider Ben's issue completely resolved.

Wondering why we override the "no trigger context" case with https://github.com/plotly/dash/blob/dev/dash/_callback_context.py#L31

See this discussion #1103 (comment) and response #1103 (comment) for the backward compatibility concerns that prompted this.

This test-27 failure is interesting - seems plausible that one of the callback invocations was aborted before being requested because another keystroke came in first, which isn't a bad thing at all. Which means if we even want to keep this assertion maybe we just loosen it?