Non-backward-compatible change in `:syn_registry.register_or_update/4`

[Denis Drobny]

Hello!
We were transitioning from syn on version 3.2.1, to version 3.3.0 but when rolling out the upgrade, we have noticed the following error originating in the nodes with the latest syn:

GenServer X terminating
** (CaseClauseError) no case clause matching: {:ok, {:on_process_registered, [_meta], _ts, :syn_registry_by_name, :syn_registry_by_pid}}
    (syn 3.3.0) /app/deps/syn/src/syn_registry.erl:119: :syn_registry.register_or_update/4
    (syn 3.3.0) /app/deps/syn/src/syn_registry.erl:87: :syn_registry.register/4
...

Similar error was reported by the nodes in the cluster that were running the previous version of syn:

GenServer Y terminating
** (CaseClauseError) no case clause matching: {:ok, {:on_process_registered, :undefined, [_meta], _ts, :syn_registry_by_name, :syn_registry_by_pid}}
    (syn 3.2.1) /app/deps/syn/src/syn_registry.erl:119: :syn_registry.register_or_update/4
    (syn 3.2.1) /app/deps/syn/src/syn_registry.erl:87: :syn_registry.register/4

The issue seems to be caused by the commit Add update callbacks with previous meta info, because now we might get a tuple of unexpected arity from the syn_gen_scope:call on both nodes (version 3.3.0 may get result in the shape {ok, {CallbackMethod, Meta, Time, TableByName, TableByPid}} which won't match and version 3.2.1 will fail to match if the second tuple contains the additional PreviousMeta).

Making the change backwards compatible should probably be as easy as adding an extra clause in the case statement that matches if the tuple is missing PreviousMeta and we can possibly get rid of this once releasing syn to a new major version.

However, to make upgrades smooth we would also need the change to be forward-compatible. That could have been achieved by returning a map instead of the tuple, therefore the old version could ignore the added key.
But for that it is probably too late, hehe.

Would it make sense to add the extra clause to handle tuples without PreviousMeta in order to at least mitigate the issue?
I'd be more than happy to help, of course!

Thanks for the library, it has been serving us very well:)

[Roberto Ostinelli]

Hello, thanks for this report. Mixed-Cluster Versioning isn't really supported, though very desirable.

What you are suggesting would fix errors seen on the nodes running 3.3.1 (to be released) but not those on 3.2.1, if I'm understanding what you are saying correctly.

My take on this would be to start having Mixed-Cluster Versioning from 3.3.0 onwards, i'm not sure I see a point in fixing a Mixed-Cluster Versioning issue only on one side of the equation. I already am tagging internal messages in the format {'3.0', ... to this effect, but never got around into finalizing a development that would guarantee Mixed-Cluster Versioning.

What do you think?

[Roberto Ostinelli]

Closing due to non-activity.