fix: connect backoff mechanism

[filipecabaco]

What kind of change does this PR introduce?

Simple mechanism to prevent to many Connect processes from trying to startup in the same node.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
realtime-demo	⬜️ Ignored (Inspect)	Visit Preview		May 3, 2025 10:25am

[filipecabaco]

@supabase/dashbit it would be very useful to get some feedback from your side on lib/realtime/rate_counter/rate_counter.ex and lib/realtime/gen_counter/gen_counter.ex 🙏

[jonatanklosko]

Hey @filipecabaco!

I looked at the counter modules, I have two notes:

1. I noticed you use :erlang.phash2/1:
   

   realtime/lib/realtime/gen_counter/gen_counter.ex

   Line 36 in 5ddfbc5

   id = :erlang.phash2(term)

   
   This function isn't the best at generating unique values. It has 2^32 possible return values, which is relatively low for hashing. A typical usage of phash would be to deterministically assign value to a partition (in fact, phash2 accepts a second argument N, to cap the range). It is fair to expect collisions are very much possible.

   What you could do is lookup by phash2, but handle a case where there are multiple results and filter those based on the exact keys. That said, as long as you use simple terms (I see you use a tuple with two atoms and id), it's most likely fine to not hash altogether.

2. Is there any reason GenCounter starts a process? It seems to me you only really use the registry to store and lookup keys, but not the process itself. If that's the case, what you actually want is to store the counters in an ETS table (which is exactly what Registry uses under the hood).

[coveralls]

coverage: 82.276% (+0.5%) from 81.779%
when pulling c02c23b on fix/connect-backoff
into e2275cd on main.

[kiwicopple]

🎉 This PR is included in version 2.34.54 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀