[PB-5851] feat(fv): add partial undo for tier downgrades #917
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
douglas-xt
temporarily deployed
to
development
GitHub Actions
Inactive
douglas-xt
temporarily deployed
to
development
GitHub Actions
Inactive
…lans with versioning enabled
douglas-xt
force-pushed
the
feat/partial-undo-file-versioning
branch
from
37228b3 to
0f6fc20
Compare
douglas-xt
temporarily deployed
to
development
GitHub Actions
Inactive
douglas-xt
temporarily deployed
to
development
GitHub Actions
Inactive
|
jzunigax2
approved these changes
Feb 6, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Implements intelligent file version cleanup when users downgrade between subscription plans that both support file versioning. The system now adjusts the number of versions per file and removes expired versions according to the limits of the new tier.
Why are we doing this?
Previously, file version cleanup only occurred when users downgraded to plans without file versioning support, resulting in complete deletion of all versions. However, when users downgrade between plans that both have versioning enabled but with different limits (e.g., from Ultimate to Premium), versions were not being adjusted to match the new tier's restrictions.
How are we doing this?
The system now detects when file versioning remains enabled after a tier change and applies the new tier's version limits. It removes versions that exceed the maximum allowed per file and deletes versions older than the retention period of the new plan. When versioning is disabled, it continues to remove all versions as before.
Should this be manually tested & how?
Already tested manually using curl commands against the gateway endpoint. A test user with 100 files and 25 versions per file was created, then downgraded from Ultimate to Premium tier. The system correctly deleted excess versions according to Premium limits (keeping 10 versions per file). Subsequently tested downgrade to Free tier, which successfully removed all remaining versions.
Any background context you want to provide?
This change affects the gateway user update flow when tier changes occur. The feature maintains backward compatibility with the existing full cleanup behavior for free tier downgrades while adding the new partial cleanup logic for downgrades between paid tiers.