should we have a `archive_unstable_upgrades`?

[josepot]

As of today polkadot-api doesn't support the archive group of functions (and it probably won't for a while).

Nevertheless, I have been thinking about what would be needed in order to properly support it, and I have concluded that ideally we would need an endpoint that can let the consumer know the blocks that have triggered runtime upgrades.

The way that I envision this API is: it would take a block hash as an input, and it would return a sorted array with the heights (or the block hashes, but preferably the heights IMO) of those ancestor blocks that have triggered runtime upgrades.

Thoughts?

@tomaka @lexnv @jsdw

[tomaka]

This seems identical to #108

[josepot]

This seems identical to #108

~How come? I thought that #108 was meant to find the "diffs" of certain storage entries?~

~What I'm after is finding out the blocks that have triggered runtime-upgrades. Basically, what I want to know is the blocks for which the Metadata_metadata runtime call will yield different results.~

Dah! Of course, checking the diffs of the storage entry System.LastRuntimeUpgrade would give me that 😅

[josepot]

This seems identical to #108

@tomaka is correct, this information can be inferred with what's proposed on #108 . So, closing this. Thanks!

[tomaka]

The storage key name :code contains the runtime code. When it changes, there's a runtime upgrade. It's the only "special" storage key, alongside with :heappages and the child-trie-related stuff (https://github.com/paritytech/json-rpc-interface-spec/pull/118#issuecomment-1841221883)