PSA: This Repeating Group's X uses WU

Tips
1

If you have a Repeating Group with a data source, then a condition ‘This Repeating Group’s X:first item is empty’ it uses WU equal to the WU of the data source.

Consider the following:

  • Repeating Group with Do a search for X and a condition ‘This Repeating Group’s X:first item is empty’ for the empty state
  • Do a search for X uses a few WU as expected
  • This Repeating Group’s X:first item is empty uses an equal amount of WU. This is despite the RG only calling the Bubble server / doing a search once and This RG’s X:first item being wholly client side.

Is it a bug or expected behaviour? I don’t know, Bubble hasn’t been very clear, but I use this expression all the time in my apps to handle empty repeating groups, and according to the manual it should not use additional WU because:

  1. Only one search is done to Bubble (proven through network tab)
  2. This Repeating Group’s X:first item is a wholly client side operation that has no load or interaction with Bubble, as the data in Repeating Group is already loaded and was charged for WU correctly.

CleanShot 2023-11-22 at 17.24.43@2x
CleanShot 2023-11-22 at 17.24.43@2x1698×286 29.9 KB

5 Likes
2

Thank you for your efforts! It is a little ridiculous that they do not seem to know what they expect the behavior to be (you can not call something a bug if it is not necessarily unexpected).

@georgecollier Just for reference and to see if Bubble thinks this is important, how long did it take to get this response from the time you brought it to their attention?

1 Like
3

Reported 15th Nov, they couldn’t replicate on 16th Nov, I sent a detailed video explanation on Sunday 19th Nov, they confirmed they could replicate it same day, looped in engineering 21st Nov, sent a follow up today. Communication speed I can’t really criticise and the support agent is helpful :slight_smile:

CleanShot 2023-11-22 at 18.06.17@2x
CleanShot 2023-11-22 at 18.06.17@2x1696×224 18.2 KB

1 Like
4

Tracking this topic. Hope we’d get more updates on this one.

5

It’s now been over two weeks since engineering were asked whether it’s a bug or feature and three weeks since I raised the issue. Maybe you can attribute it to Thanksgiving in the US but still… I will post any more updates as I get them…

2 Likes
6

It’s now the one-month-iversary of reporting the issue, still no answer as to why the WU are being overcharged here :man_shrugging: I’ll keep following up…

4 Likes
7

Noticing the same behavior here, hope this is addressed ASAP.

9

Perhaps this is related (this thread also pertains to being charged WU multiple times for a search that only runs once as per network tab). Who knows.

10

Update for the people following:

None. Two months later :upside_down_face:

Sent today:

CleanShot 2024-01-23 at 11.54.11@2x
CleanShot 2024-01-23 at 11.54.11@2x1728×248 16.8 KB

12

Here’s the reply. 2.5 months later, but better late than never.

The TLDR is, yes, WU are being overcharged, and we’re not doing anything about it in the short-medium term. There is an interesting nugget about how ‘:first item is empty’ is calculated though…

Firstly, I want to extend our sincere gratitude for your patience and for bringing this matter to our attention. It’s through feedback like yours that we’re able to delve deeper into the intricacies of our application and improve the experience for all users.

Our engineering team has conducted a thorough investigation into the unexpected behavior you reported within your application. Here’s what we’ve discovered:

When one expression in your application references another search, it introduces an additional step in the process, specifically in the “Fetching Data” phase (db_search). For example, if a condition within a repeating group checks against the first item of the group’s list (e.g., making something visible only if “The Repeating Group’s list:first item:is not empty”), and this list is populated via a search (e.g., “Do search for foos”), this operation is split into two separate searches. The first search checks the condition with an offset of 0 and a limit of 1, while the second search populates the list with an offset of 1 and a limit of N, where N represents the number of cells displayed.

From a technical standpoint, this process, while slightly inefficient, doesn’t result in duplicate data or significant issues. However, we did notice an impact on workload units (WU). Specifically, each database search incurs an overhead of 0.3 WU. In this scenario, there’s an additional 0.3 WU overhead—part of it is necessary for the search operation, but the other part represents an inefficiency we hadn’t fully accounted for until now.

Our engineering team has concluded that this is definitely something we want to continue looking into, however, any significant changes to this behavior are not anticipated to be rolled out in the short-medium term future.

Your report has had a significant impact on how we understand and calculate search-related workloads. It has prompted us to look more closely into our workload calculations, ensuring we are as efficient and transparent as possible in how resources are utilized within our application. Your experience is incredibly valuable to us, and we are committed to making continuous improvements based on the insights you and our user community provide.

Thank you again for your valuable contribution. If you have any more questions, concerns, or further feedback, please don’t hesitate to reach out. Your input is instrumental in helping us enhance our service.

1 Like