Skip to content

[Conditions] Update JSON keys#3168

Merged
vegaro merged 2 commits into
cesar/conditional-configurabilityfrom
cesar/update-condition
Mar 4, 2026
Merged

[Conditions] Update JSON keys#3168
vegaro merged 2 commits into
cesar/conditional-configurabilityfrom
cesar/update-condition

Conversation

@vegaro

@vegaro vegaro commented Mar 3, 2026

Copy link
Copy Markdown
Member

Updates conditions to not reuse the old intro_offer and promo_offer ones. This way old SDKs behave as expected when a newer paywall with conditions sends some of the new ones.


Note

Medium Risk
Medium risk because it changes condition JSON deserialization keys and runtime evaluation for offer-based overrides, which could cause overrides to stop applying if payloads or clients are mismatched. Backward compatibility is partially maintained for legacy intro_offer/promo_offer objects, but new payloads must use the renamed *_condition types.

Overview
Updates the paywall override condition schema to avoid reusing legacy condition keys. intro_offer/promo_offer are now plain boolean conditions (no operator/value), while new types intro_offer_condition and promo_offer_condition carry operator + value.

Renames the JSON type keys for parameterized conditions from selected_package and variable to selected_package_condition and variable_condition, and updates ConditionSerializer mappings plus UI-side condition evaluation to match. Tests are adjusted to cover legacy payload tolerance (extra fields ignored for intro_offer/promo_offer) and the new *_condition types.

Written by Cursor Bugbot for commit 918d463. This will update automatically on new commits. Configure here.

@facumenzella

Copy link
Copy Markdown
Member

The backward-compat scenario that motivates this PR — old-format JSON like {"type": "intro_offer", "operator": "=", "value": true} hitting the new IntroOffer object serializer and silently dropping the extra fields — isn't explicitly tested.

This works because ignoreUnknownKeys = true in the Json config, but if that ever changed or someone refactored the serializer, there'd be no test to catch the regression.

Same gap for promo_offer with extra fields.

Opened #3172 against this branch adding those tests.

…#3172)

## Summary
- Adds tests verifying that old-format JSON with extra
`operator`+`value` fields (e.g. `{"type": "intro_offer", "operator":
"=", "value": true}`) correctly deserializes to the plain
`IntroOffer`/`PromoOffer` objects, silently ignoring the extra fields.
- This is the key backward-compat scenario that #3168 exists to solve,
and it wasn't explicitly tested.

## Test plan
- [x] `ComponentOverridesTests` pass

🤖 Generated with [Claude Code](https://claude.com/claude-code)

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Low risk: test-only change that adds coverage for backward-compatible
JSON deserialization behavior without modifying production code.
> 
> **Overview**
> Adds parameterized test cases in `ComponentOverridesTests` to verify
backward compatibility: legacy `intro_offer`/`promo_offer` condition
JSON that includes extra `operator`/`value` fields is accepted and
deserializes to `Condition.IntroOffer`/`Condition.PromoOffer` (silently
ignoring the extra fields).
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
2a1a829. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

@cursor cursor Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

@facumenzella

Copy link
Copy Markdown
Member

Nit (pre-existing, not introduced by this PR): the Unsupported -> false branch in PresentedPartial.kt:118 is dead code. toPresentedOverrides() already bails with a PaywallValidationError.UnsupportedCondition error if any condition is Unsupported (line 68), so evaluate() can never be called with an Unsupported condition at runtime.

Not a blocker, but worth a comment or a TODO if it's intentional defense-in-depth.

@facumenzella facumenzella left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Let's try this out!! a few nits

@vegaro

vegaro commented Mar 4, 2026

Copy link
Copy Markdown
Member Author

Nit (pre-existing, not introduced by this PR): the Unsupported -> false branch in PresentedPartial.kt:118 is dead code. toPresentedOverrides() already bails with a PaywallValidationError.UnsupportedCondition error if any condition is Unsupported (line 68), so evaluate() can never be called with an Unsupported condition at runtime.

Right, that's changing and not going to Unsupported so it will change

@vegaro vegaro merged commit d26ef51 into cesar/conditional-configurability Mar 4, 2026
7 of 8 checks passed
@vegaro vegaro deleted the cesar/update-condition branch March 4, 2026 11:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pr:fix A bug fix

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants