We maintain a "live" gateway and a "test" gateway on separate servers. We develop projects on the test gateway, and when we consider them ready we export them and then import them on the live gateway for general use. If the project to be imported is an update and an older version already exists (it usually does), we give it the same name and tell the live server to overwrite anything existing. Up till yesterday, this arrangement worked fine.
Yesterday, an attempt to import a project failed. A message appeared saying that the Gateway was reporting that it could not import the project. The project in question has been updated via this same re-import process a half-dozen times before without any trouble. It is quite a large project (about 20MB when compressed, about 43MB on disk in its natural state in the data/projects folder). It is our main UI project (most of the bulk is views) and is the default project users are sent to when they browse in.
Because this was an update to an existing project, I thought I should try expressly deleting the existing project first and then importing; but this resulted in a new error message saying that the project "could not be fully deleted". It vanished from the list of projects, even so; but importing the new project with the same name still failed with the same message at that stage. So I restored everything from backup and figured I'd post this today.
Some questions:
Nothing about the failed import and delete appears in the usual diagnostics log. Are there other logs that might give more details about the issue(s) encountered during the delete and import attempts? Are there logging settings that can be adjusted to record and/or show the problem if I trigger it again?
Any guesses as to why a project would not delete completely? One thing I did not try yesterday was to look at the data/projects folder to see which files, if there were any, were still present after making the attempt to delete the project.
I saw another post that suggested that the size of the file being imported can be a problem when it exceeds what the gateway will upload, and that the solution was to manually unzip the project in the correct location. This problem is a bit different in that it also involves a large import file but it seems like removing the existing project is the immediate cause of the error. However, as a potential solution . . . if the existing files were manually deleted from the data/projects folder and the new project was manually unzipped there, might that be a workaround? Or is there more to "deleting" a project than just removing the files from data/projects?
I would expect something in the gateway's system logs/wrapper.log if there was a legitimate backend exception, but I think what may have happened is more complicated...
My only guesses would be a timeout (where the frontend gave up because the backend took too long to respond, but the operation still went through) or something strange happened on the filesystem, but that would absolutely throw an error into the gateway's logs. Looking at the data/projects folder would absolutely be useful if this happens again.
My hunch is that it's something like a disconnect between the gateway webpage 'frontend' and the 'backend', and in that disconnect the frontend is just displaying a misleading/confusing error message.
This would absolutely work. The 'source of truth' for projects in 8.0+ is the filesystem. Note that as of 8.1 you will have to wait up to 5 minutes (or call system.project.requestScan()) for the gateway to reconcile its internal state with whatever the filesystem has, but the filesystem will always 'win'. There's no other persistent bookkeeping in Ignition for what projects exist - just the scan of the filesystem that's parsed and loaded into memory.
That all said...
This seems like something's gone very wrong with your project design. Views are JSON files; at ~1 byte per character you're talking about a lot of data being stored persistently in your project. Are you deliberately marking datasets persistent or storing lots of data URI images or something else "weird", for lack of a better word? Standard view configurations in a project will basically never hit tens of megabytes.
I will try to see which files, if any, survive the deletion process later today. If something jumps out at me, I'll post.
The trouble with the project design appears to be not so much "gone wrong" as "gone unnoticed". I zeroed in on one of the larger view files and discovered that the custom property holding the data for a large chart was set to "Persistent" and it was storing almost a full megabyte of chart data. Why? Because an earlier chart that served as a starting template persisted its custom property, and nobody changed it because the chart "worked fine." There are probably tables and other data containers that were created the same way. Copy, paste, modify, repeat, and eventually, 43MB.
Now that we know the project isn't supposed to be anywhere near this large, the file sizes will highlight the views with similar issues. I suspect there are a whole bunch more to find. Thanks for the pointer!