The last refactor of the save process (0fdb70ce669838f9fd66eb5de570ffde78e3653d) has introduced a bug: the save flow was not more stopped when a layer fail to save. This ends with a broken UI, as the map is not dirty anymore, so the save button is not active anymore, while at least one layer still needs to be saved.
Save can fail in two scenarios:
there is a conflict (status 412)
the server is down or as an issue (eg. disk is full)
I tried a more modest scenario (listening for status in map.save and recallign the map save after a conflict), but this ended with calling map.save uselessly even more.
So I decided to try this refactor, which also totally remove the useless map.save we were sending at each save until now.
The last refactor of the save process (0fdb70ce669838f9fd66eb5de570ffde78e3653d) has introduced a bug: the save flow was not more stopped when a layer fail to save. This ends with a broken UI, as the map is not dirty anymore, so the save button is not active anymore, while at least one layer still needs to be saved.
Save can fail in two scenarios:
I tried a more modest scenario (listening for status in map.save and recallign the map save after a conflict), but this ended with calling map.save uselessly even more.
So I decided to try this refactor, which also totally remove the useless map.save we were sending at each save until now.