qfieldcloud icon indicating copy to clipboard operation
qfieldcloud copied to clipboard

Changes not applied

Open gabgarcies opened this issue 3 years ago • 11 comments
trafficstars

Hi everyone,

I do not understand why some changes of my field workers are not applied. They push changes once a day and I have seen on the website that some of those changes have the status "Not applied". image If I try to change the status to "Applied" manually, it does not work either. The action starts but, after a while, it says "Not applied" again (Server error 500).

Why this might happen?

I attach the raw json of one of those not applied changes. raw_json.txt

Thanks,

Gabriel

gabgarcies avatar May 05 '22 11:05 gabgarcies

It does not only happen with a single layer, but it happens occasionally with 3 different layers of the project.

The field workers only edit attributes (not adding/deleting features).

gabgarcies avatar May 06 '22 07:05 gabgarcies

Here I see the log of the Delta Apply that tries to apply the changes: image

gabgarcies avatar May 06 '22 09:05 gabgarcies

Hey @gabgarcies, OPENGIS-Team and QField-Users!

We have the same problem here. Some deltas were made successfully, others not. image

Trying to re-apply them, doesn't work. image

Clicking the ID shows the OSM and some times the selected poly (like in this case). In the upper right I clicked "see jobs". In this case it shows me a list of 4 jobs, because I tried 3 times to re-apply the changes. Clicking the last item at this list (the first try pushing field data from mobile device) it shows: image As you can see, the warning says, that "modifiedFeaturePK" and "sourcePK" doesn't match. In fact that's wrong - they match!

I wonder if there are any problems with data formats in the background? I also checked the content in HTML. For me it looks the same like the applied change underneath.

Any ideas, someone?

Greetings from Germany!

stenk

ThKroschel avatar Jan 17 '23 10:01 ThKroschel

Hi @ThKroschel

It seems exactly the same issue I mentioned months ago, and I regret to tell you it is quite desperating, in terms of QA and productivity, if your project/organization is quite big and involves many workers, devices and continuous synchronizations...

We have been coping with it for 6 months of intense fieldwork. I have not find a solution since then (more than applying them manually regularly). Hard work...!

I think no one from OpenGISch has ever answered me about this issue (they have with other issues).

Good luck!

Gabriel Garcies

gabgarcies avatar Jan 24 '23 11:01 gabgarcies

Hi @gabgarcies and @ThKroschel, sorry for the late response and sorry for experiencing problems during synchronization. Thank you for the detailed explanations, developer highly admire them!

Quick look into your problems shows there I still do not have precise answers other than QFieldCloud failed to find the given feature.

The error 500 is something we know about and will be solved very soon.

Do you experience the "Unable to find feature" error on only one project or in any project? Which data providers cause the issue? Do you usually sync with multiple small pushes in short period of time, or you usually do one big push at the end of the day? If you can find any kind of pattern, especially if you experience this often, would help a lot to find and solve the problem asap.

suricactus avatar Jan 24 '23 12:01 suricactus

Hi Ivan,

In my case:

Our organization was structured with 10 projects for 10 different workers. All of this projects were identical (same files and QGIS project setup) but each one owned unique features based on a specific zoom of a city, so we had divided the city in 10 equal parts.

Files are geopackage and there are relationships between the main files in the QGIS project setup.

The Not applied issues happened, indistinctly, with any of the files that pushed changes (all the files that were editable) and within any editable field in it. I can't describe a pattern here.

Normally, the fieldworkers pushed changes once at the end of the day. They had a Samsung Galaxy tab with no 4G. So they used to connect the tab to their home's WiFi or their cellphone's 4G network indistinctly.

In an attempt to get better results regarding Not applied changes, I have asked my fieldworkers to send smaller parts of changes to sync,. It may work for a while but, ultimately, they appear again.

The only pattern I can describe is that after manually solving all the Not applied changes in a project, and resynchronizing it (in order to send the latest version to the fieldworker), the Not applied changes took a while to reapper (after 2 or 3 days of large pushing changes). Then, after the first Not applied change appears, they appear regularely until you repeat the process of manually solving them. And it seems that they appear more and more often if the project already has "active" Not applied changes.

That is all I can say after spending the last 6 months with Not applied changes.

Regards,

Gabriel Garcies

gabgarcies avatar Jan 24 '23 12:01 gabgarcies

@gabgarcies and @suricactus: We've grapped the JSON data from the website via JavaScript and will turn them into projectdata via QGis...

ThKroschel avatar Jan 24 '23 14:01 ThKroschel

@gabgarcies Thank you for your detailed feedback!

suricactus avatar Jan 24 '23 14:01 suricactus

Sorry... I will leave a more detailed report later on this week - I'm a little bit busy. We had Samsung Galaxy Tabs too, as well as iPhones.

ThKroschel avatar Jan 24 '23 15:01 ThKroschel

@suricactus atm it looks like I have to go the same way: Download JSON from the API and patch the project manually. Seeing that this problem is not limited to our use case this should be labeled as critical!

miili avatar Mar 16 '23 17:03 miili

Here the same problem : #https://github.com/opengisch/qfieldsync/issues/508

GlaDal avatar Jun 14 '23 14:06 GlaDal