Skip to content

Prepare release of v1.21.0 (polkadot-stable2512) #881

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.

Sign up for GitHub

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

Jump to bottom
Closed
Niederb wants to merge 13 commits into from
Closed

Prepare release of v1.21.0 (polkadot-stable2512) #881

Niederb wants to merge 13 commits into from

Conversation

@Niederb
Copy link
Contributor

@Niederb Niederb commented Jan 12, 2026 •
edited
Loading

DO NOT MERGE

@Niederb Niederb self-assigned this Jan 12, 2026
@Niederb Niederb added E1-breaksnothing F9-dependencies Pull requests that update a dependency file labels Jan 12, 2026
@Niederb Niederb requested review from clangenb and haerdib January 14, 2026 07:10
clangenb
clangenb reviewed Jan 14, 2026
View reviewed changes
Copy link
Collaborator

@clangenb clangenb left a comment

Choose a reason for hiding this comment

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

Nice, thanks for handling this.

Regarding your no_std build error, I suppose that we could try changing the return type here to the value mentioned in the error message:

substrate-api-client/test-no-std/src/main.rs

Line 61 in 6164219

fn panic(_panic: &PanicInfo<'_>) -> ! {

.github/workflows/ci.yml Outdated
Comment on lines 55 to 58
RUSTFLAGS='--cfg substrate_runtime' cargo build --release -p test-no-std --features api-client,
RUSTFLAGS='--cfg substrate_runtime' cargo build --release -p test-no-std --features compose-macros,
RUSTFLAGS='--cfg substrate_runtime' cargo build --release -p test-no-std --features node-api,
RUSTFLAGS='--cfg substrate_runtime' cargo build --release -p test-no-std --features primitives,
Copy link
Collaborator

@clangenb clangenb Jan 14, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

You should be able to set the env at the step level here with:

      - name: ${{ matrix.check }}
        env: 
           RUSTFLAGS: '--cfg substrate_runtime'
        run: ${{ matrix.check }}

Copy link
Contributor Author

@Niederb Niederb Jan 15, 2026

Choose a reason for hiding this comment

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

I found yet another approach that works with cargo directly by providing a config.toml.
I like this a bit more as it is more general, but so far I only managed to get it working for the wasm32 builds. For no-std I have not (yet) managed to find a solution that works with a config.toml 😞

@Niederb
Copy link
Contributor Author

Niederb commented Jan 15, 2026

Nice, thanks for handling this.

Regarding your no_std build error, I suppose that we could try changing the return type here to the value mentioned in the error message:

substrate-api-client/test-no-std/src/main.rs

Line 61 in 6164219

fn panic(_panic: &PanicInfo<'_>) -> ! {

I have tried this but I could not get this to work. The error message originates from sp-io. Do you think it is triggered by us providing our own panic-handler? I don't see how they are related and I think our signature should be correct.

@clangenb
Copy link
Collaborator

clangenb commented Jan 15, 2026

I have tried this but I could not get this to work. The error message originates from sp-io. Do you think it is triggered by us providing our own panic-handler? I don't see how they are related and I think our signature should be correct.

I have been looking into it: my superficial impression is that it might not be possible to plainly compile to no_std, as no_std without the substrate_runtime rust flag or a risk-v target doesn't exist anymore.

So maybe we should drop pure no_std currently, and envision risk-v as a potential alternative in the future.

@haerdib
Copy link
Contributor

haerdib commented Jan 20, 2026 •
edited
Loading

Sorry, a bit late but to my understanding the following is happening: In commit paritytech/polkadot-sdk@93852b1 the RUSTFLAG substrate_runtime has been introduced. Crates such as sp_state_machine now use this feature instead of no_std. In the same commit other crates have been updated, such as sp_storage, which had no_std compile flags removed completely (from pub struct Storage for example). Theoretically, this should have been absolutely fine (hopefully, not yet tested) - if the commit was taken as a whole.

Our problem is now that some crates, such as sp-storage, are still on the version previous to the commit mentioned above and some crates, such as sp-state-machine already include this commit.

At least I'm quite sure that's the problem for the compile errors for the no-std primitives build (https://github.com/scs/substrate-api-client/actions/runs/21025146379/job/60447849672?pr=881#logs). Not sure what's happening with sp-io, but I think there's a good chance that the version mismatch is the problem there as well.

Either way - sucks. Nothing we can do but
a) Downgrade the "too new" crates
b) Leave as is, hope for the better in the next release cycle

Any preferences?

@Niederb
Copy link
Contributor Author

Niederb commented Jan 21, 2026

Any preferences?

I think I would opt for "leave as is" for now.
Our weekly build (that runs a cargo update) still passes, so I think this problem is only temporary and it is only a matter of time that the change, that is "missing" from crates.io, gets published.

haerdib
haerdib reviewed Jan 21, 2026
View reviewed changes
Copy link
Contributor

@haerdib haerdib left a comment

Choose a reason for hiding this comment

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

Agreed, let's release either way. Two comments, otherwise it's perfect. Thank you very much!

.github/workflows/ci.yml Outdated
with:
key: ${{ matrix.check }}

Copy link
Contributor

@haerdib haerdib Jan 21, 2026

Choose a reason for hiding this comment

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

That's not necessary, is it?

Copy link
Contributor Author

@Niederb Niederb Jan 21, 2026

Choose a reason for hiding this comment

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

Critically important whitespaces! I removed them...poor whitespaces 😭 😆

Copy link
Contributor

@haerdib haerdib Jan 21, 2026

Choose a reason for hiding this comment

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

Haha 😆

README.md
A: When specifying your own state query, you must provide the return type of the state you're trying to retrieve. This is because the api-client only gets bytes from the node and must be able to deserialize these properly. That is not possible without knowing the type to decode to. This type may be for example a simple `u64` for retrieving the `Balance` of an account. But careful: If you're looking at the pallet code and its return type, don't forget to take the Query type into consideration. The `OptionQuery` for example automatically wraps the return type into an `Option` (see the [substrate docs "Handling query return values"](https://docs.substrate.io/build/runtime-storage/) for more information). Alternatively, you can always double check via [polkadot.js](https://polkadot.js.org/).
If you're importing a value directly from the runtime, as it's done in this [example](https://github.com/scs/substrate-api-client/blob/fb108a7d1994705bbca50233e3bc66cec3726523/examples/examples/subscribe_events.rs#L25-L27), remember to adapt it to the node you are querying from.

4. Q: I get a compilation error when compiling for `no-std` or `wasm`. For example "unresolved import `sp_core::storage::Storage`" in `sp-state-machine`. What is wrong?
Copy link
Contributor

@haerdib haerdib Jan 21, 2026

Choose a reason for hiding this comment

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

Can you add the explanation about the crate Version mismatch, such that user know they can / should switch to master if it's a problem?

Copy link
Contributor Author

@Niederb Niederb Jan 21, 2026

Choose a reason for hiding this comment

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

I expanded the comment a bit.

@Niederb Niederb marked this pull request as ready for review January 21, 2026 10:33
@Niederb Niederb requested a review from haerdib January 21, 2026 10:33
haerdib
haerdib approved these changes Jan 21, 2026
View reviewed changes
Copy link
Contributor

@haerdib haerdib left a comment

Choose a reason for hiding this comment

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

Yeyy, thanks for bearing with me!

@Niederb
Copy link
Contributor Author

Niederb commented Jan 22, 2026

@clangenb v1.21.0 is now published on crates.io. Also see https://github.com/scs/substrate-api-client/releases/tag/v1.21.0

@Niederb Niederb closed this Jan 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@clangenb clangenb clangenb left review comments

@haerdib haerdib haerdib approved these changes

Assignees

@Niederb Niederb

Labels

E1-breaksnothing F9-dependencies Pull requests that update a dependency file

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@Niederb @clangenb @haerdib