Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: Update Omnichannel's room closing mechanism to use transactions. #32896

Merged
merged 19 commits into from
Aug 22, 2024

Conversation

KevLehman
Copy link
Contributor

@KevLehman KevLehman commented Jul 24, 2024

Proposed changes (including videos or screenshots)

  • Use a transaction for closing omnichannel conversations. This will prevent rooms being on an invalid state and every time something happens it will allow users to retry.
  • Currently, transaction covers only the core room closing mechanism. Sending a livechat-close message after the room is closed is not part of the scope (mainly because of the involved code changes to make all callbacks accept a session.
  • When a transaction is aborted, user will receive a generic error message asking to try again.
  • MongoDB transactions have its own quirks, so it was kept to the minimum amount of db calls for this time.

Issue(s)

https://rocketchat.atlassian.net/browse/CORE-238

Steps to test or reproduce

Further comments

Copy link
Contributor

dionisio-bot bot commented Jul 24, 2024

Looks like this PR is ready to merge! 🎉
If you have any trouble, please check the PR guidelines

Copy link

changeset-bot bot commented Jul 24, 2024

⚠️ No Changeset found

Latest commit: d3caae8

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link

codecov bot commented Jul 24, 2024

Codecov Report

Attention: Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.

Project coverage is 59.38%. Comparing base (f6351e8) to head (d3caae8).
Report is 1 commits behind head on develop.

Additional details and impacted files

Impacted file tree graph

@@             Coverage Diff             @@
##           develop   #32896      +/-   ##
===========================================
- Coverage    59.39%   59.38%   -0.01%     
===========================================
  Files         2547     2547              
  Lines        63241    63241              
  Branches     14223    14225       +2     
===========================================
- Hits         37559    37558       -1     
- Misses       22974    22975       +1     
  Partials      2708     2708              
Flag Coverage Δ
unit 75.84% <0.00%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

@KevLehman KevLehman marked this pull request as ready for review July 25, 2024 19:24
@KevLehman KevLehman requested review from a team as code owners July 25, 2024 19:24
ricardogarim
ricardogarim previously approved these changes Jul 29, 2024
Copy link
Member

@MarcosSpessatto MarcosSpessatto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't like to start to spread MongoDB (or any other DB) transaction mechanism into business rules code, this could open a wormhole to dark places, but I understand your point here. For this specific case I'm okay with it, but for sure we need a more concrete and robust solution for using DB transactions.

@KevLehman
Copy link
Contributor Author

Yup, kinda the same shared on the chapter. This facilitates this specific problem but it can create new ones (hopefully not).

We would need to check on how this behaves during testing to ensure it won't add more problems than it solves.

And ideally, we would have a nicer api for dealing with this after mongo3 (where we can have some async storage that allows to pass data down to the models without editing the whole chain).

ricardogarim
ricardogarim previously approved these changes Jul 29, 2024
@jessicaschelly jessicaschelly added the stat: QA assured Means it has been tested and approved by a company insider label Aug 6, 2024
@dionisio-bot dionisio-bot bot added the stat: ready to merge PR tested and approved waiting for merge label Aug 6, 2024
sampaiodiego
sampaiodiego previously approved these changes Aug 9, 2024
MartinSchoeler
MartinSchoeler previously approved these changes Aug 12, 2024
@dionisio-bot dionisio-bot bot removed the stat: ready to merge PR tested and approved waiting for merge label Aug 12, 2024
@KevLehman KevLehman added the stat: ready to merge PR tested and approved waiting for merge label Aug 19, 2024
sampaiodiego
sampaiodiego previously approved these changes Aug 21, 2024
@kodiakhq kodiakhq bot removed the stat: ready to merge PR tested and approved waiting for merge label Aug 22, 2024
Copy link
Contributor

kodiakhq bot commented Aug 22, 2024

This PR currently has a merge conflict. Please resolve this and then re-add the ['stat: ready to merge', 'automerge'] label.

MartinSchoeler
MartinSchoeler previously approved these changes Aug 22, 2024
@KevLehman KevLehman added the stat: ready to merge PR tested and approved waiting for merge label Aug 22, 2024
@kodiakhq kodiakhq bot merged commit be5d153 into develop Aug 22, 2024
49 checks passed
@kodiakhq kodiakhq bot deleted the chore/transactional-room-closing-omni branch August 22, 2024 20:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stat: QA assured Means it has been tested and approved by a company insider stat: ready to merge PR tested and approved waiting for merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants