@ioquatix @jcmfernandes, how can I fix the following message after an upgrade?

invalid secret: 9, must be >=64

I use it in a test for sidekiq-unique-jobs:

RSpec.describe SidekiqUniqueJobs::Web do
  include Rack::Test::Methods
  include RSpecHtmlMatchers

  def app
    @app ||= Rack::Builder.new do
      use Rack::Session::Cookie,
          key: "rack.session",
          domain: "foo.com",
          path: "/",
          expire_after: 2_592_000,
          secret: "change_me",
          old_secret: "also_change_me"

      run Sidekiq::Web
    end
  end

  before do
    flush_redis
  end
end

I am a little stumped by this, but I figured that rack-session was upgraded as part of upgrading Sinatra when updating Sidekiq 🤦‍♂️🙈

I am a little stumped by this, but I figured that rack-session was upgraded as part of upgrading Sinatra when updating Sidekiq 🤦‍♂️🙈

Alright, I just needed to make the secrets long enough, and it worked.

I'm glad you sorted it out @mhenrixon. The error has nothing to do with this PR though. Unlike the cookie-based session management that shipped with rack v2, rack-session (rightfully) requires longer secrets.

I'm glad you sorted it out @mhenrixon. The error has nothing to do with this PR though. Unlike the cookie-based session management that shipped with rack v2, rack-session (rightfully) requires longer secrets.

@jcmfernandes If this is the case, it might make sense for rack-session to provide documentation or a rotation mechanism for old keys to migrate to newer ones. If a rack 2 production app switched to this, it would throw exceptions for all requests that used the old secret, until a new one was used, which would then break all existing sessions.

There hasn't been a lot of issues filed about this, so it's possible this isn't an issue a lot of people are having, but it could make for a very bad day for someone out there in production that's not running on a fresh code base.

I'm glad you sorted it out @mhenrixon. The error has nothing to do with this PR though. Unlike the cookie-based session management that shipped with rack v2, rack-session (rightfully) requires longer secrets.

@jcmfernandes If this is the case, it might make sense for rack-session to provide documentation or a rotation mechanism for old keys to migrate to newer ones. If a rack 2 production app switched to this, it would throw exceptions for all requests that used the old secret, until a new one was used, which would then break all existing sessions.

There hasn't been a lot of issues filed about this, so it's possible this isn't an issue a lot of people are having, but it could make for a very bad day for someone out there in production that's not running on a fresh code base.

I agree, even though this was a change added in a new major version. We should start by warning that we'll break things, and only then break things.