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

ibc: fix connection paths to use ibc-types #3118

Merged
merged 4 commits into from
Sep 29, 2023
Merged

Conversation

avahowell
Copy link
Contributor

IBC on main will be broken until this is merged; we still had some of the ibc standard paths defined in the penumbra-ibc crate, which recently got changed. This broke compatibility, but these keys shouldn't even be in this crate. This PR removes the hardcoded connection keys and replaces them with the ones exposed by ibc-types, and also fixes the ClientConnections mapping logic to be consistent with the spec and the ecosystem.

This is blocking on release of a new version of ibc-types which includes a domain type we previously missed, ClientPaths

@avahowell avahowell temporarily deployed to smoke-test September 28, 2023 23:47 — with GitHub Actions Inactive
@avahowell avahowell temporarily deployed to smoke-test September 29, 2023 09:21 — with GitHub Actions Inactive
Copy link
Member

@hdevalence hdevalence left a comment

Choose a reason for hiding this comment

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

LGTM modulo path nits!

Comment on lines 11 to 17
// these are internal helpers that are used by penumbra-ibc, but not part of the IBC spec (that is,
// counterparties don't expect to verify proofs about them)
pub fn client_processed_heights(client_id: &ClientId, height: &Height) -> String {
format!("ibc/clients/{client_id}/processedHeights/{height}")
format!("clients/{client_id}/processedHeights/{height}")
}
pub fn client_processed_times(client_id: &ClientId, height: &Height) -> String {
format!("ibc/clients/{client_id}/processedTimes/{height}")
format!("clients/{client_id}/processedTimes/{height}")
Copy link
Member

Choose a reason for hiding this comment

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

if these aren't to be used by counterparties, and are component-internal, should we be prefixing them like the other component keys?

@@ -48,7 +48,7 @@ tendermint = { version = "0.33.0", features = ["rust-crypto"] }
jmt = "0.7"

# External dependencies
ibc-types = { version = "0.6.0", default-features = false, features = ["std", "with_serde"]}
ibc-types = { version = "0.6.3", features = ["std", "with_serde"] }
Copy link
Member

Choose a reason for hiding this comment

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

side point, but, i think we should change the ibc-types crate to make the feature be called serde rather than with_serde, since that's a more conventional name

Copy link
Member

Choose a reason for hiding this comment

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

@hdevalence Cargo gets confused when using colliding feature names that overlap with an optional dependency, even if you specify dep:serde, I never was able to find a way to bundle the serde = [dep:serde, dep:serde_derive] etc. maybe it's a skill issue.

Copy link
Member

Choose a reason for hiding this comment

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

yeah, i remember it being annoying to figure out. it seems potentially worth it longer-term though.

Copy link
Member

Choose a reason for hiding this comment

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

Cargo would not complain about it but the end result is that, somehow, serde_derive would not be available to the consumer crate (internal to the ibc-types graph)

@avahowell avahowell temporarily deployed to smoke-test September 29, 2023 17:38 — with GitHub Actions Inactive
@avahowell avahowell merged commit 85e5061 into main Sep 29, 2023
8 checks passed
@avahowell avahowell deleted the fix-connection-paths branch September 29, 2023 21:34
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.

3 participants