feat: Support logical deletion within APIs

[Vasilijez]

Closes #15.

Also, check book-em/user-service#40 for more information.

Part of:

• Feature delete user complete web-app#42
• feat: Support logical deletion within APIs #24
• Feature delete user complete user-service#40
• Feature delete user complete room-service#32

[magley]

Scenario:

• Guest G creates a reservation request
• Host H opens the reservation requests page
• G deletes his account
• H clicks on the "approve" request
• A reservation is made even though the user deleted his account

From what I can tell, this is a more subtle bug, because normally when you fetch reservation requests, you exclude ones from deleted users. But this is a sort-of concurrent edge case, because the host fetches requests BEFORE the user deletes his account, and accepts the request AFTER the user deletes his account.

I've left this review as a [Comment] instead of [Request changes] because while I believe this should be addressed, it's up to you whether you should actually do it. It's not much work, though, just fetch the user and check the Deleted field.

This got me thinking: how did this happen? The fault in the code is that we don't fetch the user before approving the request, and this is present elsewhere in the architecture. If this were a monolith, the database would "catch" the issue because of foreign keys (assuming we'd do physical deletes).

[Vasilijez]

Scenario:

• Guest G creates a reservation request
• Host H opens the reservation requests page
• G deletes his account
• H clicks on the "approve" request
• A reservation is made even though the user deleted his account

From what I can tell, this is a more subtle bug, because normally when you fetch reservation requests, you exclude ones from deleted users. But this is a sort-of concurrent edge case, because the host fetches requests BEFORE the user deletes his account, and accepts the request AFTER the user deletes his account.

I've left this review as a [Comment] instead of [Request changes] because while I believe this should be addressed, it's up to you whether you should actually do it. It's not much work, though, just fetch the user and check the Deleted field.

This got me thinking: how did this happen? The fault in the code is that we don't fetch the user before approving the request, and this is present elsewhere in the architecture. If this were a monolith, the database would "catch" the issue because of foreign keys (assuming we'd do physical deletes).

Thanks, I appreciate it. Really nice catch, I solved it. 33e7aac

[magley]

Seems OK now.