Coming across certain issues while working with the platform might be frustrating at times. Though there is always one way or another to resolve them, and sometimes builders need certain knowledge to handle bugs, errors, and other issues on their own, or know how to pass the info about these to our support. This article aims to walk one through differentiating error types, reproducing issues, and resolving common issues with the application environment.

There can be hundreds of reasons why an issue is happening. This makes it very hard to determine the root cause of an issue in order to create a solution.

The first step and perhaps the most important step in the whole debugging process, is making sure that you are able to reproduce the issue. When you are able to reproduce the issue you can make use of several debugging tools that are available within the Betty Blocks platform or within your browser.

If you are unable to reproduce the issue, you can spend hours, days, or even weeks finding it first. And you will never be able to determine for yourself if you have fixed the issue once you have made some changes.

To reproduce the issue you can ask the following questions to the reporter. That will allow you to reproduce the issue and solve the issue a lot faster.

Below is a small example of how an issue should be reported:

Topic

Unable to create new projects within the dashboard @exmapleapplication.

Description

When I try to create a new project on the dashboard page the new project is not showing up.

Current behavior

When I try to create a new project on the dashboard page I am able to fill in the form and press the save button. The project does not show up on the dashboard page in the project's overview.

Expected behavior

After I have filled in the project fields and pressed the save button. The project must show up directly within the project overview on the dashboard page.

An issue can happen for multiple reasons. However, we are able to determine if an issue is happening due to a technical error or a functional error. Depending on the type this will determine the steps you can take to investigate and resolve the issue. And also determine if you are able to solve the issue yourself based on your skill level. But how can you determine if an issue is technical or functional?

First, you will need to understand the difference between these two types. A functional error can be seen as an error where the user expects something to happen. But the system does something else.

With functional errors, there is a lot of room for interpretation, depending on the person who looks at it. A programmer (low-coder) will say the action works without any issues, but an end-user will say it does not work because it does not meet the user's expectations.

For example, when a user creates a new project, the user expects that the status of a project will be set to ‘new’ by default. However, the logic that actually creates the project is configured so that the default status will be set to ‘In progress'.

In this case from the user's perspective, it does not work, but from a technical perspective, it works perfectly.

A technical error will typically always generate some kind of error message that will be visible to the end-user and/or the low-coder. Making a lot less room for interpretation.

For example, when something goes wrong after a form is submitted. The following error will show up.

Now that we know the difference between a technical and functional error, we can determine the type of issue that is reported. Again, there are different methods you can use: from simple to very complex. We prefer a very simple but effective approach.

You can classify the issue as a functional error when a user is able to finish a process within the application, and the end result does not meet the user's expectations.

If this is not the case you can classify the issue as a technical error.

The following diagram could be helpful.

Example: When a user creates a new project, they expect that the status of a project will be set to ‘New’ by default. However, the user notices that the status of the project is set to ‘In Progress'.

Because the user is able to complete the process of creating a new project without any errors you can say that this is a functional error.

If the user was unable to complete the process and got stuck or got an error that was not designed, you can say that this is a technical error.

Note: This logic is not 100% accurate and you always will have exceptions.

Depending on the skill level of a person, you could determine what type of issue should be looked at by what type of developer.

Technical errors usually require more knowledge of the Betty Blocks platform and IT knowledge in general. Functional errors could be more easily solved once you know where to look. They do not require a high IT knowledge skill level.

Because functional errors most of the time happen due to a wrong configuration somewhere in the business logic of an application, these types of issues are likely to be solved very fast by someone who has a good understanding of the business logic within the application. Typically that is a business technologist or a low-coder (rarely citizen developers).

Technical errors typically require a better understanding of the underlying IT technique to investigate and solve the issue, so low-coders are the best for these kinds of issues.

Now that you are able to reproduce the issue and identify the issue type, you can start debugging. Each issue is unique and requires a different type of approach - it is very hard to create a step-based plan that will always help you to find and solve the issue.

To give you more insight into what the possible options are, we will provide several example issues, tools, and steps used to identify and solve the issue in the end.

Each example will contain details about the issue and then the steps taken to investigate and resolve the issue.

A common error is an error that an action is started but the end result does not match up with the user's expectations. For example:

Topic

Unable to create new tickets within @debug-example application.

Description

When I try to create a new ticket, the ticket is not showing up on the ticket overview page.

Current behavior

When I try to create a new ticket, I am able to fill in the form and press the Save button. The ticket does not show up on the ticket-overview page.

Expected behavior

After I have filled in the ticket fields and pressed the Save button. The ticket must show up within the table on the ticket-overview page.

If we follow the diagram, we can determine that this is a functional error. Your first check should be in the configuration of the application itself. In this case, it's an action that will create a new ticket.

First, we can go to the page itself, find the form component, and view the linked action.

When we take a closer look at the action, we can see that the action contains a single create event. And the create event itself also looks good, meaning the configuration of the create event does not contain any unknown variables, UUIDs, or other strange settings.

So it is safe to say the action itself is not the issue

The next step you can take is to see if the ticket data is being created within the back office page. If the ticket data does show up in the back office, you can eliminate the option that the action is not being started at all.

By doing so, we can also test the form itself. In this example, we see that the form itself does work correctly because a confirmation message is displayed after submitting the form.

When checking the ticket overview we can see that the ticket is not listed on the table.

So now, let’s take a look at the back office data. When opening the back office page and looking at the ticket data here, we can see that the ticket has been created and added to the database of the application.

Since the ticket is created, we can eliminate the option of the action not working.

As you might have noticed, the status of the newly created ticket is empty. And all other tickets do have status. So perhaps the ticket overview page is set up so that the tickets without any status are not displayed.

Take a look at the data table and the way it has been configured. Here we can see that the table indeed has a filter option configured.

When looking at the filter settings, we can see that the tickets without status are not visible within the table.

You can now solve the issue in multiple ways. Update the action so that the ticket always gets a default status, or you can remove the filter of the data table. In this example, we have removed the filter and that will solve the issue. As you can see below the ticket is now listed in the table.

This basic use case may serve as an example of how you have to approach debugging. For other more advanced cases of issues within the action builder, we recommend looking into Testing and debugging an action article.

Along with that article, there's Using the log message step explaining the tool you can employ to pinpoint where something breaks within your action flow. It creates a lot of insight visible through logs.

If you have a compiling error while saving the progress of your action flow configuration and wonder at what step it occurs, it's possible to identify that by reading logs. Here we will go through such a case to demonstrate how to deal with it.

Topic

Unable to compile the action in @debug-exmaple.

Description

When I try to save the configuration of an action step, I am getting a compile error.

Current behavior

When I try to save the configuration of the action step, I get the compiling error. I am able to save the configuration, but the action itself isn't compiled in the right way.

Expected behavior

When I save the action configuration, I want it to be saved and compiled.

After you noticed that the action isn't compiling (see the red cross next to the action's name), go to Tools > Logs to see the latest actions done in the application. Find the right error you received while compiling this exact action.

Within the log message, check for the action and action step IDs in square brackets:

Copy these to your action's URL like in this example and the exact action step that contains an issue will open.

From this point, it's quite easy to recognize what was the initial problem: one of the model properties is missing which leads to the error while compiling.

The Betty Blocks platform uses the GraphQL technique to request and display all the data within the page builder. So if something goes wrong in loading the data on a page, a common error is a GraphQL error.

This typically happens when the permissions for a user (or public) page are not set correctly to display the data on a page builder page. For example:

Topic

Unable to see ticket information @debug-exmaple

Description

When I try to view the ticket information I am getting a strange error.

Current behavior

When I try to view the ticket information I am getting a strange error. I am able to visit the page but the table is not displaying any ticket information.

Expected behavior

When I visit the ticket overview page I want to see all the tickets and the information.

The error itself on the screen says GraphQL error: Unauthorized for model(s)... Based on the diagram flow we can determine that this is a technical error.

Note: As mentioned before, this type of error should be looked at by someone who has more knowledge about the platform and IT in general - a business technologist or a low-coder.

The error itself could already give you an idea of how to solve the problem. But if you want to see the complete error message, or need more information. You can use the developer tools of your browser to get more information.

You can open the developer tools by right-clicking and inspecting your page or use Option + ⌘ + J (on macOS), or Shift + CTRL + J (on Windows/Linux).

And now you can select the network tab.

The network tab will help you to see what requests are being made when the page is loaded and find more details of the requests. In order to see the requests, you must have the network tab open, and then reload the page so that all requests will be visible

To reduce the amount of information that will be shown. Use the Fetch/XHR filter. The result will look something like the below:

As you can see there are several requests being made. The trick is to find out the right requests. All requests that will be made to the DataAPI of a Betty Blocks application will have a UUID as the name. Once you click on a request you are able to get more information and are able to see for example the complete error (in the preview tab):

Working out the case like that, you'll be able to collect the needed information to resolve the case. For instance, this one is pretty typical: you have to set the permissions for the Ticket data model.

Hopefully, you got a general idea of how you can resolve some typical issues on your own. In other more advanced cases - don't hesitate to reach out to our support. And remember: the more info you can collect, the faster we will be able to help you!