I just tried to restore a gateway backup and ran into an error where the gateway didn't find any projects and complained about sql bridge RPC handler issues. The only thing I can think of that's weird about this backup is it has a project with several windows, named screen_1 through screen_5, would that cause some name collision issues?
EDIT: More info: apparently if a project is part of a gateway backup and that project is corrupted, it can kill the entire gateway restore process's ability to deserialize the rest of the projects in the gateway.
Got the wrapper.log files from that Gateway? I'd imagine there's at least one big error / stack trace during startup after the restore.
Yep, one of my thumbnail.pngs was missing from the gwbk for 1 out of my 5 projects, and this killed all 5 being restored
(Which, by the way, doesn't seem like...ideal behavior)
No, probably not, but since we're the only blessed party when it comes to writing/managing resources it's never been a problem.
If you share the logs we might be able to make it more resilient in that case.
1 Like
Definitely fair -- though I imagine that with 8.3 full text based configuration this sort of thing becomes more concerning
I'm not actually sure this is a problem. Your gateway still started, and since we couldn't fully read the project as it was specified by its resources, I think we just bail on that project all together to prevent further corruption.
That's what these scary errors are about:
2025-03-05 16:54:38:520 platform-executor-93
###Fatal-An error occurred while reading project resources from disk. Disk-to-memory synchronization will not occur!
Basically the idea is: there was some kind of I/O error reading the project into memory, let's not pretend things are okay, let the user start making modifications to the project, and who knows what if anything ends up getting saved to disk later.
Full text configuration is a possibility, but not the primary driver.
The primary driver is the configuration becomes diff-able. Very few, if any people, will be modifying resources manually. You have Ignition proper and the Open API endpoints for that kind of thing. I could see people working directly on code files, but you'll just have to be careful if you're messing around with resources directly.
So, the issue with this is that my other 5 projects failed to load in as well, and those hadn't been touched.
That's the brittleness that concerns me and is reproducible.
I.e. one project being bad shouldn't kill readin of other unrelated projects
Yeah it looks like the file tree scan gives up on any I/O error, not isolated per project.
It's intentional, with a comment explicitly declaring it as intentional, that any I/O error results in the entire file tree being untrusted. I'll talk it over with another developer and see if it makes sense to change it in 8.3.
Yep. Up to y'all if that's desired behavior, but it definitely surprised me. (Since project independence is pretty strong in the designer)
Project independence depends entirely on how much you use project inheritance.
1 Like
Oh, sure -- but none of these projects inherited from one another.
Followup question -- the same behavior won't happen if i'm importing a single project, correct? (i.e. if a single project import fails due to IO error, the projects not named in that import won't be untrusted)
Thanks so much for the help, by the way!
You may end up just having an issue on the next Gateway restart or file system scan. Not sure...