[Feature Request] Ability to prevent newer background callbacks from cancelling older ones if desired

[michaelbabyn]

Is your feature request related to a problem? Please describe.
Currently new background callbacks cancel older ones updating the same output(s) but it would be great if this behaviour was optional. E.g if I have a large ag grid and groups for each row that contain a lot of data. I don't want to include all that data on page load so I'd like to load them only as a user expands them (and the individual row data still takes a while to load so I need BG callbacks).

At the moment if a user tries to expand a second group before the first one completes, Dash cancels the first update

Describe the solution you'd like
it would be great if there was a flag I could set in the callback decorator that prevented this

[Alex Johnson]

Thanks @michaelbabyn - this makes sense: the reason we have a later invocation of a background callback cancel an earlier one is that we won't use its result in the browser. But if the callback does something important server-side (running a job and saving the result, interacting with hardware, something like that) you likely still want these to complete even if another such action is triggered on top of it. By the same token, I could imagine wanting an explicit cancel action to trigger a cleanup action rather than simply terminating the job. But that's more speculative and could be dealt with separately.

Tricky to come up with a name for this that's both short and sufficiently descriptive - There's a similar setting on CircleCI that they label "Auto-cancel redundant workflows", so maybe either cancel_redundant=False or auto_cancel=False? Or we could invert this and say always_finish=True? Regardless it'll need some further explanation in the docstring. @michaelbabyn @T4rk1n any favorites or other name suggestions?

[michaelbabyn]

I like auto_cancel=False or allow_concurrent=True if we wanted to invert it

[arthur-FD]

Hi everyone,
Just to add a bit of context on the usecase that triggered this feature request.

We packaged our own version of ag grid, and we added a dash property to be able to leverage the transactions to update the aggrid table (https://www.ag-grid.com/javascript-data-grid/data-update-transactions/)
We display large table with very large number of rows, that are grouped - see below screenshot. To decrease the waiting time to display the data, we wanted to update the table every time the user open a group: it would trigger a callback, put it in a celery queue, fetch the data within the group and update the table.
The problem with this current approach is that if the user open an other group before the first callback finishes, it would just discard the first callback and onlty the second call will be successful.

So its actually important that the result of the callback is returned to the front-end.

Arthur