user.subscriptionStatus disappears when you have more than one version of your extension, and it stays disappeared.
philipmulcahy opened this issue · 10 comments
Describe the bug
ExtPay's user.subscriptionStatus goes awol when you install a local version of the extension on a user's machine, and removing the additional copy doesn't seem to fix things.
To Reproduce
Install extension that uses ExtPay subscriptions.
Subscribe
All is good
Install a local copy of the extension (such as a test build provided for UAT/feedback purposes)
paid-for features are disabled, even though the ExtPay UI claims you have paid.
Debugging of extension shows that user.subscriptionStatus has disappeared, while user.paid is still true (see debugger screenshot including console dump of a user object).
Uninstall the local copy doesn't help
Reinstalling the store copy doesn't help either.
Expected behavior
ExtPay should work on both copies (perhaps with login workflow)
Different extension installs should not interfere with each other.
Screenshots
Desktop
- OS: Windows 11, MacOS 13.4
- Browser: chrome
- Version: 114.0.5735.106
Additional context
I've changed my predicate from user.subscriptionStatus == 'active' to user.paid, which seems to work for now, so not necessarily urgent.
It'd be useful to have a work-around in your API that zaps ExtPay's locally stored state - I already have a logout button for other (non ExtPay) login-state, and calling such an ExtPay function would not make my UI more complicated.
from my extension's popup, I tried:
['extensionpay_api_key', 'extensionpay_installed_at', 'extensionpay_user'].forEach(k => chrome.storage.sync.remove(k))
on a browser login that's paid up as a normal user,
and then logged in again and took a look at sync storage:
"key": "extensionpay_user",
"value": "{\"email\":\"XXX@gmail.com\",\"installedAt\":\"2023-06-18T20:42:35.479Z\",\"paid\":true,\"paidAt\":\"2023-06-18T20:43:13.309Z\",\"trialStartedAt\":null}"
This ^ looks the same (no subscription info) as it did before zapping the entries.
On a "healthy" deployment (one that has not gone through the parallel installation and/or reinstallation), I see this:
"key": "extensionpay_user",
"value": "{\"email\":\"YYY.org\",\"installedAt\":\"2023-06-02T17:17:22.630Z\",\"paid\":true,\"paidAt\":\"2023-06-04T19:57:15.861Z\",\"subscriptionCancelAt\":null,\"subscriptionStatus\":\"active\",\"trialStartedAt\":null}"
a quick search of this repo suggests that the code that sets subscriptionStatus is not shared, so I think the ball's in your court
@Glench I confirm the issue. I've got a local (and only) installation of my extension and recently, in user object I'm getting no subscriptionStatus property, even though paid is true.
Maybe Chrome update is to be blamed?
I haven't been able to look more deeply into this yet, but no data is shared between extensions in the user's browser.
In your reproduction steps, you didn't say whether you used your developer credentials to activate the extension or your paid "login" credentials that you used when paying in your production-version extension. Could you please share what you did in your local extension version?
@Glench In my case, I have only the local extension version, no production version yet. I am using developer credentials to activate subscription.
I'm pretty sure this is related to #148. It's a caching issue that I've fixed in staging but will wait till the weekend to deploy to affect the minimal number of users.
OK, this was released Saturday morning US/ET time. Closing as resolved until I hear otherwise.