fix(memberships-sync): handle active subs from other nodes

[adekbadek]

All Submissions:

• Have you followed the Newspack Contributing guideline?
• Does your code follow the WordPress' coding standards and VIP Go coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

Adds handling of the following edge case: a user might have two separate subscriptions on two sites of the network, both granting the same (synchronized, that is!) membership. If one of these subscriptions is cancelled, but the other one still active, the membership should still be active.

See https://app.asana.com/0/1206478771616338/1207029554091953/f

How to test the changes in this Pull Request:

1. Buy a synced-membership-granting subscription on two sites of the network, using the same email address
2. As the site admin, cancel one of the subscriptions
3. Observe that the memberships are still active on both sites

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully ran tests with your changes locally?

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1207832962147246

[leogermani]

HI Adam, I would add a comment similar to what I did on #112 (review).

Is there a reason why we have to make all these requests on the fly and can not rely on synced data?

[adekbadek]

Thanks @leogermani – I completely agree that a better solution is to rely on synchronised data instead of an on-the-fly lookup in this case. However, this fix is needed pretty urgently (#112 is not). Can we ship this if it works, and I'll work on optimising the strategy in a later PR?

[leogermani]

@adekbadek I could not confirm the fix. Both on trunk and on this branch I got the same behavior. Here are detailed steps of what I did

• As an anonymous visitor I visited the Hub and bought the subscription
• I confirmed the membership was granted to the user
• I saw the user propagate to the Node and the membership being granted there as well
• As an anonymous visitor I went to the Node and bought the subscription that would grant me access to the same membership
• I waited for the data to propagate.
• I went to the Hub admin panel and Cancelled the Subscription. It went to "pending cancellation" state
• I confirmed the Membership also went to "pending cancellation"
• I checked on the Node, and the Membership was also marked as Pending cancellation

Also, when I tried to "Cancel now" the subscription, I got

PHP Fatal error:  Uncaught TypeError: array_merge(): Argument #2 must be of type array, null given in /newspack-repos/newspack-network/includes/hub/class-network-data-endpoint.php:60

[leogermani]

In another attempt, I tried to:

• Deactivate the Network plugin on both ends before buying the subscription
• Making sure I had a membership active in both sites, and they were each "native" membership, meaning they were not synced from other site
• Then I reactivated the Network plugin and proceeded the cancellation
• Got the same results

[adekbadek]

Thanks for the thorough testing! I was making a shortcut in my testing, not realising it influences the code behaviour. What I was doing was creating both subscriptions simultaneously, which had the effect of creating "standalone" memberships on both sites. Your testing scenario, much more real-world, ensures the second memberships is not "standalone" but synced from the Hub site.

This should be fixed in b7d897b.

[leogermani]

ok, it mostly works, there are edge cases and observations, but I'm not sure we want to address them all. Maybe we move forward and work on dealing with them in the definitive fix.

I tested:

• Creating the subscription on the Hub and propagating it to the Node
• Creating the subscription on the Node and propagating it to the Hub
• Create both subscriptions at the same time with the plugin deactivated, so they are both "standalone"

In all cases, when you cancel the membership, it's not cancelled in the other site, as expected, and the Note is added to the membership saying why it's still active. BUT, the membership is set to "Pending Cancellation" when the subscription is set to this status. And then they remain pending after the subscription is cancelled (maybe we don't want even to set them as pending)

After cancelling the subscription in the site the membership was originally created, if you go to the other site, where the membership was propagated to, and cancel the subscription, it won't cancel the membership (as it should, because now there is no longer any active membership). This happens because in that site, the Membership is not tied to any subscription or product.

When the membership is standalone in both sites, things work as expected. Only the "Pending Cancellation" behavior still happens.

lmk if you want to move forward

[adekbadek]

Thanks again for reviewing this thoroughly! Let's move forward with this as it's now and address the edge cases in the optimised (synced data reliant) solution.

[matticbot]

🎉 This PR is included in version 1.11.0-alpha.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[matticbot]

🎉 This PR is included in version 2.0.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀