Backend WF 'Workflow error - List at maximum length (10000)' Is it possible to reduce the max length?

Questions
1

hi Bubblers
Another painful and expensive backend WF ‘experience’ but at least this time the WF stopped on its own (Workflow error - List at maximum length (10000)). I don’t recall setting the max. length anywhere. How can the max length be lowered?
Many thanks in advance

2

That’s telling you that there is hard limit in Bubble, on list fields, of 10,000

Presumably, you’re trying to set a list field that exceeds that max limit.

That’s what it’s telling you.

1 Like
3

If you have lists that big on a data type you really need to use another table to handle that data.

2 Likes
4

thx but it wasn’t a list, was a single transaction that should have rescheduled itself a week out but got caught in a twilight zone loop that isn’t related to scheduling WFs in the past. so am trying to figure out exactly what triggered the loop but it would be good to be able to put a limit on recursive WFs in general since we don’t process more than 30-50 items in the BE and it’s somehow ridiculously easy to drive off a cliff (hasn’t happened before with this WF)

5

You prob are looking at the wrong field if you think the field that timed out is not a list

6

thx but just to clarify, the main point of the WF wasn’t to deliberately process a list, but one of the steps did contain a list field, so it (and its 10k max) acted as a cap which prevented the WF from unintentionally spinning out of control to 1m WU and beyond… so i was grateful for the max …
the post-mortem for this special case was that a number field which shouldn’t have been empty was in fact empty so the rescheduled date was in the past which caused the WU explosion. urgh

7

Not following but regardless of what the point is if you have a list max error it’s clearly not a single field and if you don’t need a list then there is no need to have one involved in the wf

8

Does it happen to be stripe related?

9

nope, not stripe related - just the now-well-known-to-me case of a backend WF (unintentionally) scheduled in the past and spinning into oblivion. i thought i’d put up enough guardrails for this but obviously had to add more … (i complained to support about the lack of guardrails and zero documentation, so they added a sentence in the manual: ’ Note that if you schedule an API workflow in the past , it will trigger immediately ')