Skip to content

make type filtering consistent with f+1 threshold used in other consensus checks - #341

Closed
ettec wants to merge 1 commit into
mainfrom
CAPPL-1086-multi-outcome-check
Closed

make type filtering consistent with f+1 threshold used in other consensus checks#341
ettec wants to merge 1 commit into
mainfrom
CAPPL-1086-multi-outcome-check

Conversation

@ettec

@ettec ettec commented Oct 29, 2025

Copy link
Copy Markdown
Contributor

https://smartcontract-it.atlassian.net/browse/CAPPL-1086

Type filtering should not use the type with the highest count, it should consider a type with >= f+1 count to be a valid outcome and fail if more than one type has >= f+1 count, i.e. there is more than one potential outcome as this is ambiguous

@ettec
ettec marked this pull request as ready for review October 29, 2025 17:43
@ettec
ettec requested review from a team as code owners October 29, 2025 17:43
@ettec
ettec enabled auto-merge October 29, 2025 17:43
@cl-sonarqube-production

Copy link
Copy Markdown

@ettec

ettec commented Oct 31, 2025

Copy link
Copy Markdown
Contributor Author

Change put into PR -> (#328)

@ettec ettec closed this Oct 31, 2025
auto-merge was automatically disabled October 31, 2025 11:50

Pull request was closed

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.

1 participant