Hi @Filip_Pejsa,
One option is to trigger your filter recipe from a scenario, and make sure to poll to check if the scenario is already running, and wait to trigger the current scenario run once you know that the scenario is not currently running.
I am attaching an example project that includes a webapp that triggers a scenario, only once the scenario is not already running. You can import this project and try it out by going to +New Project > Import project. This approach should work well for you if the recipe runs fairly quickly and you simply want to ensure that concurrent runs never occur. For this approach, you could simply pass your filter_user variable to a project variable (since the scenario will never run concurrently),and you'll set the variable prior to triggering your scenario:
import dataiku
client = dataiku.api_client()
project = client.get_default_project()
filter_user = dataiku.api_client().get_auth_info_from_browser_headers(request_headers)
['assocatedDSSUser']
project.update_variables({'user': filter_user})
You can then use the variable in your filter recipe. My example is of a Flask webapp, and I know you are using a Dash webapp, but you can likely implement similar logic in the Dash webapp.
One other option would be to generate a copy of the filter recipe through the Python API each time that the user triggers the webapp, setting the user as a recipe variable in the "newly created recipe". Your webapp can then run the "duplicated" recipe and destroy the duplicated recipe each time the webapp is used. This would allow you to always generate separate recipe runs from the webapp each time it's called, and you would never have to worry about concurrency. I am also happy to provide a code sample of this approach if you are interested in this approach instead.
Let me know what you think about these approaches and if you have any questions.
Thanks,
Sarina
