Make sure to check recipient can be charged for memberships #2174

Ticket(s)

#2174 (closed)

Summary of Changes

Previously we were checking only if the sender was banned, enabled or deleted before charging membership, because the issue that presented its self required us to prevent charges from being made from banned, enabled or deleted users.

With #2174 (closed), it's actually the recipient is banned, enabled or deleted, thus our code didn't cover it. This MR extends the logic so we check both the sender and recipient, and refactors a little to make it read cleaner.

Testing Considerations

This is going to be hard to test - access will be needed to our sandbox k8s cluster.

Prep

Given 2 users, A and B (They should both be new users as we will be deleting them)

1. Make a membership tier with A for tokens.
2. Edit the membership tier with A - dig though the XHRs and look for the endpoint you're posting to - in either the URL, request params or response there is a URN - make a note of it.
3. Subscribe to the tier it with B - you may be able to find the URL by looking at the request made here too.
4. Get the GUIDs of the sender and recipient from api/v1/channel/[[username]] and make a note of them - ensure you have them labeled correctly.

Resetting the state

One charge has been made already when subscribing so we need to clear the slate, as we're going to manually run the payments runner and watch the output in the next step.

1. Run the below

kubectl exec -it cassandra-0 sh`
cqlsh
EXPAND ON;

2. Run this command, replacing the entity_guid with the recipient, user_guid with the sender, and subscription_id with the URN - this will make it so that subscription is ready to be charged again and can be repeated after every test.

UPDATE minds.subscriptions SET next_billing=1609940821, status='active' where plan_id='wire' and payment_method='tokens' and entity_guid=1325809302358724617 and user_guid=1285556899399340038 and subscription_id='urn:subscription:offchain-1285556899399340038-1325809302358724617';

3. If you want to actually check the update worked, you can check like this and filter it down appropriately

select * from minds.subscriptions where plan_id='wire' and payment_method='tokens';

Running the runner

1. In another shell - run the below

kubectl get pods | grep banned-sub # Copy the php pod name to your clipboard
docker-compose exec -it [[pod name]] sh
cd engine
php cli.php payments subscriptions run

2. You should see output as it connects to pulsar - this will only happen if its running the sub - look through the logs and ensure you see no messages about the user being deleted.

3. Deactivate the user, repeat steps 2 and 3. You should see a message about pulsar about the user not being enabled.

4. Ban the user, repeat steps 2 and 3 then unban. You should see a message about pulsar about the user being banned.

5. Delete the user, repeat steps 2 and 3. You should see a message about pulsar about the user being deleted.

6. For bonus points repeat 2 and 3 but for user A being the deactivated account.

Regression Scope

(Can this change cause another regression issue? Which areas to focus for regression testing?)

Platform Affected (web, mobile, etc)

Background runner in the engine, doesn't effect any UI

Developer Testing Completed

Specs

Screenshots

N/A

Does this impact

• Localization
• Dark/light mode
• Guest mode