Basically, the issue checker doesn’t seem to work properly after using “sync with live”. Following is what I recall about the course of events that might lead to problems.
Assuming there are at least 2 different development versions, deploy one of them (let’s call it dev1).
Now make the other development version (let’s call it dev2) active. As expected (and documented), dev2 has become out of sync with the live version.
Pull the changes across from live to dev2.
After the above steps, what I have noticed is that the issue checker will identify issues in the editor of dev2 for workflows and pages with changes that were pulled (“sync’d”) from the live version. It seems the relevant editor page(s) must actually be visited in order for the issue checker to “see” and identify the issues. Once it does, though, simply refreshing the page will cause them to automatically resolve and disappear!
The scarier thing, however, is that I have reason to suspect that if the issue checker isn’t explicitly “forced” to identify those “false” issues (by visiting the relevant editor pages) and if those issues aren’t subsequently “cleared” (by refreshing the page), then deploying to live might result in “real” issues in the live app!
For example, I’ve had an action inexplicably disappear from a live app, even though it had previously been deployed and was working. This seemed to happen after I sync’d with live and then deployed from the version I just sync’d.
Needless to say this is all extremely difficult to troubleshoot, and I’m certainly not going to intentionally jeopardize the stability of a production app just to bug test; so I’m relying on what I recall about the sequence of events.
I’ve submitted a formal bug report just to get something on record, but if anyone has had a similar experience or has any other potentially relevant details to share, feel free to add to this thread.
Following is a bit more succinct synopsis of my observation…
Sync’ing with (pulling changes from) live can lead to “false positives” with the issue checker. That is, it will identify “issues” that will automatically resolve and vanish if the page containing the issues is simply refreshed but could potentially cause “real” issues in the live app if deployed before the “false positives” are resolved.
I’ve found a second dev version to be invaluable in certain situations. For instance, if a major feature is being implemented in the main Development version but an urgent fix is needed in the live app but Development is not ready to be deployed, then a new dev version (let’s call it “hot fix”) can be created based on the live version. The fix can then be implemented and deployed without pushing anything from the Development “work in progress”.
After deploying the “hot fix”, I typically then Add changes from the “hot fix” version to the Development version so that it’s in sync with live. Alternatively, the changes could be pulled directly from the live version, but I’m avoiding that for the time being due to the issue described in this thread.
@sudsy completely agree. I also thought it was invaluable for the same reason. While in the middle of a big upgrade, I’ll need to do a small fix. But can’t deploy the small fix without finishing the major change.
However, it’s too unreliable. Eventually your “hot fix” (Dev2) will get out of sync with main development (Dev1). At lease I think it will, more on that below.
If I used “Add Changes From” button to sync one with the other (Dev1, Dev2, or Live), I found sync issues. Many times the issues are hidden deep. Like one random element or step in a WF will disappear, and there’s no way to find it. You’ll eventually find it when you ship to live and users mention a missing button or broken WF.
I worked with bubble support for a while on this. They ended up manually copying and pasting one to match the other, element by element. They were extremely helpful and worked hard to bail me out of the tough situation I was in.
I hope the issue is resolved. I find the second dev mode unusable, and I wish I could use it (as described above). However, I just checked my Open Cases page and still see it open from last year.
Thanks, @brad.h, I really appreciate the insights. I’ll likely discontinue use of the versions feature for the time being. While I was never presented with the conflict dialog, there does seem to have been some instability and/or regressions introduced into the live app. My confidence in this feature has been shaken to say the least.
Yeah, Bubble is [kinda] cool, but I’m quite annoyed that the leadership has never heeded anyone’s cries over the years for a proper bug tracker, where developers can see bugs that others have submitted and that have been confirmed, with the ability upvote, comment, and provide feedback. I’ve expressed my strong desire for such a system on more than one occasion. Until something like that is in place, different Bubble developers are doomed to encounter the same bugs and repeat the same mistakes. (The forum is simply not the same thing.)
Honestly, @brad.h, had I seen comments like yours in a public issue tracker, it would have dissuaded me from using the feature and might have prevented some instability. Bubble should probably just turn the multi-version feature off until they get the kinks worked out.
I just don’t understand the rationale behind keeping all bug reports silo’d in each user’s account. I’m really disgruntled right now.
Thanks for the info, @lottemint.md. I hope Bubble is following this thread and gleans some insights from your post. Unfortunately, for the app I’m currently working on, that process - especially step 9 - is simply not feasible. There are over 70 pages and more than 100 reusable elements.