Exploration: Application logic for member downgrades

### Is /item/remove async or sync?

Application is treating `/item/remove` as sync. On Plaid docs, there are no mentions of background processes that will run upon calling the endpoint at Plaid side.

### If a member downgrades, confirm that Application does not call the Data Source pending fees endpoint.

Scenarios when Application call DS for pending fees:

- Showing pending fees in UI
  - Need to add membership Guard in `fees/pending-accounts` endpoint.
- Weekly insights
  - Need to add check for premium
- Scan complete
  - Currently there is no check in place at Webhook id: `accounts-by-email.spec.open-banking.recurring-fees.message/scan - COMPLETED`
  - Confirm webhook won't be fired if user is basic.
  - If webhook fired determine how to handle for fees scan complete.
- Log fees scan complete meta
- Send fees scan complete email

```
Files name for dev reference:
- fetch-pending-fees-accounts
- command/handler/send-email-insights-by-user line no: 915
- email-fees-scan-success
- log-fees-scan-result
```

### What does Application do with old Plaid Item IDs?

Application does remove the Plaid Item/Account from the database after confirmation from `/item/remove`

> HOWEVER, we have had problems with debugging Plaid webhook requests in the past because of missing data in the database. So this is probably not
> wise. Please analyze this situation and propose a solution.

There is a database table named `activity` where we can save some metadata whenever a plaid item removal event happens. The table has following columns:

- Id
- userId
- Message
- Event
- Metadata
- createdAt
- updatedAt

### Are there any gotchas for async (newsletter) processes?

Right now there are none. But once we introduce Scan Gate or one inbox per basic account at that point we might have such scenarios.