Can we see a screenshot of your resource manager setup related to your new server?
Can you expand one of the q_list_country_timezones records and show all the fields? - I wonder whether there is a field name that is conflicting and/or overwriting something in there
I just started experiencing this issue as well. And independent of this post found that $value indeed worked @patrick is this expected behavior? What would cause a server to suddenly require $value where previously (like for years) it had functioned otherwise fine? Thanks!
Hi @sid,
Adding a prefix with $value inside the repeat did resolve the issue. But there are tens of repeat steps with 100s of data bindings, so itās not an easy fix to apply.
The project is running correctly on the localhost and a remote server (Linode) without the prefix $value, so, thereās no pattern that can be identified.
Unfortunately, I donāt have a way to replicate this either.
We stumbled upon the problem randomly, and trying things, found $value as the solution.
But in my case, I faced the issue in local and server both. I use DO with Caprover/Docker for deployments.
One observation, that seems to be common here, is that its happening only in case of nested repeats, and not single repeat.
I have not noticed any change in any core lib files in recent updates that would indicate such a change, but maybe I missed something.
I initially thought that it was happening only with custom server deployment; but since then, I have tested by deploying projects on DO and Linode, and all these deployments are returning empty arrays.
You should try doing a new local deployment as well. Maybe the repeat is still working on local due to some server caching? But with a new local target, you might be able to reproduce this locally.
Add me to this list, and it appears to be a problem that rolling back in git does not resolve.
I have now reverted to 6.4.1 and pushed to staging and that does not resolve.
@patrick @George @Teodor can you please comment on this as pushing a solid code base to a remote droplet is now foobar.
I tried redeploying to the local target yesterday and it worked. But Iām now going to wait for a resolution before attempting another redeployment locally. If it stopped working locally as well, then I wonāt have any fully functioning dev and staging environments.
The strangest part is that rolling back the code and rolling back the editor does not resolve. Iām stumped on this and canāt do any work until a solution is found.
We actually didnāt have any changes in this area for long time. It is all being stable.
Maybe something wrong with query/database or output settings? What is your case @mebeingken
Here is my long-winded answer. 
- Production target is working normally and was updated a few days ago
- I am now attempting to use the master branch which is what is in production
- My local docker target works as expected
- My remote DO droplet has āthe issueā
- The issue appeared for me yesterday after updating to 6.4.2 and deploying to staging. I then tried reverting back as far as 6.3.3 and cannot make the problem go away.
The issue is:
- A repeat that has a source query outputs empty objects.
- The source query has the expected data
- I have tried modifying the output fields from Include to Exclude, both with an empty array of values
Here is my staging target. You can see ābasicsā is an array of empty objects, yet āqry_basicsā is the same array but with all the data:
Here is the same thing on my local docker:
The Library in question:
I should add that I have been extensively bouncing back and forth with Experimental/Beta in order to test with AC2 but I am now on Experimental Off and Stable channel
Another example but slightly different:
- db query
- loop through the results (NO OUTPUT)
- Set a couple of values based on the repeat
So it looks like the repeat does not have access to the query results, regardless of the output settings of the repeat.
When no output is selected on the repeater then the output data will be always empty, no matter if you have elements with output on inside
Understood, and Iām not expecting something other than that.
My point is that the set values based on that repeat DO have output on, and they too are coming up empty. Again, all working on other targets.
Itās as if something was uploaded to a target at some point (maybe during the Experimental or Beta pushes), that is not a part of the repository (since rolling back does not change anything.) I have gone back to Wappler versions from January, and git commits from then as well. Once the problem is in the target, it just wonāt go away. 
Luckily (for my sanity) other people are seeing the same thing.
Just to confirm you have this issue only on the remote but locally it is all fine?
Well if you can determine the difference between those targets, what files are different?
Correct, a local docker deployment works fine, a remote DO droplet in production works fine, and the problem persists on a remote staging DO droplet. They all use the same dockerfile.
What is there to compare? Or perhaps better, how do you recommend I do this?
All 3 targets are docker containers so what areas could be different?