Where do I even begin with this? By saying, “Spoopy!” (But of course spoopy action at a distance isn’t the issue.)
To the OP: When you see things happening “every-other-time-ish” (but fine in step mode) you’re experiencing asynchronous action execution. Which is to say: things you are thinking happen in sequence are not, in fact, happening in sequence.
I won’t help you with this further, but that’s the crux of your issue.
OP we all understand your current state of frustration in light of your problem but dissing on any form of assistance, regardless if it’s advertising or not, is not gonna get you the help you need.
Both @tylerboodman and @keith have a point. It does look like an async issue that can be resolved with broader understanding of how workflows work.
Those who have been in the forums long enough have read that post you pointed out. I myself have read that and many other posts (official and otherwise) on workflows and async issues in native Bubble. I can tell you from my reading and experience that not everything is covered in documentation or forum posts so don’t be so quick to brush off more resources.
I just mean on creation of a new Paragraph, sort by number and add one to the last one, then if you need to reorder it set it to the average of the two you want. Not like anyone sees this “order” number you can still show their index’s on screen (sequential)
My removal recommendation was regarding that weird thing where Bubble shows (deleted thing) in a field, but if you restored that datatype to an earlier date it magically knows that thing again and it’s spot in the list. I was thinking it’s still in your list as a (deleted thing) and it’s counting that? Just a theory could be completely wrong. So somehow you would synchronously do Make changes to Article → remove Paragraph, then after that do Delete a thing, Paragraph
I am of the same opinion as you. paragraphs have been deleted and a phantom link to non-existent things is left. But I’ve always understood that it doesn’t make sense to delete paragraphs from an article before deleting them. Deleting an object destroys linking. But most likely the link remains and goes into the count.
Looking at your original post again, you are experiencing what i experienced with my app’s form builder and it’s list order. It’s definitely an async issue cause you rely on a lot of additional workflows just to resolve it.
All i did was use List Shifter to update each section’s" list order" field to the current visible list index of each item. 2 workflows on the client-side was all it took.
You can go the non List Shifter route and just match your fields to each paragraph’s cell’s index number in whatever Repeating Group it’s being displayed in.
I want to make it clear. All of the workflows shown in this post exist on a test page and were created solely to demonstrate the problem. I’m not using a lot of additional workflows just to resolve it.
I just don’t quite understand how synchronous or asynchronous actions are related to phantom recordings? After all, in fact my post demonstrates their presence as such, right? After all, the action I am displaying is very simple - deleting a record. It’s one step that, for whatever reason, didn’t happen correctly. After which a phantom record was left that messes up another process. And this one is also simple. We create a record with a number (the number of all records in the article +1). So what does this have to do with asynchrony? With the utmost respect for those who do offer advice.
Could try adding a yes/no field called “isDeleted” to your Paragraph (default no), then instead of deleting just set it to “yes”. Then when you go to count your Paragraphs do :filtered with the constraint isDeleted = no so it’s guaranteed excluding “deleted” ones (just as a test)
Again literally just a theory it could be going down the wrong path and it’s just workflows not in sync
Some smart users think the problem is with the PostgresSQL that Buble uses. Although of course this may not be the case. I saw the problem with another user. He had a problem that all records in PostgresSQL are already indexed and after deleting and rewriting the same rows will have the same id that was before deletion.