Skip to content

rabbit_db_*: Wrap ets calls to projections in whereis/1 checks #11667

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 11, 2024

Conversation

the-mikedavis
Copy link
Collaborator

Projections might not be available in a mixed-version scenario where a cluster has nodes which are all blank/uninitialized and the majority of nodes run a version of Khepri with a new machine version while the minority does not have the new machine version's code.

In this case, the cluster's effective machine version will be set to the newer version as the majority of members have access to the new code. The older version members will be unable to apply commands including the register_projection commands that set up these ETS tables. When these ETS tables don't exist, calls like ets:tab2list/1 or ets:lookup/2 cause badarg errors.

We use default empty values when ets:whereis/1 returns undefined for a projection table name. Instead we could use local queries or leader queries. Writing equivalent queries is a fair amount more work and the code would be hard to test. ets:whereis/1 should only return undefined in the above scenario which should only be a problem in our mixed-version testing - not in practice.

Projections might not be available in a mixed-version scenario where a
cluster has nodes which are all blank/uninitialized and the majority
of nodes run a version of Khepri with a new machine version while the
minority does not have the new machine version's code.

In this case, the cluster's effective machine version will be set to
the newer version as the majority of members have access to the new
code. The older version members will be unable to apply commands
including the `register_projection` commands that set up these ETS
tables. When these ETS tables don't exist, calls like `ets:tab2list/1`
or `ets:lookup/2` cause `badarg` errors.

We use default empty values when `ets:whereis/1` returns `undefined` for
a projection table name. Instead we could use local queries or leader
queries. Writing equivalent queries is a fair amount more work and the
code would be hard to test. `ets:whereis/1` should only return
`undefined` in the above scenario which should only be a problem in
our mixed-version testing - not in practice.
@the-mikedavis the-mikedavis merged commit 8c6b866 into main Jul 11, 2024
289 checks passed
@the-mikedavis the-mikedavis deleted the md/khepri-projections-wrap-ets-calls branch July 11, 2024 16:27
the-mikedavis added a commit that referenced this pull request Jul 11, 2024
rabbit_db_*: Wrap `ets` calls to projections in `whereis/1` checks (backport #11667)
the-mikedavis added a commit that referenced this pull request Jul 11, 2024
rabbit_db_*: Wrap `ets` calls to projections in `whereis/1` checks (backport #11667) (backport #11677)
@dumbbell
Copy link
Collaborator

Instead of ets:whereis() + the read, what about performing the read in a try/catch block and returning the fallback value in catch error:badarg?

In a regular situation, we would only have one ETS call, not two.

It is also atomic: if for whatever reason, the ETS table goes away between ets:whereis() and the read, we still get the badarg.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants