Bubble Endpoints Intermittent Issues + logic fails (logic issue solved)

Hey everybody,

My frustration with Bubbles endpoints is just dragging on!

Issue 1 - The endpoints are failing to reply on a consistent basis. The CRM that is firing the data keep showing an error of no response after 15000 milliseconds. I’ve hit their support and there isn’t anything they can do, they simply say that I’ve either hit my API limits (which I haven’t) or that Bubble is unstable.

I hit support with a detailed video of the problem and they sent me a reply saying that I need to record the debugging session from the page!

There isn’t a page… this is the API workflows but regardless I did what they said from that page and recorded a new video showing the problem again. Here’s that video: https://share.getcloudapp.com/E0ulkddJ

Whilst I waited for a response I decided to try and overcome the problem myself by adapting the workflows in the CRM to compensate for Bubbles intermittent issue. The workflows works great from the CRM perspective but this means that I needed to create an “only when” filter on the create node to stop the records from being continually duplicated in Bubble.

Issue 2 - Bubbles “only when” is failing. Essentially what I am trying to achieve is to run a search based on the unique identifier from the CRM. Using that if the list is 0 then I am good to create the record if it is not then it shouldn’t.

Sounds simple but it doesn’t work. So my backup idea also fails

I thought I was going mad so I used the same logic on a page and it worked exactly as expected… so it must be a bug in Bubble.

I have created a video her: https://share.getcloudapp.com/KouLPrr0

Thanks again anybody that reads this… it’s driving me crazy! What should have been a quick job has taken literally days because when it fails naturally I assume that the problem is me. Which obviously results in lots more testing and continually rebuilding workflows until there is no other logical explanation.

I hope it is me! At least I’ll learn something rather than wasting my time.

Thanks in advance :slight_smile:

First: Check the Server capacity log. If you reach too high, this may cause this: the server that send the request will doesn’t get an answer fast enough and will think it fail (but in reality, this is just delayed). Some server will resend the request again (and this may explain in some case duplicate).
Two: If you have a long workflow, I suggest you to put an answer right at the start (if you don’t need to reply anything else that “success”). SoBubble will not process all the workflow before sending an answer to server and this will avoid server going on timed out.
If you need to reply data to server, process the minimal action you can (like create or update thing) and do the return api response.
Three: Be sure that privacy doesn’t cause issue. I remember a few time ago I got an issue with “only when” condition that doesn’t apply… but was caused by a wrong setting in privacy tab.

Hi @Jici,

Thanks again for your response! I really appreciate you taking the time to help me out :slight_smile:

It’s definitely not the server capacity as the app isn’t live yet. Here’s a screenshot of that: https://share.getcloudapp.com/2Nu24ezz

Point two is actually a genius idea… I will give that a go and see if that boosts performance. Ironically when I originally built the flow I wasn’t experiencing any issues until I then created more actions after it. This meant that the only action is to create a record and then push to the next workflow. I never considered that the create record workflow could be the reason for the delay in Bubbles success response because in all honesty they shouldn’t be related… I’ll create an action to send a success response and then create the record and see if that does the trick.

Point three: I never considered this… I’m not too sure where I should be looking other than the obvious here: https://share.getcloudapp.com/E0ulkBOP

Thanks again

Technically, if you don’t have privacy set on the thing you are searching, this should not cause issue.
Also, without seeing data it may be hard to know what the search do.
What you can do is to also send data to a requestbin and check what is sent and what is received on Bubble side. Use the log to see received data.

Right OK.

Thank you very much for your feedback @Jici

So this is another bug within bubble then :frowning:

Any advice on how to get a response from them? As you can see in the video, they never actually replied the first time as the reply had zero relevance to my problem and since then I have replied twice with no answer.

I’m not sure if I should hit support with this as a separate issue to the first one or just bundle it together although if they only reply with canned responses anyway then I suppose there’s not much point.

Did you check the log just to be sure this is not the data sent that causing the issue with duplicate?

I think you can create a new ticket if you have more information on the initial request.
I know also that sometimes they take time to answer while they are searching for the issue/fix.
Also, use Insomnia or Postman, and do the request (a lot of time) and compare the response time. (Just to be sure it’s not the CRM that have the issue finally ;P)

More test you will do, more you may be able what causing this and provide good information to have a fix faster.

I personnaly never got intermittent issue with API Workflow and no response too. I got an issue in the past where optional field was not applied and they fix it after a week or searching.

Hey @shaun, I noticed a discrepancy in your search logic that may help.

In your create logic, you are setting the Flexie ID to Request Data’s id

image

However, in your search, you are searching for Flexie ID = Request Data’s website_id so it is logically not finding an existing record and proceeding with the create operation

image

4 Likes

@eli you bloody star!!!

How on earth did I miss that… that you very much for spotting that! The logic now works perfectly :slight_smile:

2 Likes

Hello,

There is an excellent way to view executed steps in API workflow.

Create a new table called Logs. Then, create a couple of fields, such as:

  • endpoint_name
  • text
  • message
    etc.

So, the idea is to save received data or to view if a step was executed or not.

Now you can create your logs an easily query them in your database.

2 Likes

This is a great idea!

Would I create a conditional crate/update logo for each step in the workflow?

I’d love to see an example of this in practice… I’ll give it a go now.

1 Like