We had 2 devs working on the same App (Retool Cloud version). One of them lost all of their work. We were extremely surprised by that behavior.
It is ok that Retool does not support simultaneous editing (this is not a bug). It is not ok for work to be lost (I consider this a bug). I'm aware that there are support tickets about this already (1)(2) but they did not lead to a solution or any recommendation. I expect some sort of lockout screen when trying to edit an app that somebody else is already editing to make sure this event does not happen. I also posted under "feature requests".
Since edit sessions can be very long (especially if some developer forgot an open tab!), a huge amount of work can be lost by this.
To explain why I consider this a bug, an illustration:
time: ------------------------------------------------------------------------>
_____________________
/ \
dev B: (edit-B) (publish-B)
published version: ---------------------------------------------------------->
dev A: (edit-A) (publish-A)
\________________________________________/
As far as I'm aware, dev B's changes will be lost completely. You can revert to the point in time called "publish-B" but then dev A's changes will be lost and there's no easy way to reimplement them other than actually reimplementing them. In any case, a developer's work has been completely lost and we need to reimplement it.
What are the best practices to avoid this? How can my devs make sure that when they're clicking "edit" they're on the latest published version in order to make sure they won't accidentally revert parts of the app to the last point in time when they clicked "edit"?
Hi @ypeled! Thank you for sharing this here for other users to chime in, and thank you for providing so much context around why this is impactful. I reached out to eng with this post, and we'll be tackling this in 2022!
I'll chime in here as well to just reiterate everything that @ypeled said. My team has had exactly the same issues arise and recently lost two days worth of work on a very time sensitive matter where we somehow weren't even able to fix by reverting to a point in time where the major changes had been made. And I don't mean to make this seem like a threat in any regard, but the issue is big enough that my team is now considering taking our business elsewhere because we can't deal with this again.
Hi @bryan, all of that is absolutely valid. I brought this up with the Support team (to gather context on any other users they've spoken with) as well as the Product and Eng teams. Actually building out multiplayer functionality is going to be a large lift and will take time, but it will get worked on! In the meantime, we're planning on some sort of notification system to let users know that we don't support multiplayer to at least stop the overriding before it happens.
I'm sorry for all the time this has taken from your team. As a potential thought, do you see anything in the the three dots > Releases and History > History tab?
That isn't happening to all of our apps, though. I checked a couple others and they show the proper history. For some more context, the app in question here is our largest app that we've had up and running since we first started with Retool but has just grown increasingly complex over time.
Agh, I'm sorry about that. While we won't be able to ship any big fixes anytime soon, this is absolutely being planned for and we'll do what we can in the interim to prevent loss of work (e.g. notifying and warning users when there are multiple editors on a single app).
