Server API repeat steps returning empty array on a custom server (Vultr) deployment

[guptast]

Hello.

Today I created a new server on Vultr Cloud and added that as a custom server in the Resources Manager. The server has been correctly added and I have successfully deployed an existing project on the server.

However, I have noticed that all the repeat steps in the server APIs have stopped returning any data. The other steps are returning data correctly, but the repeat steps are returning empty arrays. There are no errors in the dev console. The only difference between working and non-working deployments is the deployment of this project on a custom server. Any help in resolving this issue is greatly appreciated.

[kfawcett]

Are there any errors in the Network or Console tab?

Is the API pulling data from the server database? If so, does the database have data for the repeat?

[guptast]

Hi Keith, thanks for the response.

There are no errors in the network or console tab. The database has records. The project is running correctly on another remote server. This is an issue only on the new custom server.

All the other API steps are returning data correctly. It’s only an issue with the repeat steps in all the APIs.

[sid]

Hi.
Few suggestions to check:

1. How the repeat works is based on the Wappler’s core files. Double check on the server if the files have been transferred correctly.
2. The repeat step is working without any exceptions, so point 1 is probably not applicable. The source of the repeat step is a query. Enable output for that, and check if the query is returning the value as expected of not. Could be some firewall on the Vultr server, or on the DB server, not allowing to access DB correctly.
3. View the logs of the remote server, just like the logs are shown in Wappler. You will have to SSH into the server and run some commands. If you are running the application over docker in the new server, try installing Portainer to easily view the logs on the browser.

[guptast]

Hi Siddhant,

Thanks for the suggestions. I will check these, especially the second point about checking the source query for the repeat. I will update the post after running these checks.

[guptast]

Here are my findings:

1. Created a new server
2. Deployed the project; Enabled output of the source query for repeat
3. Source query is returning data correctly
4. Repeat step is returning empty array
5. No errors logged - checked in Portainer and Wappler Web Server

It seems custom server setup is running the core files differently to the server setup under already available service providers such as Linode.

Vultr was available as a cloud service in the now deprecated Sockets method, but it hasn’t been added as a cloud provider in the Resources Manager.

[guptast]

Is there any other process or setup I can look at to resolve this issue?

[bpj]

Can you post a screenshot of the repeat step? Have you made sure the output is set to ‘exclude’ with an empty field list? (Or include and the fields you want outputting added to the list)

[guptast]

Hi Ben,

The repeat steps have been setup either with include and fields or exclude and empty field list. Both repeats are failing. These are the screenshots of the API steps and output in dev console.

There’s no error in the dev console and all the APIs are working correctly on another remote server. The only difference is that these repeat steps are failing on the server that has been added as a custom server in Resources Manager.

Screenshot showing data from the source query output enabled and repeat showing empty arrays

[sid]

What is the NodeJS version on server where its not working… vs where its working?

[guptast]

Both servers are running Node v18 Alpine.

[famousmag]

Buddy just in case…
Can you check:

• if the rpt_listcountry_timezones has also 418 records
• if you disable these setValues inside the repeat (that pull theeir values from the query) and just add a new one for test for example indx=$index and output it, will you get 418 records
  (with indx = from 0 to 417)?

If the above steps are ok then probably the query setup is not combatible with the new server…
(I suppose )

[Hyperbytes]

Just in case it is a scope/namespace issue, try pre-defining the set value stages before the repeat with a matching global value like this.

Also add the global name to the Set value stages in the repeat.

[guptast]

@famousmag Interesting! The set Value inside the repeat is getting a correct value of the $index.

So, it seems there’s an issue with the new server not compatible with the query setup, when the server has been setup as a custom server in the Resources Manager.

[famousmag]

So, next step…
Can you show us in detail the query setup?
Maybe somebody in here or patrick can make sense what the problem may be…

[famousmag]

And of course don’t forget the new custom server setup details…
Maybe there is a problem

[guptast]

That’s what I think is happening. The custom server details in the project.json file are missing many details when compared with the server added from the available service providers such as Linode.

Custom server details in the project.json file. There’s no ssh_key record associated with this entry in the file along with other details such as server id, region, server specs etc.

"servername": {
      "ip_address": "xxx.xxx.xxx.xxx",
       "user": "root",
       "access": true,
       "services": {
       "traefik": {},
       "portainer": {}
 }

[sid]

Project.json is just for Wappler to understand the project. It does not have any impact on the deployed application.
Although, if Wappler is reading and filling information in some production target file, that could impact the remote server.

One other idea: Add a insert-query step, and log the $value inside repeat.
We recently had a situation where being inside repeat, Wappler would refuse to access properties of repeat-source directly. But when doing the same with $value.xxx it would work.

[guptast]

I didn’t understand the steps completely, @sid. Could you please explain the setup?

[sid]

1. Create an insert query step and select a table where you can keep just 1 TEXT column data. In the column, set the binding as {{$value}}.
2. Place this step inside the first repeat. You can capture other details in other columns if you want. This table would be like a test table.
3. Run the SA and post deployment, check the DB - if you can see the value, it could mean that you repeat bindings require you to use $value. prefix.