-
Notifications
You must be signed in to change notification settings - Fork 278
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
[fix] #3853: Compare permission token payload as JSON #3855
Merged
mversic
merged 2 commits into
hyperledger-iroha:iroha2-dev
from
mversic:consistent_token_payload_serialization
Sep 1, 2023
Merged
[fix] #3853: Compare permission token payload as JSON #3855
mversic
merged 2 commits into
hyperledger-iroha:iroha2-dev
from
mversic:consistent_token_payload_serialization
Sep 1, 2023
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mversic
requested review from
s8sato,
appetrosyan,
Arjentix,
SamHSmith,
QuentinI,
outoftardis,
ilchu,
pesterev,
Erigara,
0x009922 and
DCNick3
as code owners
August 31, 2023 12:12
github-actions
bot
added
the
iroha2-dev
The re-implementation of a BFT hyperledger in RUST
label
Aug 31, 2023
mversic
force-pushed
the
consistent_token_payload_serialization
branch
5 times, most recently
from
August 31, 2023 12:31
43a6a34
to
bbed046
Compare
appetrosyan
previously approved these changes
Aug 31, 2023
client/tests/integration/smartcontracts/validator_with_custom_token/src/lib.rs
Outdated
Show resolved
Hide resolved
client/tests/integration/smartcontracts/validator_with_custom_token/src/lib.rs
Show resolved
Hide resolved
mversic
force-pushed
the
consistent_token_payload_serialization
branch
3 times, most recently
from
August 31, 2023 13:55
5e17907
to
842e035
Compare
Pull Request Test Coverage Report for Build 6038411647
💛 - Coveralls |
Signed-off-by: Marin Veršić <[email protected]>
mversic
force-pushed
the
consistent_token_payload_serialization
branch
from
August 31, 2023 14:05
842e035
to
b4d379b
Compare
appetrosyan
approved these changes
Aug 31, 2023
0x009922
reviewed
Sep 1, 2023
0x009922
approved these changes
Sep 1, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not familiar with the changes well. On the shallow look, LGTM. Since this PR is blocking us from rc19
release, I am approving this with fingers crossed.
This was referenced Sep 1, 2023
mversic
added a commit
that referenced
this pull request
Oct 17, 2023
Signed-off-by: Marin Veršić <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
StringWithJson
should implementPartialEq
comparison as JSONthis was causing bugs when
iroha-java
would serialize token payload vs wheniroha
serde
would do soDefaultValidator
struct fromiroha_validator
it's been used incorrectly, because the delegated method must always call back into original validator whereas calling into
DefaultValidator
would prevent this. Interestingly, removingDefaultValidator
didn't increase code duplication which was the argument for introducing it in the first placeDoesAccountHavePermissionToken
As is discussed in [BUG]
Eq
/Ord
forPermissionToken
implementations are broken #3857 the comparison ofPermissionToken
s on the host side is broken and cannot be relied upon. Additionally, there is little reason to think it measurably optimizes the operation of finding a token for an account especially since it's only executed from the validatorEq
/Ord
forPermissionToken
implementations are broken #3857Linked issue
Closes #3853
Benefits
Checklist
CONTRIBUTING.md