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

fix!: change UX in key assignment #1998

Merged
merged 9 commits into from
Jul 18, 2024
Merged

Conversation

insumity
Copy link
Contributor

@insumity insumity commented Jun 28, 2024

Description

Modifies the user experience (UX) of key assignment by reverting #1732. Note that this is not a full revert of #1732 because #1732 added tests that made sense to keep here as well.

Before, when a validator tried to re-use a previously assigned consumer key that they used, we would return success and the assignment would be a no-op. With this PR, we return an error instead.
The reason for this change was that we had a validator re-assigning an old consumer key they used but because the assignment was a no-op, the old consumer key was not set. As a result, the validator was confused on why the assignment was successful but the consumer key on the consumer chain remained unchanged.

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

  • Included the correct type prefix in the PR title
  • Added ! to the type prefix if the change is state-machine breaking
  • Confirmed this PR does not introduce changes requiring state migrations, OR migration code has been added to consumer and/or provider modules
  • Targeted the correct branch (see PR Targeting)
  • Provided a link to the relevant issue or specification
  • Followed the guidelines for building SDK modules
  • Included the necessary unit and integration tests
  • Added a changelog entry to CHANGELOG.md
  • Included comments for documenting Go code
  • Updated the relevant documentation or specification
  • Reviewed "Files changed" and left comments if necessary
  • Confirmed all CI checks have passed
  • If this PR is library API breaking, bump the go.mod version string of the repo, and follow through on a new major release

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

  • confirmed the correct type prefix in the PR title
  • confirmed ! the type prefix if the change is state-machine breaking
  • confirmed this PR does not introduce changes requiring state migrations, OR confirmed migration code has been added to consumer and/or provider modules
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic
  • reviewed API design and naming
  • reviewed documentation is accurate
  • reviewed tests and test coverage

Summary by CodeRabbit

  • New Features

    • Improved key assignment security: Now triggers an error if a validator attempts to reuse the same consumer key, preventing key duplication.
  • Bug Fixes

    • Enhanced error handling for scenarios where a key is already assigned, ensuring accurate failure scenarios and messages.
  • Tests

    • Updated test cases and JSON structures to reflect new error handling logic for key assignments.
  • Documentation

    • Updated function descriptions in test cases to specify scenarios related to key assignment failures.

@github-actions github-actions bot added C:Testing Assigned automatically by the PR labeler C:x/provider Assigned automatically by the PR labeler labels Jun 28, 2024
@insumity insumity changed the title fix!: fix key assignment fix!: change UX in key assignment Jun 28, 2024
@insumity insumity self-assigned this Jun 28, 2024
@insumity insumity marked this pull request as ready for review June 28, 2024 09:16
@insumity insumity requested a review from a team as a code owner June 28, 2024 09:16
Copy link
Contributor

coderabbitai bot commented Jun 28, 2024

Walkthrough

Walkthrough

The changes enhance the key assignment process by preventing validators from reusing the same consumer key. This involves returning an error when a validator attempts to reuse a key, improving security and avoiding duplication issues. Modifications span across error handling in test cases, updating JSON test data, refining key assignment logic, and adjusting test descriptions to reflect the new error scenarios.

Changes

File(s) Change Summary
.changelog/unreleased/api-breaking/provider/1998-change-ux-in-key-assignment.md, .changelog/unreleased/state-breaking/provider/1998-change-ux-in-key-assignment.md Introduced modifications to key assignment UX to trigger errors on key reuse, enhancing security.
tests/.../steps_compatibility.go, tests/.../steps_start_chains.go Updated error handling logic and comments for key assignment conflicts, refined ExpectError and ExpectedError fields.
tests/e2e/tracehandler_testdata/*.json Modified ExpectError fields from false to true and updated ExpectedError messages. Adjusted State fields by removing nested objects and subfields.
tests/integration/key_assignment.go Changed function descriptions and boolean values in test cases for double key assignment scenarios.
x/ccv/provider/handler_test.go Updated test case names and expected error values to reflect scenarios of consumer keys in use. Added new test cases for different validator conflicts.
x/ccv/provider/keeper/key_assignment.go Unified logic to handle cases preventing multiple validators from assigning the same key and reusing keys.
x/ccv/provider/keeper/msg_server.go Changed logging and event emissions to use the consumer public key instead of the TM public key.

Recent review details

Configuration used: .coderabbit.yml
Review profile: CHILL

Commits

Files that changed from the base of the PR and between a15827c and 58e6bd2.

Files selected for processing (15)
  • .changelog/unreleased/api-breaking/provider/1998-change-ux-in-key-assignment.md (1 hunks)
  • .changelog/unreleased/state-breaking/provider/1998-change-ux-in-key-assignment.md (1 hunks)
  • tests/e2e/steps_compatibility.go (1 hunks)
  • tests/e2e/steps_start_chains.go (2 hunks)
  • tests/e2e/tracehandler_testdata/consumer-double-sign.json (2 hunks)
  • tests/e2e/tracehandler_testdata/democracy.json (2 hunks)
  • tests/e2e/tracehandler_testdata/democracyRewardsSteps.json (2 hunks)
  • tests/e2e/tracehandler_testdata/happyPath.json (2 hunks)
  • tests/e2e/tracehandler_testdata/multipleConsumers.json (4 hunks)
  • tests/e2e/tracehandler_testdata/shorthappy.json (2 hunks)
  • tests/e2e/tracehandler_testdata/slashThrottle.json (2 hunks)
  • tests/integration/key_assignment.go (2 hunks)
  • x/ccv/provider/handler_test.go (2 hunks)
  • x/ccv/provider/keeper/key_assignment.go (1 hunks)
  • x/ccv/provider/keeper/msg_server.go (1 hunks)
Additional context used
Path-based instructions (6)
x/ccv/provider/handler_test.go (2)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations. Only report issues that you have a high degree of confidence in.


Pattern **/*_test.go: "Assess the unit test code assessing sufficient code coverage for the changes associated in the pull request. Only report issues that you have a high degree of confidence in."

tests/e2e/steps_compatibility.go (2)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations. Only report issues that you have a high degree of confidence in.


Pattern tests/e2e/*: "Assess the e2e test code assessing sufficient code coverage for the changes associated in the pull request. Only report issues that you have a high degree of confidence in."

tests/integration/key_assignment.go (2)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations. Only report issues that you have a high degree of confidence in.


Pattern tests/integration/*: "Assess the e2e test code assessing sufficient code coverage for the changes associated in the pull request. Only report issues that you have a high degree of confidence in."

tests/e2e/steps_start_chains.go (2)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations. Only report issues that you have a high degree of confidence in.


Pattern tests/e2e/*: "Assess the e2e test code assessing sufficient code coverage for the changes associated in the pull request. Only report issues that you have a high degree of confidence in."

x/ccv/provider/keeper/msg_server.go (1)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations. Only report issues that you have a high degree of confidence in.

x/ccv/provider/keeper/key_assignment.go (1)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations. Only report issues that you have a high degree of confidence in.

Additional comments not posted (23)
.changelog/unreleased/api-breaking/provider/1998-change-ux-in-key-assignment.md (1)

1-3: Changelog entry is clear and concise.

The changelog entry accurately describes the changes made in the PR. No issues found.

.changelog/unreleased/state-breaking/provider/1998-change-ux-in-key-assignment.md (1)

1-3: Changelog entry is clear and concise.

The changelog entry accurately describes the changes made in the PR. No issues found.

tests/e2e/steps_compatibility.go (2)

92-103: Test step "AssignConsumerPubKeyAction" for the same validator is clear and concise.

The test step correctly handles the scenario where a key is already assigned by the same validator. No issues found.


Line range hint 104-121: Test step "AssignConsumerPubKeyAction" for another validator is clear and concise.

The test step correctly handles the scenario where a key is already assigned by another validator. No issues found.

x/ccv/provider/keeper/msg_server.go (2)

76-76: Ensure logging consistency.

The change to log the consumer public key instead of the TM public key is appropriate. Ensure that all related logs and events use the consumer public key consistently.


83-83: Ensure event attribute consistency.

The change to use the consumer public key in the event attribute is appropriate. Ensure that all related events use the consumer public key consistently.

x/ccv/provider/keeper/key_assignment.go (1)

375-381: Ensure the error message is clear and precise.

The error message "a validator has or had assigned this consumer key already" is clear and helps in understanding the issue. This change prevents reusing consumer keys that are already in use or are to be pruned, which is a good improvement for security and consistency.

tests/e2e/tracehandler_testdata/slashThrottle.json (2)

148-149: Correctly set ExpectError to true.

Setting ExpectError to true is appropriate as the test now expects an error when reusing a consumer key.


149-151: Update ExpectedError message.

The ExpectedError message "a validator has or had assigned this consumer key already" accurately reflects the new error condition.

tests/e2e/tracehandler_testdata/democracyRewardsSteps.json (2)

148-149: Correctly set ExpectError to true.

Setting ExpectError to true is appropriate as the test now expects an error when reusing a consumer key.


149-151: Update ExpectedError message.

The ExpectedError message "a validator has or had assigned this consumer key already" accurately reflects the new error condition.

tests/e2e/tracehandler_testdata/democracy.json (3)

148-149: LGTM! The error expectation is correctly updated.

The change to ExpectError: true and the updated ExpectedError message ensure that the test case correctly expects an error when a validator tries to reuse a previously assigned consumer key.


151-151: Simplified state representation.

The empty State section simplifies the test case by focusing on the action and expected error.


161-162: LGTM! The error expectation is correctly updated.

The change to ExpectError: true and the updated ExpectedError message ensure that the test case correctly expects an error when a different validator tries to reuse a previously assigned consumer key.

tests/e2e/tracehandler_testdata/shorthappy.json (3)

148-149: LGTM! The changes to ExpectError and ExpectedError fields are appropriate.

The modifications align with the PR's objective to return an error when a validator attempts to reuse a key.


161-162: LGTM! The changes to ExpectError and ExpectedError fields are appropriate.

The modifications align with the PR's objective to return an error when a validator attempts to reuse a key.


151-151: LGTM! The changes to the State object are consistent with the new error scenarios.

The modifications ensure that the state accurately represents the adjustments made to the key assignment logic.

tests/e2e/tracehandler_testdata/happyPath.json (3)

148-149: LGTM! The error handling update is clear and aligns with the PR objective.

The ExpectError field is correctly set to true, and the ExpectedError message clearly indicates the issue with reusing a consumer key.


151-151: LGTM! Simplifying the state object.

The State object is empty, which helps in focusing on the action and expected error without unnecessary state information.


161-161: LGTM! The error handling update is clear and aligns with the PR objective.

The ExpectError field is correctly set to true, and the ExpectedError message clearly indicates the issue with reusing a consumer key.

tests/e2e/tracehandler_testdata/multipleConsumers.json (3)

148-149: Change Approved: Correctly handling re-used consumer keys.

The change to set ExpectError to true and update the ExpectedError message to "a validator has or had assigned this consumer key already" ensures that re-used consumer keys are correctly flagged as errors, addressing potential confusion for validators.


161-162: Change Approved: Correctly handling re-used consumer keys.

The change to set ExpectError to true and update the ExpectedError message to "a validator has or had assigned this consumer key already" ensures that re-used consumer keys are correctly flagged as errors, addressing potential confusion for validators.


430-431: Change Approved: Correctly handling re-used consumer keys.

The change to set ExpectError to true and update the ExpectedError message to "a validator has or had assigned this consumer key already" ensures that re-used consumer keys are correctly flagged as errors, addressing potential confusion for validators.

Warning

Review ran into problems

Problems (1)
  • Git: Failed to clone repository. Please contact CodeRabbit support.

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share
Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai generate interesting stats about this repository and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@@ -54,7 +54,7 @@ func (k msgServer) AssignConsumerKey(goCtx context.Context, msg *types.MsgAssign
k.Logger(ctx).Info("assigned consumer key",
"consumer chainID", msg.ChainId,
"validator operator addr", msg.ProviderAddr,
"consumer tm pubkey", consumerTMPublicKey.String(),
"consumer public key", msg.ConsumerKey,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before the public key was logged as something similar to this:

5:16PM INF assigned consumer key consumer chainID=neutron-1 consumer tm pubkey="ed25519:\"\\242\\263!y\\256\\304\\246\\023\\031\\360\\323\\215\\337\\263\\020\\271\\203A\\253\\211hk\\205\\356'\\234\\310W>B7\\213\" " module=x/ibc-provider validator operator addr=cosmosvaloper1jmykcq8gylmy5tgqtel4xj4q62fdt49sl584xd

We fix this so we get the public key logged as:

`{"@type":"/cosmos.crypto.ed25519.PubKey","key":"Ui5Gf1+mtWUdH8u3xlmzdKID+F3PK0sfXZ73GZ6q6is="}

Thanks to @MSalopek for pointing this out!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome!

Copy link
Contributor

@p-offtermatt p-offtermatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thanks for the work!

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Outside diff range and nitpick comments (1)
x/ccv/provider/keeper/msg_server.go (1)

[!TIP]
Codebase Verification

Ensure robust handling of previously assigned consumer keys.

The AssignConsumerKey function does not currently check if a consumer key has already been assigned. This could lead to key reuse, which is not handled by the current implementation. Please add a check to verify if the consumer key is already in use and handle this scenario appropriately.

  • File: x/ccv/provider/keeper/msg_server.go
  • Lines: 32-69
Analysis chain

Line range hint 39-64: Ensure robust handling of previously assigned consumer keys.

Please verify that the implementation correctly identifies and handles cases where a consumer key is reused. This is crucial for meeting the new requirements stated in the PR.

Scripts executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Verify the handling of previously assigned consumer keys.

# Test: Search for the function implementation and check for error handling related to key reuse.
ast-grep --lang go --pattern $'func (k msgServer) AssignConsumerKey($_, $_) ($_,$_){
  $$$
  if $_ {
    return nil, $_
  }
  $$$
}'

Length of output: 133



Script:

#!/bin/bash
# Description: Locate and extract the implementation of the AssignConsumerKey function to verify error handling for key reuse.

# Locate the file containing the AssignConsumerKey function.
file_path=$(fd -IH 'msg_server.go')

# Extract the implementation of the AssignConsumerKey function.
ast-grep --lang go --pattern 'func (k $_) AssignConsumerKey($_, $_) ($_,$_){ $$$ }' $file_path

Length of output: 2865

@MSalopek MSalopek marked this pull request as draft July 18, 2024 14:44
@insumity insumity force-pushed the insumity/fix-key-assignment branch from a15827c to 58e6bd2 Compare July 18, 2024 16:08
@insumity insumity marked this pull request as ready for review July 18, 2024 16:13
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Outside diff range, codebase verification and nitpick comments (11)
x/ccv/provider/handler_test.go (1)

Line range hint 131-152: Redundant test case: "fail: consumer key in use by the same validator".

The test case "fail: consumer key in use by the same validator" is redundant as it is similar to the test case "fail: consumer key in use by other validator". Consider removing it to avoid redundancy.

-		{
-			name: "fail: consumer key in use by the same validator",
-			setup: func(ctx sdk.Context,
-				k keeper.Keeper, mocks testkeeper.MockedKeepers,
-			) {
-				k.SetPendingConsumerAdditionProp(ctx, &providertypes.ConsumerAdditionProposal{
-					ChainId: "chainid",
-				})
-				// Use the consumer key already
-				k.SetValidatorByConsumerAddr(ctx, "chainid", consumerConsAddr, providerConsAddr)
-
-				gomock.InOrder(
-					mocks.MockStakingKeeper.EXPECT().GetValidator(
-						ctx, providerCryptoId.SDKValOpAddress(),
-					).Return(providerCryptoId.SDKStakingValidator(), nil).Times(1),
-					mocks.MockStakingKeeper.EXPECT().GetValidatorByConsAddr(ctx,
-						consumerConsAddr.ToSdkConsAddr(),
-					).Return(stakingtypes.Validator{}, stakingtypes.ErrNoValidatorFound),
-				)
-			},
-			expError: true,
-			chainID:  "chainid",
-		},
tests/integration/key_assignment.go (4)

124-124: Clarify test case description.

The description "double same-key assignment in same block by same val" could be clearer. Consider rephrasing for better readability.

- "double same-key assignment in same block by same val"
+ "double key assignment in the same block by the same validator"

127-127: Ensure consistent test case descriptions.

The description "double key assignment in same block by same val" should be consistent with the previous suggestion for clarity.

- "double key assignment in same block by same val"
+ "double key assignment in the same block by the same validator"

194-194: Clarify test case description.

The description "double same-key assignment in different blocks by same val" could be clearer. Consider rephrasing for better readability.

- "double same-key assignment in different blocks by same val"
+ "double key assignment in different blocks by the same validator"

197-197: Ensure consistent test case descriptions.

The description "double key assignment in different blocks by same val" should be consistent with the previous suggestion for clarity.

- "double key assignment in different blocks by same val"
+ "double key assignment in different blocks by the same validator"
tests/e2e/steps_start_chains.go (4)

89-89: Clarify comment for failure scenario.

The comment "op should fail - key already assigned by the same validator" is clear but could be more descriptive.

- // op should fail - key already assigned by the same validator
+ // Operation should fail because the key has already been assigned by the same validator

95-96: Ensure error message consistency.

The ExpectedError message "a validator has or had assigned this consumer key already" should be consistent with other similar error messages.

- ExpectedError: "a validator has or had assigned this consumer key already",
+ ExpectedError: "a validator has already assigned this consumer key or had assigned it before",

109-109: Clarify comment for failure scenario.

The comment "op should fail - key already assigned by another validator" is clear but could be more descriptive.

- // op should fail - key already assigned by another validator
+ // Operation should fail because the key has already been assigned by another validator

109-109: Ensure error message consistency.

The ExpectedError message "a validator has or had assigned this consumer key already" should be consistent with other similar error messages.

- ExpectedError: "a validator has or had assigned this consumer key already",
+ ExpectedError: "a validator has already assigned this consumer key or had assigned it before",
tests/e2e/tracehandler_testdata/consumer-double-sign.json (2)

148-149: Ensure error message consistency.

The ExpectedError message "a validator has or had assigned this consumer key already" should be consistent with other similar error messages.

- "ExpectedError": "a validator has or had assigned this consumer key already"
+ "ExpectedError": "a validator has already assigned this consumer key or had assigned it before"

161-161: Ensure error message consistency.

The ExpectedError message "a validator has or had assigned this consumer key already" should be consistent with other similar error messages.

- "ExpectedError": "a validator has or had assigned this consumer key already"
+ "ExpectedError": "a validator has already assigned this consumer key or had assigned it before"

Comment on lines +154 to +175
name: "fail: consumer key in use by other validator",
setup: func(ctx sdk.Context,
k keeper.Keeper, mocks testkeeper.MockedKeepers,
) {
k.SetPendingConsumerAdditionProp(ctx, &providertypes.ConsumerAdditionProposal{
ChainId: "chainid",
})

// Use the consumer key already used by some other validator
k.SetValidatorByConsumerAddr(ctx, "chainid", consumerConsAddr, providerConsAddr2)

gomock.InOrder(
mocks.MockStakingKeeper.EXPECT().GetValidator(
ctx, providerCryptoId.SDKValOpAddress(),
// validator should not be missing
).Return(providerCryptoId.SDKStakingValidator(), nil).Times(1),
mocks.MockStakingKeeper.EXPECT().GetValidatorByConsAddr(ctx,
consumerConsAddr.ToSdkConsAddr(),
// return false - no other validator uses the consumer key to validate *on the provider*
).Return(stakingtypes.Validator{}, stakingtypes.ErrNoValidatorFound),
)
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Duplicate test case: "fail: consumer key in use by other validator".

The test case "fail: consumer key in use by other validator" appears twice. Remove the duplicate to avoid redundancy.

-		{
-			name: "fail: consumer key in use by other validator",
-			setup: func(ctx sdk.Context,
-				k keeper.Keeper, mocks testkeeper.MockedKeepers,
-			) {
-				k.SetPendingConsumerAdditionProp(ctx, &providertypes.ConsumerAdditionProposal{
-					ChainId: "chainid",
-				})
-				// Use the consumer key already used by some other validator
-				k.SetValidatorByConsumerAddr(ctx, "chainid", consumerConsAddr, providerConsAddr2)
-
-				gomock.InOrder(
-					mocks.MockStakingKeeper.EXPECT().GetValidator(
-						ctx, providerCryptoId.SDKValOpAddress(),
-						// validator should not be missing
-					).Return(providerCryptoId.SDKStakingValidator(), nil).Times(1),
-					mocks.MockStakingKeeper.EXPECT().GetValidatorByConsAddr(ctx,
-						consumerConsAddr.ToSdkConsAddr(),
-						// return false - no other validator uses the consumer key to validate *on the provider*
-					).Return(stakingtypes.Validator{}, stakingtypes.ErrNoValidatorFound),
-				)
-			},
-			expError: true,
-			chainID:  "chainid",
-		},
Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
name: "fail: consumer key in use by other validator",
setup: func(ctx sdk.Context,
k keeper.Keeper, mocks testkeeper.MockedKeepers,
) {
k.SetPendingConsumerAdditionProp(ctx, &providertypes.ConsumerAdditionProposal{
ChainId: "chainid",
})
// Use the consumer key already used by some other validator
k.SetValidatorByConsumerAddr(ctx, "chainid", consumerConsAddr, providerConsAddr2)
gomock.InOrder(
mocks.MockStakingKeeper.EXPECT().GetValidator(
ctx, providerCryptoId.SDKValOpAddress(),
// validator should not be missing
).Return(providerCryptoId.SDKStakingValidator(), nil).Times(1),
mocks.MockStakingKeeper.EXPECT().GetValidatorByConsAddr(ctx,
consumerConsAddr.ToSdkConsAddr(),
// return false - no other validator uses the consumer key to validate *on the provider*
).Return(stakingtypes.Validator{}, stakingtypes.ErrNoValidatorFound),
)
},

@MSalopek MSalopek added this pull request to the merge queue Jul 18, 2024
Merged via the queue into main with commit fde751e Jul 18, 2024
14 of 16 checks passed
@MSalopek MSalopek deleted the insumity/fix-key-assignment branch July 18, 2024 18:12
mergify bot pushed a commit that referenced this pull request Jul 18, 2024
* init

* added nit changes

* added CHANGELOGs

* fixed E2E tests error message

* brought one more test from #1732

* fixed logging

* fixed event key

* fixed CHANGELOGs

* rebase

(cherry picked from commit fde751e)
MSalopek pushed a commit that referenced this pull request Jul 18, 2024
fix!: change UX in key assignment (#1998)

* init

* added nit changes

* added CHANGELOGs

* fixed E2E tests error message

* brought one more test from #1732

* fixed logging

* fixed event key

* fixed CHANGELOGs

* rebase

(cherry picked from commit fde751e)

Co-authored-by: insumity <[email protected]>
insumity added a commit that referenced this pull request Jul 23, 2024
* init

* added nit changes

* added CHANGELOGs

* fixed E2E tests error message

* brought one more test from #1732

* fixed logging

* fixed event key

* fixed CHANGELOGs

* rebase
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A:backport/v5.2.x C:Testing Assigned automatically by the PR labeler C:x/provider Assigned automatically by the PR labeler
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants