Hello,
We have a 8.3.8 gateway with ~10 production critical (manufacturing) projects, each project has its own tag changes and gateway scripts.
We migrate code to this production server via git and use system.project.requestScan from the gateway UI, eventually from a hook to call it from the api.
For simplicity sake, lets say today I need to change the color of a button in one of the projects - does that mean I have to shut down the entire factory while request scan is running to prevent missed gateway messages?
What we had happen today was we did a very small update to one project (scripts and ui, not messages) and request scan triggered "Restarting Gateway Scripts" on every project (plus a billion client session errors?). The top line in the screen shot shows that caused us to miss a gateway message, ultimately resulting in equipment downtime.
Looking for some advice - am I misunderstanding or doing something wrong? Its a tough ask (impossible) for me to tell the plant to shut down every time we update these apps.
Thanks,
Jake
This is a surprise. I would have expected only the changed projects to restart. Unless, you had resource.json timestamps/hashcodes changed in the git repo. After you did the project scan, did git show any new changes scattered across the projects?
(Presuming you aren't using .gitignore to omit resource.json.)
The changed project got two new commits spanning 2 views (resource.json, thumbnail.png, view.json) and 2 scripts (code.py, resource.json). The other projects wouldn't have had any files changed, although its not impossible something touched their timestamps?
Git should tell you (via git status) about uncommitted changes in the gateway. Note that if a resource had to be re-hashed, and the project was inheritable, any child projects of it would also restart.
No one develops using the designer on this gateway so the working directories are always clean.The other projects all got a new commit ~12 days ago for the necessary conversion from binary to .json messages after the 8.3 upgrade, but aside from that they are very static. We scanned after doing that, and have scanned almost every day since then (maintaining this one project) and always, it shows every project getting restarted.
This project in particular inherits "global" but global remains static aside from the aforementioned 8.3 commit.
I wonder if this has something to do with that dang last modification entry we still haven't gotten rid of...
So i explored @pturmel's suggestion that this may be related to uncommitted changes on our gateway.
First I ran the following command on the repository root of our server:
$scanTimestamp = Get-Date
$repoCount = 0
$dirtyFileCount = 0
Get-ChildItem -Directory -Recurse | ForEach-Object {
if (Test-Path "$($_.FullName)\.git") {
$repoCount++
$status = git -C $_.FullName status --porcelain
if ($status) {
Write-Host "`n$($_.FullName)" -ForegroundColor Yellow
$status
$dirtyFileCount += @($status).Count
}
}
}
Write-Host "`n===== Git Repository Scan Summary =====" -ForegroundColor Cyan
Write-Host "Scan timestamp: $($scanTimestamp.ToString('yyyy-MM-dd HH:mm:ss'))"
Write-Host "Repositories scanned: $repoCount"
Write-Host "Total dirty files: $dirtyFileCount"
I first verified the effectiveness of this command on our dev server (which I know has "dirty files") and received the following output:
I repeated this command in our test server and confirmed there were no "dirty files":
I proceeded then to run scan File system which resulted in all projects on the gateway restarting (even though there was no file changes)
It seems like the requestScan command is restarting gateway scripts regardless of whether files are being changed:
After rescanning, I repeated the above command and verified that there was no files changed as part of the file scan process:
I opened an issue for this yesterday. I think that once you've pushed an external resource to a project, the last modification won't match until the resource is saved some time later in the Designer, and that is triggering the project restarts because the system thinks one of the project resources were modified.
In your setup where you only ever modify resources externally, eventually all projects will get caught up in this.