I have submitted a bug that causes issues in a live app I pay a subscription for the professional tier about 47 hours ago. The four videos I created to help support the investigation still have not been viewed.
How long does support normally take before they begin looking at the submitted bug reports. This is for Bug report #113717 @Roody_BubbleSupport could you take a look at what might be causing the delay in the investigation getting underway?
Thatâs not cool @Bubble.
so update to this. It seems that Bubble engineering believes it is okay to delete the pages from our apps without our input.
It should not make any difference whatsoever what actions a user took prior to initiating the forced sync function when we wish to deploy to live, the system should not be deleting pages from our development versions.
It is a simple fix, there are two classifications, conflicting or non-conflicting changes. Non-conflicting changes we as the user have no control over whether or not to bring the live version differences into our development version, which means any differences are automatically brought in without user control, which on the whole is fine. Conflicting changes are those that seem important or substantive enough to warrant user input in the process to decide whether or not to keep the live version or the development version.
The problem is when a page that is considered âremovedâ is classified as a non conflicting change and the user can do nothing about whether or not Bubble is going to delete the page from their development version. This should NOT be the case. A page that is considered âremovedâ should be a Conflicting change. This is just simple logic. Do not delete the pages in the app without the users input. How is this difficult to grasp?
I had a development version. Deleted some pages in progress to launch live. After deploying to live I reverted my development back to the save point to reinstate my deleted pages. Now, when I want to deploy to live, those pages are being deleted by the sync process as they are classified as non-conflicting changes.
Bubble support response:
After talking to engineering, I can confirm that having these pages deleted is still currently expected behavior. If you want this to be changed, I would recommend posting on the ideaboard as that is the best way to have changes like this noted for our product team in their planning.
How about Bubble just hires a User Experience expert who can be there to step in and help engineering understand that although they may have built something to work a certain way, if it leads to poor user experience, it should be altered to provide a better user experience and perhaps have the intended/expected behavior be more inline with their users intended/expected behaviors rather than that of the engineer who implemented the feature.
@nick.carroll @Roody_BubbleSupport @josh This is part of the reason why it is becoming exhausting to have to report bugs. Actual bugs are often enough (not always but often enough), being met with no remorse of the issues they cause (because of a clear reluctance to fix them), and often result in further frustration due to lack of resolution from Bubble. It erodes confidence in the platform and creates a sense of disaffection of the community members that routinely go out of their way to report bugs in attempts to improve the platform for their benefit, other users benefits and Bubbleâs benefit.
I am glad that after the work around provided by support (quoted below) was first presented to me, I pushed back on the support agent to ask what Bubble is going to be doing to resolve the issue so it doesnât affect other users, because it seems like after they finally spoke to engineering concerning the issue, a better work around was presented, and although the work around will suffice for my situation at present, it still does not address the underlying cause of the issue so as to not cause a negative impact on other users, cause a loss of time for other users and utilize the resource of support to assist those other users who may be affected in the future.
First workaround (couple of hours of my time likely):
The best workaround at this point would be to make a new branch that is what you currently have in development main, then sync main to live which will delete those pages. Once that has been done however, you can move those pages back to main and will then be able to deploy them to live. In order for that to work, they do need to be made as new pages, because those pages will be recognized as âdeletedâ on the main branch and wonât get moved onto main even if you try to merge changes from your branch to main. There are two main ways to do this:
Go to your new branch use command-c to copy the page, go to your main branch command-v and use the pop-up to say yes make a new page, and repeat for all pages.
Go to your new branch, click âmake a new pageâ use the âclone from pageâ, and pick which page you want to clone. Do this for all pages, then go to âmainâ click âmerge changes from your new branchâ and all these pages will appear.
Once these new pages have been added, identical to the old ones but not connected to the versions that had been on main and live, you will be able to deploy to live without getting a notification that main is âout of sync.â
Second workaround (easy enough):
if you were to make edits to the pages after having restored them, they would then be conflicting changes as opposed to non-conflicting. Non-conflicting changes are for any instance where one branch has added/edited/or deleted an element with none of those things happening on the other, so this does fall within what is currently classified as a non-conflicting change.
One thing to point out here is the LOGIC of the workaroundâŚit states that that a Non-Conflicting change is when anything has been added/edited/or deleted on one branch but not another (basically something was changed?)âŚso everything you do in development that is not done in your live would be classed as non-conflictingâŚso than what is a conflicting change?
I try to understand the world around me through logic. When things to me do not seem logical it is difficult for me to accept and understand. Would anybody be able to logically explain to me what would be the definitions of a non-conflicting and a conflicting change, so as I could understand and accept that a page that is not in the live, but is in the development would be classified as a non-conflicting change resulting in the deletion of the page from the development version of the app?
Iâm sorry to hear that you faced so many issues dealing with these pages being deleted outside of your control. Jumping in to explain what makes a conflicting vs non-conflicting change.
In short, a conflicting change is when the same thing changes differently in two branches. For example, lets say I have a button that exists in both branch A and B. I change the color of the button to Red in branch A and Blue in branch B. Now, if I merge one branch into another, the version control system doesnât know which change to move forward with, so it raises a conflicting change for user input. If I only changed the button color in one branch, and didnât touch it in the other, it would be a non-conflicting change.
Now lets extend this to a page. If the same page exists in two branches, and in one branch I delete the page, and the other I donât touch it at all, this would be considered a non-conflicting change, because it was only changed in one branch. If I deleted the page in one branch, and then made an edit on that page in the other branch, this would now be a conflicting change because which change do you want to keep? The instance where you edited the page or the instance where you deleted it?
Live is essentially no different than any other branch, its just the version of your app that exists in production. So, in your case, it sounds like you deleted pages (lets call this point A) and then deployed the changes (including the deleted pages) to Live. Then, you reverted your branch back to before Point A to recover the deleted pages. At this point, development is out of sync with Live, so the branch must be syncâd with Live before you can deploy. During the sync, the deleted pages are not recognized as a conflict because Live does not have the pages, and Main is considered behind Live, so the sync, or merge, moves forward with assuming the page deletion was intentional.
This being said, the exhibited behavior is consistent with how the merge algorithm works everywhere else. I do however, see why this is frustrating because its not super clear why the sync would be undoing the branch reversion, and its not very obvious how to make it not do that.
As far as moving forward, it sounds like the second workaround, just make a small edit to the page that was deleted, is sufficient for now. And then from a product perspective, the ability to review all changes, not just conflicts, would have prevented this?
Let me know if this is helpful or if I can expand on anything.
Thank you for the explanation, and jumping into this.
yes, definitely way better than the first workaround and it gets the job done in a couple of minutes
Not reviewing all changes, as I do believe most of the behavior as the algorithm works is fine, however, making it so any difference in a page or a reusable element existence should be automatically set as a conflicting change and allow the user to review those differences since the experience of seeing those automatically deleted is quite alarming/distressing.
This topic was automatically closed after 14 days. New replies are no longer allowed.
