fix(dashmate): migrate Drive and DAPI images onto the prerelease line

[shumkov]

Issue being fixed or feature implemented

dashmate derives the Drive and rs-dapi image tags from the package version in getBaseConfigFactory.js — the major on a stable release, the major plus the prerelease identifier on a prerelease:

constprereleaseTag=semver.prerelease(version)===null ? '' : `-${semver.prerelease(version)[0]}`;constdockerImageVersion=`${semver.major(version)}${prereleaseTag}`;// "4" stable, "4-rc" on an rc

A fresh install on 4.1.0-rc.x therefore gets dashpay/drive:4-rc / dashpay/rs-dapi:4-rc correctly. But config files store resolved values, so existing operators only move when a migration re-pins them — and no migration re-pinned those two images above '4.0.0':

• the '4.0.0' migration re-pins both from base config, moving operators onto the stable :4 images;
• the latest '4.1.0-rc.2' migration re-pins only the gateway Envoy image.

Result: an operator upgrading a 4.0.x dashmate to a 4.1.0-rc dashmate keeps running the 4.0 stable Drive/DAPI images instead of the 4.1 rc images — a silent version mismatch between the node's dashmate and the platform binaries it runs.

What was done?

A '4.1.0-rc.3' migration in getConfigFileMigrationsFactory.js re-pinning platform.drive.abci.docker.image and platform.dapi.rsDapi.docker.image from the base config.

Migration key — 4.1.0-rc.3.migrateConfigFileFactory.js short-circuits when fromVersion === toVersion, then applies every key where semver.gt(key, fromVersion) in semver.compare order. Keying at the already-released 4.1.0-rc.2 would never fire for an operator already on rc.2. Keying one release ahead sorts it after '4.1.0-rc.2' and covers every affected cohort: all 4.0.x, plus 4.1.0-rc.1/rc.2. This follows the convention documented in the '4.0.0-rc.3' and '4.1.0-rc.2' migration comments.

Guard — only the tags releases actually publish.

conststockDriveImage=/^dashpay\/drive:4(-(rc|dev|beta|alpha|pr|hotfix))?$/;conststockRsDapiImage=/^dashpay\/rs-dapi:4(-(rc|dev|beta|alpha|pr|hotfix))?$/;

The identifiers are listed rather than matched loosely. A looser 4(-[a-z]+)? also matches operator-chosen tags in the same namespace — dashpay/drive:4-patched, :4-local and :4-mybuild would all have been silently re-pinned onto the stock image. That is reachable: isServiceBuildRequired.js lets operators run a locally built image under their own tag, and docs/config/drive-abci.md documents this field as operator-settable with a dashpay/drive:* example. All six identifiers are verified against shipped git tags (dev 158, pr 84, rc 40, alpha 11, beta 10, hotfix 5) and against what semver.prerelease(v)[0] can yield — 2.1.0-pr.2716.1 → pr, 3.0.1-hotfix.1 → hotfix.

An identifier a later release invents is skipped rather than guessed at, which leaves the operator untouched instead of overwriting them; the table-walk test forces a migration at the release that invents it.

The major stays at 4 permanently — it matches the tag being migrated away from, not the one being migrated to, so a later major needs its own migration rather than an edit here.

How Has This Been Tested?

Two complementary tests in migrateConfigFileFactory.spec.js.

1. should refresh version-derived images from every config version that has a migration — parametrized over the migration table itself rather than written per migration. For every config version an operator can be sitting on, a config stamped at that version carrying that era's derived tags must migrate onto the images a fresh install produces today. Future migrations are covered without touching the test. Fails without the migration:

images left on a stale tag; add a migration keyed at the upcoming release
that re-pins them from the base config
"4.0.0 -> base: drive dashpay/drive:4, expected dashpay/drive:4-rc"
"4.0.0 -> base: rs-dapi dashpay/rs-dapi:4, expected dashpay/rs-dapi:4-rc"
... every config, not just the first

2. should move only the stock version-derived tags and leave operator images alone — pins both halves of the guard. Pinned at configFormatVersion 4.0.0, the only starting point where this migration acts alone: below it the unconditional re-pin in '4.0.0' overwrites every image regardless.

Mutation results — each of these shipped green before this test existed, and now fails:

mutation	table walk	guard test
guard deleted (unconditional re-pin)	green	red
loose 4(-[a-z]+)?	green	red
$ anchor dropped	green	red
migration handles only 4 and 4-rc	green	red
rs-dapi half dropped	red	green
migration removed entirely	red	green

Why the pre-existing tests never caught this. The '4.0.0' migration re-pins unconditionally, so every cohort below that key is rescued by it for free. The v0.25.0 fixture test starts at 0.25.0 and the recent-version test at 4.0.0-rc.2, so both cross it. Only a cohort at or above 4.0.0 was exposed, and nothing exercised one.

Releases older than 1.3.0-dev.3 are excluded from the walk — the migration at that key reads core.log.file.categories, which current configs no longer have, so it and everything older throw against a config built from current defaults. That range stays covered by the v0.25.0 historical fixture test.

Commands run:

• yarn workspace dashmate run test:unit — 158 passing
• yarn workspace dashmate exec eslint configs/getConfigFileMigrationsFactory.js test/unit/config/configFile/migrateConfigFileFactory.spec.js — clean

Not tested: an end-to-end upgrade of a real 4.0.x node, which would need a live masternode on the 4.0 line.

Notes for the release

Merge timing matters. The key must stay strictly above every released version at merge time. migrateConfigFileFactory.js filters with strict semver.gt, so an operator whose config is stamped exactly 4.1.0-rc.3 would be excluded permanently, not just once. If this does not land in the 4.1.0-rc.3 release, bump the key to whatever release it lands in.

Installing an RC dashmate moves every configured network, mainnet included, onto the RC images. One config.json holds every network, and any command migrates all of them. An operator running mainnet on dashpay/drive:4 who installs an RC to help test testnet will find their mainnet config re-pinned to dashpay/drive:4-rc, pulled on the next dashmate --config=mainnet update. This matches what a fresh install of the same dashmate already writes to the mainnet config, so it is existing design rather than something this migration invents — but it now reaches the 4.0.x upgrade cohort too. Worth calling out in the RC release notes.

Downgrading does not restore the images. Going back to a 4.0.x dashmate leaves the config on 4-rc, because the older dashmate has no migration keyed above it. Also worth a release-note line.

At the rc → stable boundary this recurs by design. Nothing re-pins once a config reaches 4.1.0-rc.3, so cutting 4.1.0 stable needs its own '4.1.0' migration. The table-walk test goes red in that release's CI precisely to force it — the fix is to add the migration, not to delete or weaken the test. Raising the floor constant to dodge it trips the expect(releases).to.include(newest) assertion, and a no-op migration at the new key still leaves the walk red.

Breaking Changes

None. The migration moves operators from stock Dash image tags onto the tag the base config already derives for the installed dashmate version — what a fresh install of that version gets. Operator-chosen images are untouched, and re-running is idempotent.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 6877c657-cdc2-4d91-828e-9ebfc9b5546d

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/dashmate-migration-rc-image-tags

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

⛔ Blockers found — Sonnet deferred (commit 7acc32e)
Canonical validated blockers: 1

[thepastaclaw]

Preliminary review — Codex only

The migration targets both version-derived image paths, uses base tags that are consistent across all default presets, and safely skips missing nested Docker sections. However, its broad stock-tag patterns overwrite operator-selected same-repository tags despite the stated preservation guarantee, and the generalized test does not model the intended rc.2-to-rc.3 repair boundary. The image guard must be tightened before merge.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

• Codex reviewers: gpt-5.6-sol — general (completed)
• Verifier: gpt-5.6-sol — verifier
• Sonnet: not run (deferred by blocker gate)

🔴 1 blocking | 🟡 1 suggestion(s)

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/dashmate/configs/getConfigFileMigrationsFactory.js`:
- [BLOCKING] packages/dashmate/configs/getConfigFileMigrationsFactory.js:1597-1598: Stock-image patterns also match custom alphabetic tags
The optional `-[a-z]+` suffix accepts any alphabetic identifier rather than only identifiers generated by Dash releases. Consequently, locally retagged or otherwise operator-selected images such as `dashpay/drive:4-patched`, `dashpay/drive:4-custom`, or `dashpay/rs-dapi:4-latest` are silently replaced with the base image. This contradicts the migration's explicit guarantee that custom, vendor-patched, and floating tags survive. Repository tag history shows the managed prerelease identifiers are `alpha`, `beta`, `dev`, `hotfix`, `pr`, and `rc`; matching those explicitly follows the tight allowlist used by the earlier 3.x image migration.
In `packages/dashmate/test/unit/config/configFile/migrateConfigFileFactory.spec.js`:
- [SUGGESTION] packages/dashmate/test/unit/config/configFile/migrateConfigFileFactory.spec.js:118-136: Cohort sweep does not exercise the rc.3 migration boundary
This sweep iterates migration keys rather than actual operator releases, so it omits released 4.1 cohorts such as beta.1, beta.2, and rc.1. More importantly, the rc.2 case starts with an already-correct `:4-rc` image and short-circuits because the current package and `fromVersion` are both `4.1.0-rc.2`; the rc.3 case is a downgrade and invokes no migration. The 4.0.0 case passes only because the runner has no `toVersion` upper bound and therefore executes the future rc.3 migration while targeting rc.2. Add a focused `4.1.0-rc.2` config carrying inherited `:4` images migrated to `4.1.0-rc.3`, plus preservation cases for same-repository custom tags such as `:4-custom` or `:4-patched`.

[thepastaclaw]

Final validation — Codex + Sonnet

The 4.1.0-rc.3 migration correctly re-pins stock Drive and rs-dapi v4 images across all configured networks, safely handles partial shapes, remains idempotent, and now preserves operator-selected images through an explicit release-tag allowlist. No functional blocker remains, but the tests still do not directly exercise an rc.1/rc.2-stamped config retaining inherited stable :4 images as it crosses the rc.3 migration boundary.

Review provenance

• Codex reviewers: gpt-5.6-sol — general (completed)
• Verifier: gpt-5.6-sol — final-verifier (fallback)
• Sonnet reviewers: claude-sonnet-5 — general (failed), claude-sonnet-5 — general (completed)
  Source: reviewers gpt-5.6-sol + claude-sonnet-5; final verifier gpt-5.6-sol (fallback after unparseable Sonnet verifier).

🟡 1 suggestion(s)

1 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/dashmate/test/unit/config/configFile/migrateConfigFileFactory.spec.js`:
- [SUGGESTION] packages/dashmate/test/unit/config/configFile/migrateConfigFileFactory.spec.js:69-80: Cohort sweep does not exercise the rc.3 migration boundary
No test directly verifies the affected persisted state: a config stamped `4.1.0-rc.1` or `4.1.0-rc.2` while retaining inherited `dashpay/drive:4` and `dashpay/rs-dapi:4` images, upgraded through `4.1.0-rc.3`. The focused case starts at `4.0.0-rc.2` with already-current `:4-rc` images and also crosses the existing unconditional `4.0.0` re-pin, so it passes independently of the new migration. In the table sweep, the rc.2 case returns immediately because it equals the current package version, while the rc.3 case is a downgrade to rc.2 and selects no migration because the runner uses strict `semver.gt`; the 4.0.0 and guard cases reach rc.3 only because the runner has no `toVersion` upper bound. Consequently, moving the repair into the existing rc.2 migration would leave the suite green even though a real rc.2-stamped config would skip it. Add a focused migration from `4.1.0-rc.2` to `4.1.0-rc.3`, seed both images with `:4`, and assert that both become the base rc images.