Fix: [Referenda Tracks] Resolve representation issues that are breaking PJS apps

[pandres95]

This Pull Request fixes the following issues present with PJS derived from #2072

• Represents Tracks constant as a Vec<(TrackId, TrackInfo)> instead of Vec<Track>, so tracks iteration in PJS apps Governance hook remains as how it was before, and

• Encapsulates [u8; N] from name field in a StringLike structure that represents its TypeInfo as a &str and encodes as such. This fixes errors present in PJS apps that treat name as a javascript string.

[pandres95]

@ggwpez @gui1117 @bkchr any additional comments, suggestions, or improvements for this fix?

[kianenigma]

Are we going to merge this, or revert as per #7661?

[pandres95]

Are we going to merge this, or revert as per #7661?

I'm expecting to have the change @gui1117 requested today, so we can proceed with merging this one. Probably would be nice to have a quick round of reviews before merging, but IIUC this PR seems like a good fix for the current reviewers.

[paritytech-release-backport-bot]

Created backport PR for stable2503:

• [stable2503] Backport #7671 #7991 with remaining conflicts!

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin backport-7671-to-stable2503
git worktree add --checkout .worktree/backport-7671-to-stable2503 backport-7671-to-stable2503
cd .worktree/backport-7671-to-stable2503
git reset --hard HEAD^
git cherry-pick -x 467d1f642c8d5d6b11c45e5212f546af86b6f6e4
git push --force-with-lease

[RomarQ]

@pandres95 @bkchr @ggwpez @kianenigma @gui1117
Why exactly was this change needed?

The new returned name looks like this, and I really don't see the need for it. Now, tools or existing code expecting a "pure" name, have to trim the string. For example, EVM precompiles using track info.

[bkontur]

@pandres95 @bkchr @ggwpez @kianenigma @gui1117 Why exactly was this change needed?

The new returned name looks like this, and I really don't see the need for it. Now, tools or existing code expecting a "pure" name, have to trim the string. For example, EVM precompiles using track info.

Where is that u0000u0000... coming from?
@karolk91 Could this be also related to the: #9354 rust version?

[RomarQ]

@pandres95 @bkchr @ggwpez @kianenigma @gui1117 Why exactly was this change needed?
The new returned name looks like this, and I really don't see the need for it. Now, tools or existing code expecting a "pure" name, have to trim the string. For example, EVM precompiles using track info.

Where is that u0000u0000... coming from? @karolk91 Could this be also related to the: #9354 rust version?

It comes from str_array, which is used to pad with nulls at the end to fill the bounded length.

polkadot-sdk/substrate/primitives/runtime/src/lib.rs

Lines 1037 to 1050 in 0c51d2e

	///
	/// ```rust
	/// # use sp_runtime::str_array;
	/// const MY_STR: [u8; 6] = str_array("data");
	/// assert_eq!(MY_STR, *b"data\0\0");
	/// ```
	pub const fn str_array<const N: usize>(s: &str) -> [u8; N] {
	debug_assert!(s.len() <= N, "String literal doesn't fit in array");
	let mut i = 0;
	let mut arr = [0; N];
	let s = s.as_bytes();
	while i < s.len() {
	arr[i] = s[i];
	i += 1;

[gui1117]

@pandres95 @bkchr @ggwpez @kianenigma @gui1117
Why exactly was this change needed?

The new returned name looks like this, and I really don't see the need for it. Now, tools or existing code expecting a "pure" name, have to trim the string. For example, EVM precompiles using track info.

We wanted to allow dynamic set of tracks:
#2072

The name needed to be bounded.
But we still wanted to allow static instances of the type.
So we used a fixed array (Because bounded vec is not static and cow of vec is not bounded)
We should have created a new type that allowed a static variant and a bounded vec variant to prevent the breaking change.

But in general I agree if doing a change without a break is not possible we should maybe prefer to fork the crate instead of breaking it unnecessarily.

Is it already used on kusama? do we need to change it before it ships to polkadot and kusama, or should we roll with the breakage?

[pandres95]

Kusama recently approved this WFC which in practice should enable the usage of dynamic tracks in the near future.

I think it might be possible to work with a fix to trim the track names when sending them via precompiles. wdyt @gui1117?

[RomarQ]

Kusama recently approved this WFC which in practice should enable the usage of dynamic tracks in the near future.

I think it might be possible to work with a fix to trim the track names when sending them via precompiles. wdyt @gui1117?

We will trim the name inside the precompile on Moonbeam to keep the old behaviour, just wrote the comment to point out that maybe this was not the best design.

Sorry about bringing the discussion to your PR, I should have commented in #2072.

[pandres95]

No problem at all @RomarQ. It's a good thing to notice. Definitely something that can be improved.

[gui1117]

Kusama recently approved this WFC which in practice should enable the usage of dynamic tracks in the near future.

I think it might be possible to work with a fix to trim the track names when sending them via precompiles. wdyt @gui1117?

I think we can roll with it. And try to be more careful in the future.