Turn the Pro badge on when an account gets its first ever proof - #787
Open
mpretty-cyro wants to merge 1 commit into
Open
mpretty-cyro wants to merge 1 commit into
mpretty-cyro wants to merge 1 commit into
Conversation
The badge is off by default, so a new subscriber had to find the toggle in Pro settings before anyone could tell they had subscribed. Desktop has done this since session-desktop 266ac2c9e; this is the same behaviour. The condition is that config carries no proof, no access expiry and no profile features - that this account has never held Pro - rather than that Pro is active now. Enabling on "active" would turn the badge back on at every renewal for a subscriber who had deliberately turned it off, and since a lapsed plan keeps its access expiry after the proof is cleared, that expiry is what tells a returning subscriber from a first-time one. It is read inside the same `mutate(cache:)` that writes the proof and the expiry, and before either of them. The badge itself goes through `Profile.updateLocal(proFeatures:)`, which the Pro settings toggle already uses, so there is no second writer for it. A linked device is unaffected: it takes the badge from the user profile config it merges, and that config's proof or expiry fails the check in any case. `ProBadgeFirstProofSpec` covers the check. It does not cover the call site: `GenerateProProofResponse` can only be built by parsing raw backend bytes, and there is still no `MockSessionProManager`.
Bilb
approved these changes
Sep 15, 2026
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
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.
The Pro badge is off by default, so a new subscriber had to find the toggle in Pro settings before anyone could tell they had subscribed. Desktop has done this since
266ac2c9e("setProBadge on when recovering pro without swarm config"); this is the same behaviour on iOS, client-side only.The guard is "has this account ever held Pro", not "does it hold Pro now"
The obvious reading — enable the badge whenever Pro becomes active — is wrong in a way that is easy to ship and annoying to diagnose: a subscriber who deliberately turns the badge off has it turned back on at every proof renewal, with no way to make the choice stick. Being visible as a subscriber is the user's call, which is why the badge is off by default in the first place.
So the condition is all three of
proConfig,proAccessExpiryand the profile-feature bitset being absent, matching Desktop.proAccessExpiryis the value doing the real work: a lapsed plan has its proof cleared but keeps its expiry, so that expiry is what separates a returning subscriber from a first-time one.hasNeverHeldProis read inside the samemutate(cache:)that writes the proof and the expiry, and before either of them — two of the three values it asks about are things that write is about to change.The badge write
applyProofSuccessalready ended withProfile.updateLocal(proFeatures:); it now passes.inserting(.proBadge)on a first-ever proof. That is the same route the Pro settings toggle uses (Profile.updateLocal→Profile.updateIfNeeded→cache.updateProfile→user_profile_set_pro_badge), so there is no second writer for the badge and no new cache API.A linked device is unaffected — it takes the badge from the user-profile config it merges, and that config's proof or expiry fails the guard in any case. A device that syncs a config with the badge off keeps it off.
Testing
ProBadgeFirstProofSpec— 4 tests, all passing, and proven to fail: forcinghasNeverHeldPrototruefails 3 of the 4 (a stored proof, a surviving access expiry, an existing profile feature). Those three are the regression.SessionMessagingKitTests: 597 passed, 0 failed, 0 restarts — the 593 baseline plus these 4. Run through theSessionscheme with-parallel-testing-enabled NO, since theSessionMessagingKitscheme can't resolve itsWebRTCdependency.One gap, stated rather than papered over: the spec covers the decision, not the call-site wiring.
Network.SessionPro.GenerateProProofResponsehas onlyinit(parsing: Data)over raw backend bytes and there is noMockSessionProManager, so exercisingapplyProofSuccessend-to-end would mean crafting a signed backend response. The Android companion does cover placement, because there the badge write sits inside the tested seam.Companion Android change: session-foundation/session-android#2214.