The bug is passing string keys into business logic and not that the business logic expected atom keys, but you’re trying to change the latter instead of the first problem. User input (most often string keyed maps) should only ever land at a place where it’s Ecto.Changeset.cast or otherwise converted to an internal data structure. I would even say modifying those maps (e.g. add something to it) before “casting” to be a smell.

The other place for string keyed maps is if you need keys, which are user defined. But then your whole business logic needs to work with just string keys, because you never want to convert arbitrary user provided keys to atoms.

Exactly.

When I get input from the user, its usually that I validate it and typeconvert to elixir types as necessary. Then its either used for funcalls directly as bare value, or to create some other data. For what I have done so far, this other data is about 90% some struct that existed already before I decided to get some user input.

And in case of projects using ecto, well, at least 50% of them have a schema and a changeset function which makes validation/normalization very easy and straightforward.

Of course, sometimes other data structures make sense, then use it. And of course, if there are user provided relationships, just don’t use atom keys. But either way, deeper in your codebase nothing should access a map by a literal string, as either you know upfront what you expect or you don’t. And if you use a literal string, it feels as if you knew what you should get, but forgot to normalize. (And as always, there are exceptions to this “rule”, case by case)

I’ve only skimmed the implementation, but it seems as if it builds on a one-time creation of stringified/atomized counterkey with same value.

This seems to make things even worse…

One part of code updates atom key, another reads string key.

And even if you remember to re-key… Which should win if both exist?

The only solution are proper conversion to structs. No more arguing about string vs. atoms, just structs. Part of the contract, checked by dialyzer.

It really sounds like you trying to solve the wrong problem here.

Maybe a better thing is to take a few steps back and, look at why a developer would end up in this situation, in the first place; I feel like all of this can be solve by good design, but that is sometime harder than said.

This is not about that. It’s about introducing a module/structure that has an implicit and thus potentially surprising behaviour.

That’s hard because none of us can point you at our own production code, it’s all company trade secrets, you know. The “abstract” piece of advice you receive, you seem to be not impressed with so you’ll have to discover your own truths along the way.

As an anecdotal evidence, I have 10+ times successfully introduced big refactorings in Elixir code bases where the PR shows, say, 1650 lines added / 1280 lines removed and I still introduced zero bugs. I am not special or particularly amazing at programming though; good test suite and coding style consistency can and do work wonders, even in dynamic languages like Elixir.

You are aiming at the wrong problem. You can rework your code base to not rely on such arcane surprising mechanics and your project will be better for it. I’d argue the energy spent on such refactoring will end up being less than the energy put into making sure your surprise mechanics work well.

It seems you are dead-set on actually going forward with this though, so maybe all of us here trying to convince you to give it up are barking up the wrong tree.