chore: remove backwards compatibility with 2.6.0 by sbackend123 · Pull Request #5415 · ethersphere/bee

sbackend123 · 2026-03-30T08:56:33Z

Checklist

I have read the coding guide.
My change requires a documentation update, and I have done it.
I have added tests to cover my changes.
I have filled out the description and linked the related issues.

Description

Removed code for backwards compatibility with version 2.6.0

WithBee260Compatibility
bee260BackwardCompatibility() methods
bee260Compatibility tracking map and related methods
FilterBee260CompatibleUnderlays() function
Bee260CompatibilityStreamer interface usage

Breaking change:
Single underlay address serialization is not supported anymore, wire encoding is now list-only.
The underlay prefix and deserialization of a single underlay address are kept for backward compatibility with the current network. Otherwise the handshake with bootnodes fails.

Open API Spec Version Changes (if applicable)

Motivation and Context (Optional)

Related Issue (Optional)

#5340

Screenshots (if appropriate):

AI Disclosure

This PR contains code that has been generated by an LLM.
I have reviewed the AI generated code thoroughly.
I possess the technical expertise to responsibly review the code generated in this PR.

acud · 2026-03-31T07:32:00Z

@sbackend123 I think that removing all migration code might be a bit too eager - can you make sure that the migration code covers the currently active bee node version still showing up in swarmscan?

janos · 2026-03-31T09:32:33Z

@sbackend123 I think that removing all migration code might be a bit too eager - can you make sure that the migration code covers the currently active bee node version still showing up in swarmscan?

I agree, as there are still 2.6 nodes (not many, but still ~6%), it is early to release bee without compatibility.

This code is intended to be temporary. It is a good effort, but I would suggest to hold on merging, for some time.

sbackend123 · 2026-03-31T22:31:00Z

@sbackend123 I think that removing all migration code might be a bit too eager - can you make sure that the migration code covers the currently active bee node version still showing up in swarmscan?

I ran the previous bee version (v2.6.0) locally, let it sync to current block height on maiinet and build a real data directory. Then I started this build on the same data directory without clearing it. The node started successfully with no migration errors.

I also ran earlier versions trying to sync with mainnet, but get error connect new stream: incompatible stream: failed to negotiate protocol: protocols not supported.

acud · 2026-04-01T04:30:53Z

@sbackend123 I think that removing all migration code might be a bit too eager - can you make sure that the migration code covers the currently active bee node version still showing up in swarmscan?

I ran the previous bee version (v2.6.0) locally, let it sync to current block height on maiinet and build a real data directory. Then I started this build on the same data directory without clearing it. The node started successfully with no migration errors.

I also ran earlier versions trying to sync with mainnet, but get error connect new stream: incompatible stream: failed to negotiate protocol: protocols not supported.

I suppose it does not error the migrations because there's nothing to do in the migrations in the current build. I am not 100% sure about the reasoning behind the necessity of those migrations. But we should definitely leave in place the migration code to support the migration path from the node version still running on the network (2.6.0 definitely). The older ones we can mark as nops.

…h 2.7.0 version

mfw78 · 2026-04-02T08:23:14Z

I agree, as there are still 2.6 nodes (not many, but still ~6%), it is early to release bee without compatibility.

Those 2.6.0 nodes are on some dirty tag mostly, so it's on them. They are running custom code - we shouldn't be persisting with cruft in the protocol because someone doesn't update their modifications.

acud · 2026-04-06T11:26:45Z

@sbackend123 this needs a rebase

acud

there's a whole chunk of changes that are in pkg/storer/migration/all_steps.go that is completely not touched but the code can probably also be removed. as for the individual migration steps which are not in use already - there's no need of keeping the files with empty functions that do nothing - those can be removed.

acud · 2026-04-15T05:50:33Z

+
+func firstByteString(data []byte) string {
+	if len(data) == 0 {
+		return "none"


maybe just ""?

acud · 2026-04-15T05:55:32Z

+// step_02 was a migration step that migrated the cache to a new format.
+// It is now a NOOP since all nodes have already run this migration,
+// and new nodes start with an empty database.
+func step_02(_ transaction.Storage) func() error {


if this is not used anywhere - why do we need to keep the file?

…2.6.0 # Conflicts: # pkg/p2p/libp2p/version_test.go # pkg/statestore/storeadapter/migration.go # pkg/storer/internal/reserve/olditems.go # pkg/storer/migration/refCntSize.go # pkg/storer/migration/step_02.go # pkg/storer/migration/step_04_test.go # pkg/storer/migration/step_05.go # pkg/storer/migration/step_05_test.go # pkg/storer/migration/step_06.go # pkg/storer/migration/step_06_test.go

…ility-with-2.6.0

Add test. Move db repair tool.

sbackend123 · 2026-04-22T13:24:47Z

there's a whole chunk of changes that are in pkg/storer/migration/all_steps.go that is completely not touched but the code can probably also be removed. as for the individual migration steps which are not in use already - there's no need of keeping the files with empty functions that do nothing - those can be removed.

If I understand everything correctly, we can't remove it completely because of our migration mechanism.
Existing upgraded nodes may appear fine, but new installations would be broken, because ValidateVersions checks versions are without gaps (added unit test for that) and when we have currentVersion=0 and then next one 8 -> fail.

akrem-chabchoub · 2026-04-28T11:43:55Z


 func (a *Address) UnmarshalJSON(b []byte) error {
 	v := &addressJSON{}
 	err := json.Unmarshal(b, v)


Nice work @sbackend123.

I just have a concern here, what will happen for the 2.6.0 nodes here ? because I see you removed Underlay field from addressJSON, I know this is not needed anymore, but in the Unmarshal the node will have the Underlays filed empty.

Maybe we can keep it in addressJSON (just to for the Unmarshal) and we get that Underlay addr and set it to Underlays slice
Right or maybe I'm missing some parts ?

This is main point, we remove compatibility with 2.6.0 so minimal supported version would be 2.7.0. So we force everybody update their versions

Yes, I know.
I’m just thinking out loud, if I were a node operator on 2.6.0 or earlier, I might suddenly get disconnected without really understanding why. That could be a bit confusing.
But as @janos mentioned, those nodes are only around 6%, so the impact seems pretty small.

acud · 2026-04-28T13:57:12Z

+		4: legacyNoopStep,
+		5: legacyNoopStep,
+		6: legacyNoopStep,
+		7: legacyNoopStep,


please add a comment here that noop steps should never be removed since it would cause the new migrations to not execute on old nodes that have a higher migration version. the same on the legacyNoopStep - it should explicitly be commented that any migration step marked with this function should never be modified or touched and that the noop function should not be removed. i can easily see an LLM agent "refactoring" this out in the future and breaking stuff because it might not see the bigger context of this.

acud · 2026-04-28T13:59:01Z

+		5: noop,
+		6: noop,
+		7: noop,
+		8: noop,


like in the other migrations comment - the sequence and indexes of these migrations should be commented such that they aren't removed in the future

sbackend123 added 3 commits March 26, 2026 00:09

chore: remove legacy code

eebec22

chore: remove legacy code for underlay addresses

af6c38e

chore: noop old migrations and remove legacy underlay test

71d07fd

chore: remove underlayListPrefix prefix

2ee43af

sbackend123 requested review from akrem-chabchoub, gacevicljubisa and janos and removed request for akrem-chabchoub, gacevicljubisa and janos March 31, 2026 09:15

fix: restore underlay prefix and tests for backward compatibility wit…

68613ec

…h 2.7.0 version

gacevicljubisa linked an issue Apr 9, 2026 that may be closed by this pull request

Remove backwards compatibility code to clean up codebase #5340

Open

9 tasks

acud requested changes Apr 15, 2026

View reviewed changes

sbackend123 added 4 commits April 22, 2026 12:42

Merge branch 'refs/heads/master' into chore/remove-backwards-compatib…

fff123b

…ility-with-2.6.0

fix: remove empty files

8a068fc

Add test. Move db repair tool.

fix: remove legacy migrations files

70022f4

sbackend123 added 4 commits April 22, 2026 16:57

fix: fix broken merge

5ac22ee

fix: remove unnecessary changes

1e92169

fix: revert unnecessary changes

c9674df

fix: revert unnecessary changes 3

4758020

sbackend123 added 2 commits April 27, 2026 23:01

fix: return comments

08386b3

fix: clean up

e0ce20d

sbackend123 requested a review from acud April 28, 2026 09:08

sbackend123 marked this pull request as ready for review April 28, 2026 09:08

sbackend123 requested review from akrem-chabchoub and janos April 28, 2026 09:09

akrem-chabchoub reviewed Apr 28, 2026

View reviewed changes

acud reviewed Apr 28, 2026

View reviewed changes

+: noop,
+: noop,
+: noop,
+: noop,

Conversation

sbackend123 commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist

Description

Open API Spec Version Changes (if applicable)

Motivation and Context (Optional)

Related Issue (Optional)

Screenshots (if appropriate):

AI Disclosure

Uh oh!

acud commented Mar 31, 2026

Uh oh!

janos commented Mar 31, 2026

Uh oh!

sbackend123 commented Mar 31, 2026

Uh oh!

acud commented Apr 1, 2026

Uh oh!

mfw78 commented Apr 2, 2026

Uh oh!

acud commented Apr 6, 2026

Uh oh!

acud left a comment

Choose a reason for hiding this comment

Uh oh!

acud Apr 15, 2026

Choose a reason for hiding this comment

Uh oh!

acud Apr 15, 2026

Choose a reason for hiding this comment

Uh oh!

sbackend123 commented Apr 22, 2026

Uh oh!

akrem-chabchoub Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sbackend123 Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

akrem-chabchoub Apr 28, 2026

Choose a reason for hiding this comment

Uh oh!

acud Apr 28, 2026

Choose a reason for hiding this comment

Uh oh!

acud Apr 28, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

sbackend123 commented Mar 30, 2026 •

edited

Loading

akrem-chabchoub Apr 28, 2026 •

edited

Loading

sbackend123 Apr 28, 2026 •

edited

Loading