Skip to content

Conversation

Pantani
Copy link
Collaborator

@Pantani Pantani commented Jul 10, 2025

Add the distribution module from v0.50.13 with some cleanups

@tbruyelle
Copy link
Collaborator

You should merge again julien/050 to fix the latest tests. You can also merge tbruyelle/chore/lint-upgrade to have a green linter.

That said once merged the IBC setup in the e2e tests is still failing, error is :

e2e_ibc_test.go:167: 
        	Error Trace:	/home/runner/work/atomone/atomone/tests/e2e/e2e_ibc_test.go:167
        	            				/home/runner/work/atomone/atomone/tests/e2e/e2e_setup_test.go:735
        	            				/home/runner/work/atomone/atomone/tests/e2e/e2e_setup_test.go:186
        	            				/home/runner/work/atomone/atomone/tests/e2e/e2e_setup_test.go:192
        	            				/home/runner/work/atomone/atomone/tests/e2e/e2e_test.go:71
        	Error:      	Received unexpected error:
        	            	hermes relayer command failed: failed to create client: error raised while creating client for chain chain-1MAu4z: failed while querying src chain for latest height: RPC error to endpoint http://chain-1mau4z-atomone-00:26657/: response error: Internal error: failed getting app version: app.versionModifier is nil (code: -32603): %!s(<nil>)

I wasn't able to find a fix for now...

@giunatale
Copy link
Collaborator

@Pantani Some pending conflicts after #141 was updated.

@julienrbrt can you also review this when you have time?

@tbruyelle
Copy link
Collaborator

I think the pulsar files can be removed, as Julien did in his branch.

@Pantani Pantani force-pushed the Pantani/feat/dstr-module branch 2 times, most recently from 0141f86 to ea6d970 Compare August 4, 2025 06:51
Pantani added 3 commits August 4, 2025 03:55
# Conflicts:
#	.golangci.yml
#	Makefile
#	app/keepers/keepers.go
#	app/keepers/keys.go
#	app/modules.go
#	tests/e2e/query_test.go
@@ -0,0 +1,173 @@
syntax = "proto3";
package atomone.distribution.v1beta1;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Since this module is aimed to be part of the fork, is it OK to use the atomone namespace for it ?
In other words, are we going to replace the cosmos namespace to atomone for everything in the fork ?
(for remind, the existing gov module which should also go to the fork already uses the atomone namespace)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is also my question. IMHO, as a fork but as a different SDK, it will be nice to have different namespaces. But we can lose some integrations we already have for the cosmos-sdk

Copy link
Collaborator

Choose a reason for hiding this comment

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

Indeed, I would rather keep the original namespace, but for x/gov it will difficult to change it back so cosmos, since clients have already integrated the atomone namespace...

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Great, I will return the namespaces to cosmos

Copy link
Collaborator

Choose a reason for hiding this comment

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

If you don't mind I prefer to keep the comment unresolved until the namespace is returned to cosmos.

Copy link
Collaborator

Choose a reason for hiding this comment

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

This PR will ideally be done in the SDK? So the buf issues shouldn't happen then.

Copy link
Collaborator

@tbruyelle tbruyelle Aug 26, 2025

Choose a reason for hiding this comment

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

That's a good point @julienrbrt. Initially we have decided to fork the distribution module in atomone, but given this namespace problem and the fact that now atomone already depends on our SDK fork, we should move the fork of the distribution module directly to our SDK fork, with the cosmos namespace.

@Pantani could you close this PR and make the same on atomone-one/cosmos-sdk ?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Note that for now the atomone gov module will stay on atomone, because it is more closely tied to the AtomOne Constitution.

Copy link
Collaborator

@julienrbrt julienrbrt Aug 28, 2025

Choose a reason for hiding this comment

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

Note that for now the atomone gov module will stay on atomone, because it is more closely tied to the AtomOne Constitution.

We could port most of the changes to the SDK fork, and keep atom one gov module (for client compat) in atom one as a simple wrapper instead of fork.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah yes I remember you told me about this, let's keep that in mind.

@Pantani Pantani requested a review from tbruyelle August 12, 2025 17:42
Copy link
Collaborator

@tbruyelle tbruyelle left a comment

Choose a reason for hiding this comment

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

Looks good, but as commented we need to keep the original namespace for protos, because introducing a new one will break client integrations. And considering this module will end up in our fork, this is an other good reason to keep the cosmos namespace.

@Pantani
Copy link
Collaborator Author

Pantani commented Sep 18, 2025

close because we move this change to atomone cosmos-sdk

atomone-hub/cosmos-sdk#10

@Pantani Pantani closed this Sep 18, 2025
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.

4 participants