Previously Added Logic Was Reverted

Hello everyone,

We have a method that was updated last week, but some logic changes were reverted.
Please let me know if you have any questions or need further clarification.

App ID: 4A47197B-AE30-FA84-FF56-0071F4010900
Method Name: Send_SMS_Conference

Affected logic

Thank you

Hi Francis,

What is the name of the service that contains the method?

Regards,
Mark

Hi Mark,

BG_21_Microschool.

Hi Francis,

I checked the activity log and I see multiple instances where the service is regularly updated by you and Kean, at times within 25 minutes between the updates (on March 2nd for example) - see the screenshot below. If the service logic is fetched by Kean before you deploys the changes, then Kean’s changes will overwrite yours. This is what most certainly caused the "logic changes reversal’.

Both you and Kean should have log of codeless changes on your corresponding machines. You should be able to use it to understand when the overwrite happened.

Regards,
Mark

Hi Mark,

Whenever we need to update a method in a service and someone else is already working on that specific service, we receive an alert like this. In that case, we usually wait for the other user to finish their update and save their progress before another user starts editing.

As for the log of codeless changes, I’m not sure which one you are referring to, but there is a changelog in each method. However, the log gets removed after some time.

Thank you so much for checking!

Hi Francis,

I am glad you worked out a policy for collaborative editing. Indeed, it is important to make sure you’re not stepping on each other toes while working on the same service (i.e. deployment model). My recommendation is whenever someone takes over a service, make sure to completely reload the console to ensure you have the latest changes from the server. Otherwise, the following may happen:

  1. engineer A starts working on a service
  2. engineer B tries to open the same service for editing (see the warning above and waits)
  3. engineer A deploys the service and informs B about it
  4. engineer B starts editing

The problem here is that engineer B is looking at the version of the service that does not have changes from engineer A. As a result, any changes deployed in step 3 will be wiped out when engineer B deploys theirs.

Regards,
Mark

Got it. Thank you!