Open intrip opened 1 year ago
Let me know your take on this, I'll be happy to create a PR to re-add the ability to use the old format.
This is affecting us as well, because the signed global ids are created in workers and passed along as part of a link. The links don't expire for awhile. If we upgrade the gem, the links can no longer be parsed.
To expand on this a little more, our case was an edge case where we use bootboot
for upgrading rails. In this case the DEPENDENCIES_NEXT
Gemfile_next.lock had version 1.2.1 and the default had 1.0.0 set. We upgraded workers first, the urls were created with the new signed global id format. Our web processes were still running on the older version of globalid, and didn't know how to handle the new format. If we had updated both web and workers at the same time we wouldn't have had an issue.
https://github.com/rails/globalid/commit/12f76297c803c658ea2fc684d4336db347a90901 removed the ability to keep using the old format when serializing via
SignedGlobalID
. This causes the following issues:I understand that "Rollbacks" can be considered a "no-issue" since the upgrade is one-way but I'm still afraid of the rolling-deployment issue. Additionally, Version "1.2.1" is the new version pointed by Rails "7.1", which makes rolling back a Rails upgrade more complicated because it forces you to upgrade GlobalID before upgrading Rails in order to not encounter the "unexpected" rollback issue.