Every so often our Perspective project runs into log messages scoped at perspective.ClientSession with a message of Received prop sync for missing view.
What scenario would trigger this message on the gateway? Is a client session misbehaving and causing these messages? Did the gateway "forget" an instantiated view?
“Bump!”
This is most commonly encountered when a session has multiple tabs open and a single tab of the browser session is closed by a user, but can also be encountered any time the Gateway loses connection to a session. As such, network issues and even potentially resource starvation could result in you seeing this message.
Essentially, what you’re seeing is that the Gateway believes a View (which contains a binding, or a script which writes to a prop) is in place for a session, but the View was removed from the session without going through the OnShutdown process. As I alluded to before, this can be encountered in a multiple tab scenario because the session remains active because at least one tab is still open, but the closing of the secondary tab does not always de-register the resources in use; so the session receives the information for the missing view and has no idea what to do with it.
So it’s not so much the Gateway “forgot” the view, but moreso that the View was removed from a session without properly informing the Gateway.
This can ALSO be encountered if you perform a lot of HTTP navigation (URLs) instead of page navigation, because the HTTP request results in the page not shutting down properly. The HTTP request results in the “current” Perspective page getting a new ID, and since the old page did not get a chance to de-register content, the Gateway doesn’t know what happened to it.
The warning/error should be benign most of the time because the page being referenced is no longer in use, but we have encountered some instances where Alarm Tables begin encountering issues if they are on a page which is navigated back-and-forth from-and-to with HTTP navigation.
Just for reference, this happened to me today. I only had one tabcopen. And it started happening on another project that I had just tested and was fine.
I ended up restarting the Ignition service and it seems to have gone away. I'm glad it was a dev server.
@ken.maze Any chance you had a Designer session open for that Gateway?
I did, I was in active development when this started, but it seems more complicated than that. Many of the perspective sessions on one of our gateways, and my designer PC on a different gateway, were all coming up on the Ignition status pages as having the same IP address. That IP address I believe is one of our ZScaler servers. I don't have any problems with the perspective sessions on the other gateway, thank goodness because they are all production, but my development gateway, where yes, I generally have a designer session open, is still occasionally giving the error above.
It did that for two days, and now I just checked it, and everything looks back to normal. Perhaps I was in a development fever dream when I saw it. One way or another, I'm pretty sure I will never find out unless/until it happens again and blows up spectacularly, but I'm going to keep an eye on it.
It happened again this afternoon, and all IP addresses looked normal to me, perhaps that was a very strange red herring.
But, I did shut down the designer, which I was running under the same IP as my test session, and it stopped. When I started the designer back up it was back. It doesn't seem to be affecting anything, but it's odd, therefore I don't like it 
Going to bump this post...
Running Ignition 8.3.6, we observed this message being sent at least ~10 times/second for a sustained duration, all from the same view. Bumping the particular view resource that was referenced in the swarm of logs made it go away. This is after ~3 days of uptime and an average of 100 perspective sessions.
Is this something that is fixed in 8.3.7?
Is there any way to prevent the log message from being spammed?
No, because we haven't been able to lock down the root cause.
I'm looking into that now, but highly unlikely.
@paul.longtine , when you encountered this, did you (or some associate) have a Designer open to the View in question?
I do not believe there was a designer session that had triggered this. The only instance of a designer session was yesterday.
Perhaps a client session was misbehaving/the websocket connection was in a strange state for some clients?
It was hard to pinpoint if it was coming from a particular client session. Perhaps in the MDC logging there could be a reference to the originating session ID?
Good news and bad news.
Good:
I was able to get a reasonable diagnosis of the problem into an actionable ticket. I'll hand it off to the Perspective team so they can determine when a fix can be done. I don't have insight into when that will be, but we'll update this thread when the fix is completed.
Bad:
There's no way to prevent the logging. You could set your Logs page to require ERROR, but then you'd be ignoring any other WARNING level errors. I understand the current logging symptom is a major problem, but there's no way around it because of where the logging is: that logged line will trigger anytime a binding updates on the "orphaned" Page/View in your browser. That binding update gets sent to the Gateway, the Gateway has no View with that id registered, and a new line is logged. For pages with many updating bindings, or bindings that refresh quickly, these un-mapped entries compound.