Anton Gilgur

> including the preceding PR #9790 > ``` > Error: Failed to execute 'pushState' on 'History': A history state object with URL 'https://archived-workflows/{{namepsace}}/87e895f1-50df-443b-971d-218beae9d25f' cannot be created in a document with...

Fixed in #13712 and should be released in the next 3.4 patch, 3.4.18

> I don't have any permissions to operate issues. Is there something wrong? @agilgur5 You pop up correctly as a "Member". Screenshot:  So...

> I actually meant that I think env variable `ARGO_TEMPLATE` should only be set in `init` container, and other containers should read it from the file `/var/run/argo/template` if needed. This...

> is this even supported ? No this shouldn't be supported or possible; I'm actually surprised it attempts to execute this. `script` and `container` are mutually exclusive as they are...

Hmm I think this proposal has a bit of an issue -- `maxInParallel` is defined on one Workflow in the example, but it can actually be defined on any Workflow....

> maxInParallel in this case could even be specific to the workflow for my usecase Hmm that is a slightly different use-case. That straddles in between the current `parallelism` feature...

Dynamic keys were also suggested in https://github.com/argoproj/argo-workflows/pull/7302#issuecomment-982917593

#13055 essentially proposed this too, but on a semaphore or mutex, which would obviate the need for selectors (although they are a k8s standard and quite powerful, they're usually used...

I stumbled upon @LinuxSuRen's [`argo-workflow-atomic-plugin`](https://github.com/LinuxSuRen/argo-workflow-atomic-plugin) today which looks like a user-land workaround for the `Replace` policy