Skip to content

Conversation

@ranshid
Copy link
Member

@ranshid ranshid commented Aug 4, 2025

This is needed due to changes presented in #2089

Signed-off-by: Ran Shidlansik <[email protected]>
@ranshid ranshid requested a review from zuiderkwast August 4, 2025 18:39
@codecov
Copy link

codecov bot commented Aug 4, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 71.57%. Comparing base (3b12132) to head (54a7d3f).
⚠️ Report is 17 commits behind head on unstable.

Additional details and impacted files
@@             Coverage Diff              @@
##           unstable    #2422      +/-   ##
============================================
+ Coverage     71.51%   71.57%   +0.06%     
============================================
  Files           123      123              
  Lines         67454    67493      +39     
============================================
+ Hits          48239    48308      +69     
+ Misses        19215    19185      -30     
Files with missing lines Coverage Δ
src/aof.c 80.53% <100.00%> (ø)
src/rdb.c 76.81% <100.00%> (-0.27%) ⬇️
src/valkey-check-rdb.c 72.11% <100.00%> (+0.33%) ⬆️

... and 11 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

ranshid added 3 commits August 4, 2025 21:58
Signed-off-by: Ran Shidlansik <[email protected]>
Signed-off-by: Ran Shidlansik <[email protected]>
Signed-off-by: Ran Shidlansik <[email protected]>
Signed-off-by: Ran Shidlansik <[email protected]>
Copy link
Contributor

@sarthakaggarwal97 sarthakaggarwal97 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice!

(rdbver >= RDB_FOREIGN_VERSION_MIN && rdbver <= RDB_FOREIGN_VERSION_MAX) ||
(rdbver > RDB_FOREIGN_VERSION_MAX && !is_valkey_magic) ||
(rdbver > RDB_VERSION && server.rdb_version_check == RDB_VERSION_CHECK_STRICT)) {
serverLog(LL_WARNING, "Can't handle RDB format version %d", rdbver);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably extend this to include whether or not it's the Redis magic as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@madolson to which one of the check conditions do you refer to? The [12-79] or just validate that below 12 we have the redis magic?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@madolson done. want to take a look?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently not :D

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also meant we should print out whether or not the version is incompatible or it's the Redis Magic.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we don't reuse the same numbers as with the different magics, it will never be ambiguous (except for hand-hacked RDB files with wrong magic/number).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For us yes, not for end users. Ideally we should print out that this is a Redis RDB and not a valkey RDB.

@ranshid
Copy link
Member Author

ranshid commented Aug 5, 2025

@valkey-io/core-team just to highlight the implications of this: this basically breaks the 7.2 and 8.0 compatibility.
IIRC we only added the strict version check in 8.1 which will now become the only downgradable version.
Should we include some wording about it in the documentation? I expect it is going to be somewhat confusing.
Also, I expect some of the Cross version cluster tests will now fail. I think it is expected, but would be happy to hear if you feel otherwise.

@ranshid
Copy link
Member Author

ranshid commented Aug 5, 2025

I think that the only issue is with the failover test.
This test will attempt to first sync-up an old version which is now unsupported. It will probably not be an issue for the daily compat tests as they are being run with compatible-redis tag.

I think that for the CI tests we can run only against 8.1 and enable the relaxed rdb check in this specific test.

@zuiderkwast WDYT?

@zuiderkwast
Copy link
Contributor

IIRC we only added the strict version check in 8.1 which will now become the only downgradable version.

Ran, yes, because of this, we consider 8.1 a stepping stone. All our customers must upgrade to (a version of our products that contain) 8.1 before they can upgrade further to 9 and later.

I think that for the CI tests we can run only against 8.1 and enable the relaxed rdb check in this specific test.

Yes.

We have discussed a way to let Valkey produce older RDB versions for even better downgrade possibilities. It would involve a config to set the RDB version and it would be up to the user to only use features supported by the chosen RDB version. I still think we should do it. Technically, it's not very difficult... #1108.

@ranshid
Copy link
Member Author

ranshid commented Aug 5, 2025

IIRC we only added the strict version check in 8.1 which will now become the only downgradable version.

Ran, yes, because of this, we consider 8.1 a stepping stone. All our customers must upgrade to (a version of our products that contain) 8.1 before they can upgrade further to 9 and later.

I think that for the CI tests we can run only against 8.1 and enable the relaxed rdb check in this specific test.

Yes.

We have discussed a way to let Valkey produce older RDB versions for even better downgrade possibilities. It would involve a config to set the RDB version and it would be up to the user to only use features supported by the chosen RDB version. I still think we should do it. Technically, it's not very difficult... #1108.

Thank you @zuiderkwast . I am mainly referring to the plan to change the CI as part of THIS pr so that we will start running the cross version compat against 8.1 + configure relaxed RDB check in the failover test

also make Cross version cluster - failover use relaxed rdb check

Signed-off-by: Ran Shidlansik <[email protected]>
@ranshid
Copy link
Member Author

ranshid commented Aug 5, 2025

hhh There is a failure in test Send cluster message via module from other server to latest, but it is because this test should have fail IMO. It is based on the fact that CONFIG resetstat will reset the cluster msg stats (which is not true). I actually think that there might be a bug in the use of light headers in this cross version case? will check

@hpatro FYI

@ranshid
Copy link
Member Author

ranshid commented Aug 5, 2025

hhh There is a failure in test Send cluster message via module from other server to latest, but it is because this test should have fail IMO. It is based on the fact that CONFIG resetstat will reset the cluster msg stats (which is not true). I actually think that there might be a bug in the use of light headers in this cross version case? will check

@hpatro FYI

O.K after some fighting, I found the issue is known (#1708) and that is the node-id is passed NULL terminated only from 8.1 to clusterMassageRecievers. because of that the 7.2 module is unable to send the DONG message back to the originator and this is why the test fails for 7.2. So there are some AIs:

  1. fix the failover test as it is now not testing correctly the message transfer.
  2. @zuiderkwast / @hpatro seems like you guys have context on the issue. did we decide to backport this? if not what do we expect?
    I guess after enabling this test to work with 8.1 there will be no failure though

@zuiderkwast zuiderkwast moved this to In Progress in Valkey 9.0 Aug 5, 2025
@ranshid ranshid merged commit 33a43f2 into valkey-io:unstable Aug 5, 2025
52 checks passed
@github-project-automation github-project-automation bot moved this from In Progress to Done in Valkey 9.0 Aug 5, 2025
* RDB 11 is the last open-source Redis RDB version, used by Valkey 7.x and 8.x.
*
* RDB 12+ are non-open-source Redis formats.
* RDB 12-79 are reserved for Redis non-compatible RDB formats
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any particular reason to pick 79?

With Valkey 9.0 we could have picked 90 as our new RDB version :).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was discussed in the last core-meeting and we decided on 80. Personally I think the 80's (although the bad hair thing) were so cool

Copy link
Contributor

@zuiderkwast zuiderkwast Aug 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

80+ for Valkey magic was picked in #1604. It was arbitrary-ish.

Yeah we could have used 90 for Valkey 9.0 but with this scheme we would run out of RDB versions after Valkey 99.9. If we just bumb it when necessary, we don't run out of RDB numbers as fast.

allenss-amazon pushed a commit to allenss-amazon/valkey-core that referenced this pull request Aug 19, 2025
This is needed due to changes presented in
valkey-io#2089

---------

Signed-off-by: Ran Shidlansik <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

5 participants