Why Pay for a Bug We Didn't Cause? This post contains a high amount of WU

[eren]

Hello there,

The subject of this post is Bubble’s expectation that we should bear the entire cost of a bill resulting from a bug that was not created by us. A system where only the application owner pays for damages caused by bugs is an extremely unfair one.

I need to go into some detail, so this might be a bit long to read, but I can’t accurately explain the situation without mentioning the dates.

When we noticed the WU (Workload Unit) spike, @batuhanmerguz from our team began investigating the situation. Upon realizing that the WU consumption was due to a malfunctioning condition (we were describing this bug as data fetching, but then we realized that the condition was broken.), we created a bug report with a Loom video on September 6th.

It was September 11th that it reached the relevant team (of course, we sent a follow up; otherwise, I’m not sure if it would have reached that day)

On September 17, I took over the conversation from Batuhan and wrote the email below.

The response we received was along the lines of “we’ll look into it,” but with one difference: they requested the editor link for the bug report. I was surprised because I had already sent the bug report number “2999” in the subject line of the email. They said they couldn’t find a number like that and stated it should be 6 digits long, among other things.

The reason I’m providing this detail is crucial: time is passing! Between emails and correspondences, our bill is continuously growing.

On the 19th of the month, I received an email from @Eram_BubbleSupport saying, “We’re already actively investigating, and we’ll add you to the CC list.” Yes, by this time, 13 days had passed before our application even entered the investigation phase.

Remember this follow-up; I had already mentioned my expectation regarding a refund. If the support team had responded to the email I shared above with something like, “We don’t issue refunds. If you know of a workaround, please apply it. Also, you can check our refund policy here,” we would have solved the problem on our own with a workaround and avoided paying an even higher bill.

In just these 10-11 days, while we were waiting for the bug report to reach the right people, we had already spent $400. In my opinion, even this much is abnormal.

Meanwhile, we didn’t apply any workaround and waited for the problem to be solved, because a condition wasn’t working properly. If a condition doesn’t work, how can I trust Bubble to develop applications?

In fact, I mentioned this while responding to @ihsanzainal84 here.

@eren

However, we are not applying these optimization techniques that come to mind. We are waiting for news from the Bubble team. Because we believe this is a bug related to data fetching and is important for the sustainability of the platform. Even if it is not a bug, we need to understand which behavior has changed.

Being exposed to a higher bill while seeking a more stable platform? This is truly frightening. Let’s continue.

We continued our conversation with @Eram_BubbleSupport. I prepared a very detailed email, trying to help them see the source of the problem. Of course, this didn’t happen immediately. I understand that the application can be complex, and certain factors can complicate the investigation.

Patiently, after more than ten back-and-forth emails until around October 2nd, a different approach was needed. I copied the page, deleted all elements and workflows, leaving only the malfunctioning repeating group (workflow count 0 - element count 15). And, as we had reported from day one, it was still malfunctioning.

It took 6 days just to confirm the error on this page. Let me remind you, we created the bug report on September 6th, and we agreed that it was a bug on October 8th.

Did it end here? Of course not. There was another spike in the application.

From September 6th, before the bug:

This image is from an unexplained spike that occurred in between. Just as its cause is unclear, why it resolved is also unknown. We hadn’t even looked into this one yet. We were still dealing with the first issue The period after the 10th of the month is when Bubble found a solution for the “first bug.” That’s why there’s such a significant drop.

So, what turned out to be the solution for the simplified page? The Bubble team finally identified this: The Hero Icon Plugin was interfering with the RG’s condition. When we removed this icon, the application’s behavior returned to normal. A third-party plugin, a Bubble plugin, yet it conflicts with Bubble’s code. Okay. But wasn’t the plugin system designed to develop products that wouldn’t clash with Bubble’s code?

For instance, if you have custom JS in your application, the Bubble engineering team refuses to investigate bugs, because custom JS can break your application. That’s why plugins should be used. But what if the plugin breaks it? Apparently, that becomes the application owner’s problem. Yes, the response I received was similar to this.

I’m expected to pay the bill for a bug caused by a third-party plugin.

I’m asking the Bubble team: Did you inform your other users about this issue? Did you send an email saying something like, ‘The Hero Icon Plugin can cause sudden consumption in your application. Please be aware of this and try removing this plugin if you see a sudden increase’? As we still have this plugin in our other apps, I can confidently say that neither I nor any of our team members received such an email.

I’m really curious, has @minimumstudio been informed about this issue by team? Are they reviewing their code? Somehow, I don’t think that’s happening either.

Note: This bug-causing plugin has over 47K+ downloads.

Let’s reflect for a moment: 13 days passed before the investigation even began, all while my bill kept increasing. Then, a full month went by with me being certain of the issue while the team remained unsure. After being obligated to prove the problem and doing so, I learn that all this effort was in vain.

I’m someone who has given a new direction to their career with Bubble. I’ve earned money thanks to Bubble and continue to do so. However, how can I explain to my clients a situation that I can’t even explain to myself?

Here, the community needs to do what it always does. We need to guide the team. We need a fair refund system, a rapid notification system, and transparency.

Why should we or our clients pay inflated bills just because reviews are delayed due to Bubble conferences or seasonal holidays?

In my opinion, here’s what should have happened at the very least:

1. If the bug report is related to WU consumption, and the WU consumption doesn’t lead the user to “overage” usage, there’s no problem.
2. If the bug report is related to WU consumption, and the WU consumption does lead the user to “overage” usage, the overage shouldn’t be billed immediately, or it should be communicated that it can be refunded. The user shouldn’t bear additional burden because the team didn’t have a chance to address the issue.
3. If the bug report is related to WU consumption, and the WU consumption leads the user to “overage” usage, the overage should be noted. However, if the WU consumption wasn’t caused by the user but by a 3rd party plugin, the overages should be refunded. The plugin author should be informed and asked to update as soon as possible. An email should be sent to all users, or at least to users of apps using the plugin, asking them to check their situation and remove the plugin if necessary, among other things.
4. If the bug report is related to WU consumption, and the WU consumption leads the user to “overage” usage, the overage should be noted. However, if the WU consumption was caused by the user, we have no objection to this.
5. Regarding plugin-related issues:
   a. If the plugin is a paid one, the developers who profit from its sales are responsible for ensuring it works compatibly with the Bubble platform. In this case, if the end-user is not the plugin developer themselves, they should not be billed for bugs caused by the plugin. As a paid product, users can expect a smooth experience, and the developer is responsible for providing solutions to any problems.
   b. If the plugin is free and the user encounters extra charges due to a bug, Bubble should provide early warnings to allow users to avoid such costs. It’s not fair for users to pay “overage” bills due to bugs that occur during the use of free plugins. In such cases, Bubble should inform the user and offer alternative solutions. At the very least, there should be a disclaimer about the responsibility for WU consumption arising from free plugins.
   c. Bubble, which also takes a commission from plugin sales, should be included in this responsibility. Bubble needs to implement better documentation and accountability measures for plugins. This would ensure that both Bubble and plugin developers share the responsibility for maintaining a stable and reliable ecosystem.

Additionally, I want to stress that Bubble should not discourage us from writing bug reports; on the contrary, you should encourage it. Otherwise, how can you continue to build a more stable and sustainable platform? User feedback is crucial for identifying and resolving issues, ultimately leading to a better experience for all users.
I welcome your thoughts, contributions, and questions. This community has made Bubble better so far, and I believe it will continue to do so from now on.

Best,
Eren

[GH5T]

@eren

I’m expected to pay the bill for a bug caused by a third-party plugin.

Not trying to be the bearer of the bad-news, but when you subscribe or install “third-party” plugins, you’re subject to those issues. Bubble cannot be held accountable because of a third-party plugin YOU installed.

Meanwhile, take a look at Herofy - a plugin I made that should be pretty clean. It doesn’t have any additional hooks or console errors.

You are able to use THOUSANDS of different icons from different libraries if you use the Iconify element.

[georgecollier]

@eren

However, if the WU consumption wasn’t caused by the user but by a 3rd party plugin, the overages should be refunded.

I think that’s pushing it. Updates Bubble push shouldn’t be breaking changes for existing plugins, but ultimately Bubble isn’t responsible for third party plugins. If a third party plugin you use causes more WU, that’s on you for using the plugin of your own free will. Else, does Bubble have to start refunding WU used for inefficient SSAs or fuzzy searches?

@eren

the developer is responsible for providing solutions to any problems.

For any plugin, this is not the case. The developer is responsible for nothing. Once you’ve bought it, you’re buying it as-is. Any future updates are, whether you like it or not, of the developer’s own goodwill.

It looks like this is not an issue with anything Minimum Studio did with the Heroicons plugin - rather, a change in Bubble’s code meant that Bubble began conflicting with the HeroIcons plugin. Whilst it’s annoying, it’s not really Bubble’s fault - their core responsibility is to the platform as is. They cannot test compatibility with every plugin on the platform.

@eren

Bubble’s expectation that we should bear the entire cost of a bill resulting from a bug that was not created by us. A system where only the application owner pays for damages caused by bugs is an extremely unfair one.

A bug that was also not Bubble’s responsibility as it was, even if Bubble made an update, caused by HeroIcons plugin. HeroIcons is made to be compatible with Bubble - not Bubble made to be compatible with HeroIcons.

So, my take on the whole thing is that yeah, it’s annoying, but this kind of thing is why using third party plugins is a risk we willingly take. Sure it’d be nice if using plugins came with some guarantees, but that’s only on Bubble for official Bubble plugins. They wouldn’t even intervene with plugins with thousands of downloads that expose API keys that the devs won’t even tell their users about.

Yeah, I agree with your sentiment (that it’s annoying and shouldn’t happen), but don’t think Bubble will be changing anything any time soon. And yeah, support is too slow but the team is already aware that scale/process in that department needs to be worked on quickly as Bubble continues to grow.

TLDR; yeah it’d be nice if Bubble didn’t break plug-ins, but it’s a reasonable and understandable business decision to keep plug-ins the responsibility of the authors.

[lindsay_knowcode]

I look forward to the time when plugins are presented in a way users can evaluate in a meaningful way.

[GH5T]

Have a vote on my poll!

I will keep bumping this topic once a month to keep the team informed.

Please put your thoughts on that thread to keep it alive!

[dorilama]

did they share any technical detail of what was interfering with what? it can be helpful for everybody creating plugins

[Kayami]

hey - definitely not aware that our icons plugin could even cause a problem like this, gonna check it out

im a bit confused how it could even do that, is it causing the rg to re-render more than needed and that is fetching data?

the plugin itself is just clientside js and no requests to any server besides loading the plugins once (which doesnt count towards WU)

so it has to be some sort of interaction that causes something to render more than needed? curious to get some info if possible

i think a more general alert of ‘this page / element is consuming large amount of wu’ would probably help because if our plugin can cause something like this pretty much any plugin could.

and sorta related - now that icons in buttons are officially supported im just hoping custom icon sets will be released so we can deprecate the plugin in favor of a native solution.

[eren]

Thanks for inputs;

@GH5T

Not trying to be the bearer of the bad-news, but when you subscribe or install “third-party” plugins, you’re subject to those issues. Bubble cannot be held accountable because of a third-party plugin YOU installed.

@georgecollier

For any plugin, this is not the case. The developer is responsible for nothing. Once you’ve bought it, you’re buying it as-is. Any future updates are, whether you like it or not, of the developer’s own goodwill.

We have developed and continue to develop plugins, even though we’ve delegated most of them to another company. Our goal isn’t to avoid responsibility, but to work towards a more robust and user-friendly ecosystem where these kinds of issues are minimized, and when they do occur, there’s a fair way to address them.

@georgecollier

I think that’s pushing it. Updates Bubble push shouldn’t be breaking changes for existing plugins, but ultimately Bubble isn’t responsible for third party plugins.

You’ve given a good example - for instance, when Bubble releases a new version, previously installed plugins shouldn’t have issues. But what if they do? You’re saying that the app owner (not developer) should be responsible and pay for something that didn’t cause problems before. Does this seem normal to you? I’d like to hear how you would explain a situation like this to your customers.

@georgecollier

If a third party plugin you use causes more WU, that’s on you for using the plugin of your own free will. Else, does Bubble have to start refunding WU used for inefficient SSAs or fuzzy searches?

This is not about a plugin consuming too much WU. This is about a plugin breaking Bubble.

@georgecollier

It looks like this is not an issue with anything Minimum Studio did with the Heroicons plugin - rather, a change in Bubble’s code meant that Bubble began conflicting with the HeroIcons plugin. Whilst it’s annoying, it’s not really Bubble’s fault - their core responsibility is to the platform as is. They cannot test compatibility with every plugin on the platform.

You’re right, and I agree with the rest of your points. That’s why I tried to suggest potentially implementable regulatory proposals that we could contribute more to.

@georgecollier

They wouldn’t even intervene with plugins with thousands of downloads that expose API keys that the devs won’t even tell their users about.

Let’s say you made this warning, you disclosed this situation on the forum, in this case the forum administrator should inform the team, the plugin author should be forced to fix this situation, and at the same time this vulnerability should be reported to users who downloaded that plugin.

Bubble users are mostly nocoders, right? Most of us didn’t even know what API key meant when we first stepped in. Bubble should take a step forward here.

We agree that Minimum Studio isn’t at fault, and Bubble can’t check all plugins.
However, there are some critical issues we need to address:

User Responsibility: Why should the end-user bear the entire cost of an unexpected payment when they have no way of knowing which plugin might cause issues, when, or why?

Communication Gap: I think you might have missed this point: Did Bubble confirm that this plugin caused a malfunction? Yes, they did. But was this information communicated to the plugin author and other users? No! This could lead to dozens of users with high bills creating bug reports before realizing the source is a plugin, increasing Bubble’s workload.

Bubble’s Responsibility: In a situation where Bubble hasn’t informed its customers about a known issue, don’t they bear some responsibility for the extra charges incurred?

Incentives for Reporting: As someone who filed a bug report, I’m among the customers who paid extra. I even posted on the forum to inform you all about the situation, and I’ve invested time in this discussion. If I hadn’t done this and had just applied a workaround, I wouldn’t have had this problem. We should be encouraged to create bug reports - which often take hours to create and follow up on - as they potentially benefit the entire community. Instead, we’re essentially being penalized for it.

Overage Charges During Investigation: Users shouldn’t be held responsible for “overage” charges while a bug report is being investigated, at least not until the Bubble team is certain the problem is user-caused. Conversely, if they determine it’s not user-caused, the “overage” should be refunded.

@dorilama

did they share any technical detail of what was interfering with what? it can be helpful for everybody creating plugins

No. Frankly, I think they haven’t looked into this “yet”. I think they came up with the suggestion to delete the element directly when they realized the source of the problem. I will definitely ask about this.

The Bubble plugin documentation has been bad since day one. They should definitely fix this too.

@Kayami

hey - definitely not aware that our icons plugin could even cause a problem like this, gonna check it out

You should have been informed, that’s the whole point of the post

The icon does not consume WU. The icon is in a Repeating Group that is under many parent elements. When the icon is there, the Bubble’s behavior breaks.

Invisible elements are considered visible by the Bubble even though they are “still not visible on the screen”, causing the Repeating Group to fetch data. When I delete the icon, the Bubble’s behavior is fixed.

[randomanon]

First of all, there’s no point complaining about something that you agreed to by accepting a Terms of Service.

Second, it’s really funny to me that you’re complaining about a plugin causing a WU spike, given that the only way you’d know about this bug is because of Bubble’s tooling and visualizations. Guess what bugs you don’t know about: security vulnerabilities. There’s no chart that shows you if your app has vulnerabilities due to a plugin. But you probably don’t care, because you don’t see it on a chart.

My advice is to not use any plugins other than the official Bubble plugins, and if needed, to write your own. The plugin marketplace is slop, and full of badly written code or wrappers of free open-source libraries being marked up at insane prices. Use at your own risk (just like the Terms you agreed to say).

[boston85719]

Bubble shouldn’t be nickel and diming their existing user base, as it is, in every industry, cheaper to keep a client than it is to get a new client, same is likely true for employee retention as well. In that light, Bubble should be offering to allow you to pay exactly what Bubble pays for those same WUs and not the normal overage charges, or at least the lowest stated overage charge for any plan type regardless of what your plan type is.

They should also be doing more to ensure that 3rd party plugins comply with their code since they are taking a 25% commission on every sale of the plugin, they should have more skin in the game to ensure it is not just a ‘buyer beware’ situation, and as you have pointed out some very good ways that can be done.

This situation highlights a ‘best build practice’ in the WU era with hidden RGs…put a conditional onto the RG for when it is visible to have property to change be the datasource, and leave main data source empty. This would likely ensure that no matter what, you are only charged for returning data when it is absolutely necessary.

[sem]

I am a bit concerned with the overal stands about this issue. Although we have successfully managed away the WU’s by using Supabase, meaning we have blazing fast data management, flexibility and went from paying hundreds to the starter plan, we do want Bubble to succeed as we still use the frontend at this stage.

I think we should really help Bubble to understand that this is not how you deal with customers. It is a fact that for the average Bubble user the whole WU pricing is a black box. You either hope your product will never go viral or that your manager in a corporate setting doesn’t care to pay 10x. It has been explained for years that WU is not a smart solution but now we have to accept it. Which means that also Bubble has to accept it. So in case for some reason nobody really understands why a customer suddenly has to pay much much more, simple refund. Be human about it.

And yes it can be frustrating for Bubble that a plugin is causing the issue but can you expect your customers to understand that? Specially when WU at the first place is not understood by most? Of course not. So either Bubble needs to have checks in place that will not allow a plugin to enter their closed market place (is it strange to trust a plugin that was accepted by Bubble review ?), or simply refund when it happens and contact the plugin author. How hard can it be

[senecadatabase]

@randomanon

My advice is to not use any plugins other than the official Bubble plugins, and if needed, to write your own. The plugin marketplace is slop, and full of badly written code or wrappers of free open-source libraries

I tend to agree with this.

I was looking to see what all loads when my page loads and I noticed a plugin that I had tried months ago, and then deleted is still being loaded on page load.

Incidentally, I tried the AI builder. I deleted all the pages a couple of months ago but found some of the fonts that were used are still being loaded on page load…

and also noticed when putting an image inside a group with min and max widths set…and then giving the image a 100% width and height is not a good practice for page loads.

But anyway, I found plugins can be very poorly written and should be used with caution.

I know there are those who create some good plugins, but it can be hard to tell sometimes.

[ihsanzainal84]

I don’t avoid third party plugins, i think it’s silly, but I am very particular about plugins if I cannot see source code. I mainly look out for shared headers, element headers and node resources.

If i cannot see source code then I’ll do more research on the plugin maker.
. What plugins have they made
. Do they have a support thread in the forum
. If yes, are they actively responding

I find that unpopular free plugins tend to be safer and better written.

[randomanon]

@boston85719

They should also be doing more to ensure that 3rd party plugins comply with their code since they are taking a 25% commission on every sale of the plugin, they should have more skin in the game to ensure it is not just a ‘buyer beware’ situation

The current plugin model is terrible and a holdover from their bootstrapping days, I would much rather they hire a full in-house plugin team that captures that all of that value.

[senecadatabase]

I agree somewhat…

the plugin I installed, which was free at the time and is now a paid plugin, is from a well-known plugin developer with high reviews.

I doubt if even 90+ percent of those building on Bubble actually do an in-depth look at what is loading?

I haven’t had time to look into the why yet.

I never actually used the plugin because after looking it over I decided it wasn’t what I needed.

However, it still loads.

After I take the time to track down the reason I’ll contact the plugin developer because they probably have no idea this is happening.

I also am very leery of most plugins because I’ve seen some real junk…but of course you have that with any plugins anywhere.

[JohnMark]

The only way to remove a plugin from the code is to use Optimize Application. Bubble will remove all unnecessary code, including uninstalled plugins. @senecadatabase

[senecadatabase]

Thank you!

I knew optimize application could be used to clean up databases etc., but for some unknown reason it never crossed my mind to use it for plugins.

You’re a big help today.

[GH5T]

The plugin market is what makes Bubble, Bubble. If it wasn’t for third-party plugins, a lot of Apps would all look and feel the same.

It’s what I call the “Bubble Site Effect”.

A lot of “Bubble sites” look and feel the same as it is, but there are some that stand out because they use their own plugins/build their own functionality from scratch.

Gitting rid of the plugins that are built by third-parties would be destructive for the ecosystem my guy. Having the Bubble team build everything in-house would not be ideal.

[alexcooney5]

I’m surprised to hear the plugin you referenced was initially free… but then became a paid plugin?

I’m a plugin developer and didn’t think you were able to do this.

[chris.williamson1996]

@alexcooney5

I’m surprised to hear the plugin you referenced was initially free… but then became a paid plugin?

I’m a plugin developer and didn’t think you were able to do this.

We aren’t, bubble allowed zeroqode to at one point and it padded their installs, both zeroqode and bubble made a public statement apologizing and reverting it when other people in the community got irritated.