Anton Gilgur

> One concern is that it would be hard to cherry pick UI changes into patch releases. Git picks up on renames, so a change made to a renamed file...

> but a cherry-picked bugfix is unlikely to change an import path Fixed a few conflicts, and notably this still stands over a month later, the conflicts were all with...

> feat: [...] Please re-title this PR as a `fix:`, since per https://github.com/argoproj/argo-workflows/issues/12543#issuecomment-1900910489 this very much seems like a bug and not intended behavior

### `expr` built-in functions collision > I'm even convinced it worked on both 3.5.0 release candidates You are correct on that, `expr` was upgraded to [1.14](https://github.com/antonmedv/expr/releases/tag/v1.14.0) in [3.5.0-rc2](https://github.com/argoproj/argo-workflows/blob/master/CHANGELOG.md#v350-rc2-2023-09-20), and `split`...

If that's the case that 3.4.x worked with Argo variables overriding built-in functions, then it's possibly a regression in `expr`: that built-ins now have priority over added context variables?

Does `map` work in 3.5.0-rc2? Trying to pinpoint if it's `expr` 1.14 or 1.15 that has the regression

@terrytangyuan this seems more like a regression in `expr` that we should get fixed and include in 3.5.1 rather than a breaking change we should document

I was gonna file a bug report in `expr` (and potentially fix it myself) once I knew the [specific version](https://github.com/argoproj/argo-workflows/issues/12037#issuecomment-1771120689) with the regression

> We also don't know the full list of magic bad words we can no longer use. If I found two in one workflow, I imagine there's lots. I imagine...

> I suspect a commit in expr-lang introduced stricter type checking and this might have been the reason it worked in the past. > If this is the case, the...