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.
OK OK I lied. Here’s a bit more explication on that topic:
But I won’t help further. By which I mean I won’t help earlier. By which I mean I won’t help in the correct sequence. Or maybe vice versa? 
Please stop advertising your product under the guise of solving the problem.
One thing I was thinking was just because it’s deleted doesn’t mean it’s removed from that Article’s list of Paragraphs, that is one guess I have is it needs to be removed before deleted.
You should read this topic more carefully Tip: Order of Operation - #2 by aschofer. Especially the part about the custom workflows I use.
Of course I know what you mean. But agree, seeing one number of records and actually having another is not what I would like.
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.
If you are creating things in the backend and then adding them to a list, then they can go missing from that list.
i.e. if you create 100 things by scheduling workflows and as part of that process you add the created thing to a list, you will often end up with 99 things in a list.
If you are deleting something in the back end, and then another process is trying to see if that thing exists, then it can often miscalculate.
i.e. if you delete 100 things from a list of 200, and then do a search expecting 100 … you will often find 101.
No idea why, but Bubble’s backend is essentially inconsistent. It is the way it is.
This will also show up if you are counting things expecting an exact answer. It may miss newly created things, or it may miss newly delete things.
Recursive workflows, and storing counts on control records get you round this.
The fact you see different results when using the debug is a symptom. Slowing things down lets Bubble catch up.
Chances are that Bubble is not using “native” Postgres here. So there is no table on Postgres for your data alone. It is stored as JSON blobs or something.
But yes, it seems like the “index” (be that a Bubble created index or a Postgres one) is sometimes out of step with the actual raw data.
I reported this years ago, and they even had an item on their backlog for database consistency. But that is long gone. The addition of recursive workflows bandaids over that.
I don’t use the backend to create a paragraph just a simple action (like on deletion).
You said you were looping?
Have heard about this before, where things are sticking around in a list. Which was a real worry.
So maybe when you do your :count filter the list where the unique id is not empty?
That might ignore these entries.
