LCS - Debugging Errors in your Betty Blocks Application
- GraphQL Inspector
- Actions Failing to compile
- Action is not performing the way you think it should
- Authentication and Authorization issues
- Page Errors
- Page Not found / IDE Loading errors
In general, there are 5 types of errors that can occur while developing in Betty Blocks:
- Actions failing to compile;
- Actions not returning/saving the correct data or the function doing nothing/timing out;
- Authentication/ Authorization issues that cause login loops
- Page errors that return blank or funky error messages on the page
- Page not found/random UI errors
We will look at each of these basic cases and provide options for how to determine what went wrong and where to look for the information to make that determination.
GraphQL Inspector
First, we need to install an important browser extension; in Chrome or Firefox find the “GraphQL network inspector” in the extension store and install it. This tool provides you, the developer, with an insight into the GraphQL calls that are core to all data/actions transversing through a Betty blocks application.
It can provide insights into why an action or page is having issues whenever an unexpected result happens on the platform. This is always the first tool we use to begin to see where the error or issue is coming from.
In this Animation you can see that when an action or data model is called they will get recorded by the inspector and you as a dev can drill into the call to see the request, response to see exactly what was being sent and what the response is as well as if there were any errors what the error and error message are.
Actions Failing to compile
At some point every developer will run into this issue where you save an action step and then a little red “X” will pop up in the upper left corner of the IDE screen instead of the green check mark that should be there as seen in the screenshot below:
.
When this happens, it means somewhere in the application an action step is misconfigured.
Diagnosing where the error is:
The best way to determine where the error is coming from is to head over to the application logs and inspect the log messages for an error. Logs can be found under Tools in the bottom left hand side menu:
The log message you are looking for will start with: “Failed to compile actions after XXXms...” and will have a red ERROR as the log level.
- To the far right a copy message button will appear when you hover over the log row click that and open a text editor of some sort, VSCode, BB Edit, or even Word will work, and paste the message in into the editor.
- Near the top of the message, you will find a section that will have “action: A _STRING_OF_CHARACTERS, step: SECOND_STRING_OF_CHARACTERS”
- These character strings are called UUIDs or Universally Unique IDs. We will use both to construct a URL in Betty Blocks to take us to the broken action step.
- In a new window (I like to go back to the application page and just reopen my development sandbox) navigate to any action.
- Click into the URL bar of the browser and you should have at the end “action/UUID_OF_THE ACTION”
- Replace that UUID with the action’s UUID from the error message.
- Then type “/step/” and paste the UUID of the step from the error and hit enter. This will open the action and take us directly to the action step that has the error.
- You should now be able to see the cause of the error and be on your way to rectify it.
Action is not performing the way you think it should
Sometimes an action runs but doesn’t error just seems to do nothing. Or it runs but its behavior is unexpected.
Causes
There are a few reasons why this can happen, the action or an action step is not getting the data you think it is; the data is not in a format that you can use in the way you are trying to; the action is taking too long and not finishing before it times out and other issues.
Finding the Issue
The only way to diagnose action issues like these is to use the Log Message action step.
- Drag the step it into your action canvas
- Select one of the types of log messages. It doesn’t really matter which one you select. It just shows it in the log for organization. Usually “info” or “debug” work well.
- In the Variables Section select Add.
- In the Key Field type in the wording that will be displayed in the log so you can see which log message is which.
- In the Value Field you can either type in text here just to let you know where you are in an action, or you can use the “(X)” to select a variable to display the contents of in the log.
- Log messages only get generated if there are no errors up to that point. If there is an error, then any subsequent log messages are not displayed. Therefore, by putting log messages in your action at various points you can determine how far it gets before the error occurs. Then you can add more log messages to refine things down to find the exact action step where the problem is.
- Useful things to log.
- Start of the action to make sure that the action is even getting started.
- End of the action to make sure that it completed all the way.
- Variables and their values. That way you can see if any expected variables have the correct result or not.
- Messages as waypoints. Start putting in log message that just say, “Step 1” and “Completed”. Then you can make sure it gets through the steps. Remember that it only logs messages up to the point where there are no errors. So, if it doesn’t log “Step 2” then something happened before that point.
- Once you have pinpointed your problem step(s) and fixed the error it's best practice to remove all the log messages as they can slow down your action.
Authentication and Authorization issues
These types of issues stem from improper roles and permissions setups to solve this problem check the following things:
- The page is using the correct Authentication profile (default SSO profile is WebUser)
- If the page is secured for role-based Authorization that the Auth Profile and Role data containers are setup correctly (link to Secure a page KB)
- Check what models your page is using (data containers/tables/lists/update forms), then go to Tools -> Roles & Permissions
- Go to the role the user should have to access that page and make sure the models that are being accessed on that page are readable by that user.
- That includes the Role model if you are use role-based authorization
- Go to the role the user should have to access that page and make sure the models that are being accessed on that page are readable by that user.
It’s often handy to use the GraphQL inspector here to see what user/role is getting passed through and that can be a hint at the error as well. TIP: Enable persistent logs in GraphQL to not lose the logs when the authentication redirects.
Page Errors
Page errors are some of the hardest errors to debug as Betty Blocks doesn't give you great tooling to pinpoint the error's location or cause. The GraphQL inspector is one of the most useful tools to help debug Page errors. Here are some common issues and how to identify them.
Page errors look like the following.
They appear hard to read, but they provide two pieces of useful information. For more information see Betty Blocks Docs.
- Page error for ID missing. This is common when you compile/start a page that has an input parameter. It can’t start the page because it is missing the input. It gets that input from a different page in your application.
- You can deal with it by the following methods:
- Just wipe out the part of the URL so that it starts a normal page.
- Compile/start a different page like your home page.
- Change the missing parameter to one that you know will work such as 1.
- Create a bookmark that links to a page with a correct parameter (like option 3) and then just hit the bookmark when you get this error message. This can be useful for pages that you are actively working on and starting a lot.
- You can deal with it by the following methods:
- Page errors that are missing a variable. These can be trickier to find the exact spot where the error occurs. That’s because you can’t easily find the exact component where the error is happening. You will need to examine each component on the page. However, these errors are caused by a variable in a filter so any place on your page that uses a filter is a good place to look.
- Blank pages or blank section of pages can be caused by Data Containers that aren’t getting data but have Advanced Option “Only render children on data being present” checked also see Number 2 in this list as that could be the root cause of this type of error. This checkbox is checked for good reason and the data container not getting data is a sign you should look to where it’s getting its filter value from as the culprit.
- Data Tables or lists that aren’t getting the results from a filter you expected,
- Open GraphQL inspector
- Check out what the request looks like as it will include whatever filter is being sent into GraphQL if it’s different than what you expect try to see how it came to that filter adjust your filter till you get the request query you want, or reach out to the LCS (Low Code Solutions) team for help with your filter.
Page Not found / IDE Loading errors
At times, the Betty Blocks IDE with just error out giving you an error message that looks like this:
The fix is to just refresh your browser and it should go away.
When opening an application sandbox sometimes the left navigation will not load only showing the pages icon (see above screenshot for example). To fix this refresh the browser and it should properly load the application IDE.