Skip to content
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

Model max_uncommitted_tx_count of raft.h in abs.tla #6508

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

lemmy
Copy link
Contributor

@lemmy lemmy commented Sep 27, 2024

Align spec with CCF by replacing global upper bound MaxLogLength with MaxUncommittedCount (see max_uncommitted_tx_count in raft.h) that restricts the length by which a log may be extended in each step.

These two commits were previously part of #6475. @heidihoward approved them in #6475 (comment).

with MaxUncommittedCount (see max_uncommitted_tx_count in raft.h)
that restricts the length by which a log may be extended in each step.

Signed-off-by: Markus Alexander Kuppe <[email protected]>
(Maintains the checked state space)

Signed-off-by: Markus Alexander Kuppe <[email protected]>
@lemmy lemmy added the tla TLA+ specifications label Sep 27, 2024
@lemmy lemmy requested a review from a team as a code owner September 27, 2024 01:02
@achamayou
Copy link
Member

achamayou commented Sep 27, 2024

This constraint is too simplistic, and does not accurately represent what max uncommitted tx count does.

The current behaviour is that new user and governance transactions are rejected, but signatures and nodes frontend transactions (joins, jwt refresh...) do not count towards that limit. Applying that cap to the overall committed growth per step is incorrect.

I can see that it is necessary to have a cap for model checking to work, but conflating it with max uncommitted tx is not accurate, and may result in confusion and trace validation failures.

@lemmy
Copy link
Contributor Author

lemmy commented Sep 27, 2024

This constraint is too simplistic, and does not accurately represent what max uncommitted tx count does.

The current behaviour is that new user and governance transactions are rejected, but signatures and nodes frontend transactions (joins, jwt refresh...) do not count towards that limit. Applying that cap to the overall committed growth per step is incorrect.

The documentation of max_uncommitted_tx_count documentation could mention this behavior:

"Maximum number of uncommitted transactions allowed before the primary refuses new transactions. Unlimited if set to 0."

Regarding ccfraft, is it correct to assume that max_uncommitted_tx_count applies to TypeEntry, but does not apply to TypeSignature, TypeReconfiguration, or TypeRetired?

I can see that it is necessary to have a cap for model checking to work, but conflating it with max uncommitted tx is not accurate, and may result in confusion and trace validation failures.

Actually, unbounded sequences create one less constraint in the (pending) axiomatic definitions in abs.tla.

@lemmy
Copy link
Contributor Author

lemmy commented Sep 27, 2024

Implementation-level issues and PRs:
#5692
#3871
#5690

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

Successfully merging this pull request may close these issues.

2 participants