fix: fix error when updating Telegram ID for an existing phone number

[zwliew]

Problem

Closes issue #1143

Solution

Bug Fixes:

• Try updating either phone number or telegram ID. If no update occurs, insert a new row.

Tests

These tests have been verified on staging.

Users should be able to update telegram ID for an existing phone number

1. Change your telegram_id to a different number in the telegram_subscribers table.
2. Run the /updatenumber command on the Telegram bot
3. The bot should say Your phone number and Telegram ID have been updated. and telegram_id should be updated in the telegram_subscribers table.

Users should be able to update phone number for an existing telegram ID

1. Change your phone_number to a different number in the telegram_subscribers table.
2. Run the /updatenumber command on the Telegram bot
3. The bot should say Your phone number and Telegram ID have been updated. and phone_number should be updated in the telegram_subscribers table.

Users should be able to create a new telegram_subscribers row

1. Delete the row corresponding to your account in the telegram_subscribers table.
2. Run the /updatenumber command on the Telegram bot
3. The bot should say Your phone number and Telegram ID have been updated. and there should be a new row reflecting your phone_number and telegram_id in the table.

[zwliew]

I thought of one additional edge case when thinking about the fix. However, given that it sounds like a really rare scenario, it might not be worth handling it.

Imagine this scenario:

There are 2 rows in the telegram_subscribers table.

phone_number	telegram_id
A	000
B	111

What if a user tries to update with the following parameters: phone_number=B, telegram_id=000?

I couldn't think of a clear cut answer. One solution would be to delete one of the rows and update the other. Another would be to treat both rows as the same and merge them.

Steps to achieve this scenario:

1. A user creates 2 Telegram accounts and subscribes them to the bot as shown above.
2. Then, the user with telegram_id=111 changes their phone_number to C on Telegram only. But, the user doesn't update this in Postman. Now, there is a desync between Postman's telegram_subscribers table and the canonical Telegram mapping.
3. Lastly, the user with telegram_id=000 changes their phone_number to B. This time, the user runs /updatenumber to update Postman. However, since phone_number=B and telegram_id=000 both already exist in the table as 2 separate rows, this is an issue. It is unclear which row to update, and which row to delete/merge, in order to maintain uniqueness of the keys.

Decision
Ignore. This scenario will result in an error and will be caught by Sentry, so we'll be able to resolve it manually should we face it.

[lamkeewei]

I thought of one additional edge case when thinking about the fix. However, given that it sounds like a really rare scenario, it might not be worth handling it.

Imagine this scenario:

There are 2 rows in the telegram_subscribers table.

phone_number telegram_id
A 000
B 111
What if a user tries to update with the following parameters: phone_number=B, telegram_id=000?

I couldn't think of a clear cut answer. One solution would be to delete one of the rows and update the other. Another would be to treat both rows as the same and merge them.

Steps to achieve this scenario:

1. A user creates 2 Telegram accounts and subscribes them to the bot as shown above.
2. Then, the user with telegram_id=111 changes their phone_number to C on Telegram only. But, the user doesn't update this in Postman. Now, there is a desync between Postman's telegram_subscribers table and the canonical Telegram mapping.
3. Lastly, the user with telegram_id=000 changes their phone_number to B. This time, the user runs /updatenumber to update Postman. However, since phone_number=B and telegram_id=000 both already exist in the table as 2 separate rows, this is an issue. It is unclear which row to update, and which row to delete/merge, in order to maintain uniqueness of the keys.

I think this seem reasonably rare that we don't have to handle it.