I really hope someone will take the time to have a look at this, since it cost me at least a year of my life in frustration not just with the issue but mostly the extreme slowness for me of the forum app. Anyway, this is my issue:
I create an Inventory and then create Items that belong to that inventory. However, Users specify which Items need to be created.
I load a list of a couple hundred Items and Users select an ‘Items from #’ and 'Items until" range that will be converted into the items using an API workflow.
All of this works great, however, when the API workflow created all the things in the list, it continues adding items from item# 21 until the end of the static, preloaded, list. I cannot figure out why and recreated the issue in the forum app with the same result.
Please have a look at the forum app and follow these 5 simple steps:
- choose an ID number (any number)
- Select a from number (between 0 and 25)
- Select an until number (between 0 and 25)
- click generate
- select the ID from 1. and look at the numbers listed in the repeating group.
Why does it keep adding 21 upwards?
Link: https://forumapp3.bubbleapps.io/version-test/v56?debug_mode=true
Editor: Forumapp3 | Bubble Editor
Ok, the problem has to to with the numbering. I need to create leading zeroes because the number of the item needs to be combined with the ID of the inventory to create a unique identifier that is used for a QR code. However, Bubble does not accept leading zeroes when the field type is number so I used text.
Clearly there is something wrong there. When I create an item from 0 - something, it created 1, 21. Maybe just circumvent this whole issue with a new solution to the unique ID problem…
I just switched all the ‘number’ text fields to all number fields in my app and the problem still exists. No matter what, the API workflow creates the items in the list and then simply keeps adding items from item #21… 
With 3000+ errors I am not suprised ! You can always create your own public app, and put the example in that.
Impossible to use as it is, sorry, you must have spent ages 
Dang, here I thought this app was still widely used. I’ll recreate it, hoping you’ll have another look 
Probably overused !
If you can recreate in a clean app, will have a look. It seems to take forever to load on browser.
The API workflow runs the other numbers again as it thinks it is the same 1, 2, 3 (from 21, 22, 23) as just 1, 2, 3.
At first I thought it would run the full list (it did that before I changed to numbers only). But now I see it runs until the same number in the twenties as the amount of numbers in the initial list.
I find that still strange, because the list that is used by the API workflow just contains those 1, 2 and 3.
So this list:
12
13
14
15
16
17
18
19
Outputs:
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
41
42
43
44
45
46
47
48
It creates the correct numbers (totalling 8) and then keeps going with 8 numbers in the twenties, then skips thirties and creates another 8 numbers in the fourties. (the static list goes till 50)
I fail to see the connection here.
That is certainly quite odd.
It is probably the way you are doing the #item processing, as it operates from the list number you are currently on. So it is relative to the item number that you are currently processing, rather than the first number.
I tried storing the items in a state, but that didnt seem to help either. I use the same principle for another thing in my app and it works OK there.
Not sure what you mean by ‘list number you are currently on’.
The use case for this is that I need to print stickers with a QR code that link to this particular item which you can edit. However, the items already need to be created because of the fact that stickers need to be printed.
Users need to be able to select how many items they (think they) need and also pick which item to start from. It is not always 1, it can also be 82.
I could not think of another way of doing this than with the numbers stored as a data type and then selecting them in a repeating group, running the API workflow. If there is an easier way, I’d love to hear it.
By the way, I’m very grateful you’re spending your Monday evening (at least for me) looking at my problem. Truly awesome (seeing you move about in the app)
So it is relative to the item number that you are currently processing, rather than the first number.
I’m not sure what you mean by this?
However, I think I noticed that you fixed it. So basically you changed:
To:
If you could elaborate on this, my brain can’t process this 
I don’t know why it was broken, I suspect it is a bug with the way the list processing works with item numbers or something.
So instead of using #item it the list, I am just searching for numbers between your from value and to value, having sorted the list into item number.
So if you have from = 1 and to = 14 you search for > 0 (so 1) and all the way up to < 15 (so 14).
Hm yeah exactly. I didn’t understand why you would switch methods but if you say it could be a bug, I fully believe you
The only downside to this method is that I need to make sure the number thing is actually a number and not a text which keeps me from using leading zeroes which makes it more difficult to create a unique ID for the QR to link to (1001 for inventory 1 and item 1, etc.)
I looked at adding the QR code as a next step in the API workflow when I have access to the item’s unique ID but I noticed it was not reliable in adding it. I think I would then need to schedule a new API workflow adding the QR’s to the newly created items after that has finished…
In any case, thanks for the lesson!
