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.
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: permissionless added event + cli changes #2185
fix: permissionless added event + cli changes #2185
Changes from 3 commits
b017871
8db2423
0173c0d
525afc0
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Nice catch. @insumity why do we have deprecated fields in query requests. Given that both chanId and consumerId have the same type, it's easy to have bugs where we call functions with a chainId.
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.
For backward compatibility. We try to prevent
chainIds
from being used by doing:But in this case we unfortunately missed it.
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.
Can you please give more details about this. What's the use case that we want to keep compatibility with?
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.
We could imagine that Hermes is using this query (
QueryValidatorProviderAddr
) so they use our protos to build Hermes. If we were to simply go and removechain_id
, we would break their builds. It seems, in those cases, the right approach is to just markchain_id
as deprecated. It is true that the actual query is still broken from their side but this seems less severe.We could remove all those
chain_id
s if we were to bump the proto version tov2
but this seems like it would be more time consuming at this stage.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.
Bumping the proto version is something we should talk to @MSalopek.
Regarding breaking the queries for Hermes for example, as you stated it will be broken anyway. All the users of these queries will need to update their code. Leaving chainId there seems even more dangerous to me as there is a chance that we forget to return an error and the query goes through and returns weird stuff. So my recommendation would be to remove deprecated fields from the queries.
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 would avoid
v2
and inform hermes that there will be a compatibility break and that they should update their code.