remove transitional code wrt executor parameters

[jpserrat]

I've replaced the code with the comment suggestion, @s0me0ne-unkn0wn.

Closes #714

[s0me0ne-unkn0wn]

Well done, it's definitely a legit change, as the executor params have been on Polkadot for a long time already... I'm just asking myself if, for the sake of paranoia, it needs a burn-in prior to merging. I'll ask fellows if we have the capacity for that.

[bkchr]

I don't see any reason for a burn in. In general I have to say that the runtime api returns an Option was not a very good idea here. As we actually expect that this always returns something...

[bkchr]

Actually this implementation is broken for chains that start from genesis. We should keep the current code. We should just remove the comment. As I said above, this runtime api function should never have returned an option..

[s0me0ne-unkn0wn]

Actually this implementation is broken for chains that start from genesis.

Why? TBH, I didn't test that, but currently, we should bootstrap session zero executor parameters from HostConfiguration::executor_params. I believe the host configuration should be there either way.

[s0me0ne-unkn0wn]

As I said above, this runtime api function should never have returned an option.

The executor parameters are side-data for SessionInfo, and session_info() returns an Option. What would you want it returned if requested for a non-existing session index?

[bkchr]

Why? TBH, I didn't test that, but currently, we should bootstrap session zero executor parameters from HostConfiguration::executor_params. I believe the host configuration should be there either way.

There is no code that does this. At least I couldn't find it?

[s0me0ne-unkn0wn]

There is no code that does this. At least I couldn't find it?

This one:

polkadot-sdk/polkadot/runtime/parachains/src/session_info.rs

Line 196 in 2726d5a

SessionExecutorParams::<T>::insert(&new_session_index, config.executor_params);

initializer_on_new_session() is run for the session zero, right?

[bkchr]

initializer_on_new_session() is run for the session zero, right?

Ahh yeah, that is actually executed on genesis. Then sorry!

[bkchr]

The executor parameters are side-data for SessionInfo, and session_info() returns an Option. What would you want it returned if requested for a non-existing session index?

Maybe a Result, but that wouldn't change that much probably. I mean we could then have at least covered the case where the session was already pruned. (but you could only have guessed what the parameters were back then)

[bkchr]

Approving based on the discussion above.