I proposed this since it is in line with the requirement of non-salaried (neither active nor passive) members only need to retain their knowledge, which seems to be given here.
| Report Date | Date of submission (2026/10/08) |
| Submitted by | Christian Langenbacher |
| Sponsored by | N/A (inactive, not claiming a salary) |
@clang:matrix.org16YCL3UVpVWQLGW3p3Zx4k5WAEp9W1DwdDnxAbyAaPxVxnp322024/03/272026/06/25Runtimes (Engineering, Security, Benchmarking) (primary), Runtimes (FRAME, APIs, integrations), Encointer (system chain)Up until now, I have been an active Member. However, with the new accountability requirements, I am unsure in this moment of transition how sponsorship and the restrictions on other full-time employment apply to me. Hence, I have set myself to inactive and will not draw a salary for the time being, which is why this report does not name a sponsor. Nevertheless, it is my interest to stay active in the ecosystem, and I will revisit my status once the requirements are settled.
My argument primarily revolves around PRs and issues that I filed in the Polkadot SDK and Runtimes repositories.
My work falls primarily into the Runtimes (Engineering, Security) subsystem: the safety of runtime upgrades, state hygiene on the relay chains, and keeping the Runtimes repository and its integration tests maintainable. The multi-block migration work also extends upstream into FRAME.
I have also listed myself for the Encointer system chain in the Subsystems, which I will own. However, as Encointer has been deemed non-essential, my work on it does not count towards my Fellowship contributions and is hence not part of this argument.
As part of the TODO cleanup from my last report, I switched the Polkadot Hub runtimes to the upstream
ForceUnstuckOnFailedMigration (runtimes#1217).
During the review, ggwpez pointed out
that the max_blocks of the aggregated MBM is just the sum of the individual migrations' limits. If a single
migration does not set one, there is no fallback, and a buggy migration that does not make progress would
keep the chain stuck indefinitely.
I took up the suggested follow-up and capped
individual MBMs to one day in the runtimes. After hitting the cap, the migration is considered failed, and
the FailedMigrationHandler is triggered. As this is useful for every chain using the migrations pallet, I
also drafted the upstream version, which
integrates a configurable cap directly into pallet-migrations. Following bkchr's proposal, we closed the
runtimes PR in favour of the upstream one: the issue is rather unlikely to happen, and we have been rolling
without the cap for quite a while already.
Exceeding the limit only helps if the failure handler leaves the chain recoverable. Hence, the upstream PR
also switches the default from FreezeChainOnFailedMigration to ForceUnstuckOnFailedMigration.
EnterSafeModeOnFailedMigration would be the better middle ground, but while looking into it I noticed
that it returns KeepStuck even after successfully entering safe mode, which would block any manual
intervention. I have raised this as a
separate question upstream and deferred that change until it is clarified.
Before polkadot-sdk#6604, DMP queued messages for paras without a head. The leftover queues have been waiting for a cleanup on Polkadot and Kusama since December 2024.
I diagnosed the affected para IDs on both relay chains with a script (8 paras per relay) and wrote a migration that removes their queues and queue heads. I chose to target those paras explicitly instead of iterating through all storage keys, as the bug has been fixed upstream and no new stale queues should appear. Some of these paras could have been re-registered by the time of the upgrade, so the migration skips any para that has a head by then. The PR is still pending review.
In my last report I described the triage
of all TODO/FIXME markers in the Runtimes repository. The PRs I mentioned there as pending have all been
merged in this period (#1213,
#1214,
#1216,
#1217), and I continued the work with
a few more:
ethereum_extrinsic test, removing the local copy and the now-unused fixtures dev-dependency.actions/create-release and actions/upload-release-asset actions in the release workflow, keeping
the published asset names unchanged.I posted a status update
on the tracking issue: of the 27 actionable TODOs from the original triage, 13 are gone from main and 4 more
are addressed by open PRs. In the meantime, 7 new ones appeared, so 17 remain open. These are
categorized into those that can be removed with the next SDK bump and those that still need an issue or work.
I also used the occasion to close out stale issues whose work had already been done
(#382,
#1061).
The Runtimes repository's integration-tests-helpers crate had become a re-export facade of the
upstream emulated-integration-tests-common crate: the macros it existed for had been backported, but
the pub use emulated_integration_tests_common::* was kept for compatibility. This resulted in a mixed
import pattern, where test crates imported the same items from both places.
I removed the facade so that almost all
crates now depend only on the upstream version, re-exported the Snowbridge helpers instead of redefining
them, and replaced the remaining test macro with a generic test function for better type checks, mirroring
the more recent pattern in the codebase. This touches 47 files and closes a
TODO open since June 2024. Along the way, I
noticed that .gitignore's **/chains/ pattern also matches integration-tests/emulated/chains/, so files
added to the emulated chain crates were silently untracked. The PR is still pending review.
I upstreamed a minor convenience change to derive Debug, Clone, PartialEq and Eq for
EraPayoutParams (polkadot-sdk#12449), which I
noticed was missing during the cleanup in the runtimes repository.
I remained involved in 3 Polkadot SDK issues and 3 Runtimes issues over the period, and continued to assist community members with technical questions in the Fellowship and ecosystem Element channels.
| Ranks | Activity thresholds | Agreement thresholds | Member's voting activities | Comments |
|---|---|---|---|---|
| I | 90% | N/A | ||
| II | 80% | N/A | No eligible referenda | |
| III | 70% | 100% | ||
| IV | 60% | 90% | ||
| V | 50% | 80% | ||
| VI | 40% | 70% |
Threshold