Backend 500 Error Help

Discussion Ask a question
,
1

Hello all,

I seem to be having an issue with some of my backend functions being called correctly. Randomly, about once every 100 requests, certain backend functions will throw a 500 error in the network tab for no apparent reason. If I make the request again (via button click or otherwise), it will work. I assumed for a while it was just a bad connect and refreshing the page would fix it, however recently it’s happening more and more, but still randomly. Any help is appreciated! Below are screenshots of the network tab when it happens, and some code snippets.

//Frontend Code: Parcel Analysis Results
import {exportData} from "backend/export/land.jsw"
...
 let error = await exportData(export_data, scrub_filters, desired_fields, data_tree_filters, search_parameters, use_city_pricing, use_geo_pricing, generate_offer_price_all_increments, user_id, email, user_plan, preview_mode, remove_duplicate_owners, generate_kml, split_pricing, record_cost)

//Backend Code: Land.jsw
//On 500 error, is not called (tested via console.log and site monitor)
export function exportData(buckets, scrub_filters, desired_fields, data_tree_filters, search_parameters, use_city_pricing, use_geo_pricing, generate_offer_price_all_increments, user_id, email, user_plan, preview_mode, remove_duplicate_owners, generate_kml, split_pricing, record_cost) {
   ...
}

2366×578 84.6 KB

2383×571 69.3 KB

1540×524 42.3 KB

I will also add that I put the frontend function inside of a try/catch block, and the error that is caught is empty. I don’t know if that helps, but just in case.

Please let me know if there is anything that can be done! I have temporarily added a single recursive retry, which seems to at least hide the issue from the user. I am positive I am doing something wrong, I just don’t know what that is.

2

From where in the frontend are you calling the exportData() function? How are you calling it? When is it called?

3

Hey Yisrael!

exportData() is being called from the page code of the Parcel Analysis Results page. It’s called after a user selects all of their inputs from different Lightboxes, and then I pass all of that data to the function, which on the backend will store the selections and then send them off from Wix backend to my external API for processing and other stuff. But sometimes the call never reaches the Wix backend.

Sometimes I will go through the Lightboxes, click submit, and it will fail. I will then immediately go right back through the Lightboxes, and it will work. When I created the recursive call, sometimes the first attempt will fail (i.e 500 code) and then the 2nd attempt will successfully call the function and proceed with everything with no issue. It’s certainly weird.

I’m ready for you to shred me for doing something dumb. I’m used to it by now!

Ryan

4

Please post the URL and explain where and how to see the issue. Not sure I’ll spot anything, but I’ll give it a shot.

5

Sure! The steps are behind our pricing plans. Not sure what access rights you need to make this work, so let me know if any of these steps are blocked and I will assist.

  1. https://www.prycd.com/search-land

  2. Search Park County, CO

  3. Click the Repeater option to select this choice

  4. Click Advanced Search

  5. Min Acreage = 5

  6. Max Acreage = 200

  7. Acreage Increment = 5

  8. Click Search

  9. Note: The search content does not matter, but this search was what enabled me to reproduce the error multiple times a few nights ago

  10. Now you should be on https://www.prycd.com/parcel-analysis-results

  11. Click the Green box in the top right corner of the table for “Select All”

  12. Click Continue (top middle of the box)

  13. Scrub Field Names Lightbox. Click Continue

  14. Scrub Filters Lightbox. Click Continue

  15. Download Options Lightbox. Prior to clicking, open network tab. Click Preview

  16. This will kick off the function handleExportPreview

  17. handleExportPreview (line 431) calls exportData (line 434), which is the source of our issues

You’ll notice that handleExportPreview is recursive. This is my current mitigation for this issue happening. If the 500 error is thrown, it waits a second and tries again. As I was typing this response, the error was thrown on the first attempt and on attempt number 2 it succeeded.

Let me know what you see/find. If the error is not thrown, I recommend refreshing the page and repeating steps 5-12.

Ryan

6

It’s really a lot of code to slog through and not so easy to follow.

One thing that I see is that you call post() from myExport(), but you don’t handle the returned Promise from post(). At least, that’s what it looks like.

If that doesn’t help, all I can suggest is that you create a very simple test scenario where you can follow exactly what is called, what is returned, what succeeds and what fails.

Understand that we are unable to debug or rewrite complex code. If you feel that there is a bug in Velo, then please try to create a test page with the minimum scenario in which the problem appears to help us investigate the issue properly.

7

Don’t I know it. There’s a lot there. We are trying to move away from Wix, our site has grown beyond what can be done on the platform. I mean that in a positive way!

myExport() post is intentionally not handled. It’s a risk, but the processing time of the external API is multiple minutes, and we actually send an email to the customer with data from that event. The frontend just ensures post() was called, and we handle any errors from the external API through our own methods.

I have done the test scenario. When the 500 error is thrown, exportData is called from the frontend, but if I put a console.log() on the first line of the function on the backend, it does not show up in Site Monitoring. Seems that the request simply fails to process.

No problem Yisrael. It was a longshot to ask, but I really appreciate you trying! We will probably stick with the duct tape recursion until we can rewrite the system.

Thanks again!

Ryan