Inconsistent behavior between machines. server.js error

Installation & Configuration Bug Reports
1

I have two machines I've been testing on. On my development machine, everything is working fine. When I deploy to my test machine I am seeing a lot of errors in server.js emitted to the command prompt when clients try to access the page.

A JavaScript error occurred in the main process: Uncaught Exception:
TypeError: Cannot read properties of undefined (reading 'sessionPath')
at resolvePath (C:\Kiosk\OpenStageControl\Software\resources\app\server\src\server\server.js:48:1)
at Server.httpRoute (C:\Kiosk\OpenStageControl\Software\resources\app\server\src\server\server.js:126:1)
at Server.emit (node:events:394:28)
at parserOnIncoming (node:_http_server:927:12)
at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)

This seems to happen (although I cannot be 100% certain) when trying to access files that are in the root directory. For example, trying to access an image file using "http://XXX:8080/images/bob.png" will never return a response but will log that message.

A couple of other maybe useful things to know...

  1. I'm using a custom module to turn URLs like "http://XX:8080/?id=alice" into loading the correct session file.
  2. this is the command line I'm using to start the server: open-stage-control.exe" --read-only --remote-root . --cache-dir ..\Cache --custom-module KioskCustomModule.js --no-gui --send 127.0.0.1:9666 --osc-port 9667
  3. I'm using 1.14.5

Has anyone seen this before? It's very odd that it seems to be machine dependent.

Rob

2

Does your browser on the test machine block cookies ? OSC relies on cookies in http request headers to pass the client id with the requested file url (the client id is then used to resolve urls against the session path associated with the client).

3

I am accessing both machines from the same client machine and same browser.

4

I managed to reproduce the error with accentuated characters or spaces in the client id, any chance that's the case for you too ? I'll look into it (edit: fixed in v1.15.2).

5

My client IDs are just "pad1" "pad2" etc. I'll try out the updated build and see what happens. Thanks!

6

I'm still seeing this problem with 1.15.2.

While I am unable to duplicate the problem with my local machine, I'm wondering if this might have anything to do with the fact I am using the "?id=XXX" hack to force loading a specific session file from a URL. This has always felt a little suspect given all the caveats about "don't share client IDs." Thoughts? Unrelated?

7

One thing for sure is that you should never have two clients using the same id, is it your case ?

8

I certainly don't intentionally have multiple clients with the same ID but I'm sure it happens on occasion when I am testing and forget I have another browser open. That said, I just came back to this thread because I am seeing generally weird behavior at times, that really feels related to the usage of the id=XXX hack to force a specific session file. I'm adding a comment to that thread in hopes that there is some OTHER solution that doesn't involve "?id=XXX"

9

You never have the issue when not specifying the id and loading said sessions by hand ?

To avoid using the id here's what could work:

  • create an empty session with this in the root's onCreate script:
send('127.0.0.1:10000', '/session', globals.env.session)

this session will act like a hub and send the "session" parameter found in the url (like you did with the id)

  • set the server's load option to that hub session file
  • in the custom module, catch the outgoing /session message and use it to make the client load the session you want.
10

See the other thread for my response on using alternate technique to load session files.

Even after that change (no chance of dupe IDs) I am still seeing occasional instances in which the server gets exceptions on page load. I've attempted to instrument things a bit and it always seems to be during loading of some image file. Since the http requests are running in multiple threads of execution, I'm wondering if something is getting loaded before all the client state is stored.

It looks like resolvePath() in server.js is the culprit and that it is not finding a value for ipc.clients[clientId]. I'm not doing anything 'fancy' with my images... they are all just stored under the server remote-root directory. Maybe it would benefit to be a little accepting of unusual inputs? Or, possibly, something is very wrong that these unusual cases ever happen.

More digging shows that my clientId seems to be changing in the middle of loading a session in some cases. The images load with one clientId and the session files load with another.

If it helps, I note that Safari browser on my iPad causes this problem more than others. Chrome on my Windows machine never makes it happen.

As a test, I changed:

var sessionPath = path.dirname(ipc.clients[clientId].sessionPath)

in server.js to

var sessionPath
try {
    sessionPath = path.dirname(ipc.clients[clientId].sessionPath)
} catch(e) {}

and that seemed to fix it.

11

Thanks for the details, could you tell me the exact version of your iPad please so that I test it when I have some time?

12

iPad Pro 12.9 inch, 3rd generation running iOS 15.1

13

Quick update:
I added this to resolvePath:


	var sessionPath
    try {
        sessionPath = path.dirname(ipc.clients[clientId].sessionPath)
    } catch(e) {
    	console.log("(WARN) resolvePath failed to get session path for clientId="+clientId)
    }

and am occasionally seeing these messages in the server log:

(WARN) resolvePath failed to get session path for clientId=undefined

perhaps the undefined clientId is a clue?

This change DOES solve the overall problem of session loading sometimes causing the server to crash.

14

It seems safari/ios is a bit picky regarding cookies and this could be what causes the issue. I've pushed an attempt to fix it in next release and also implemented a fail-safe in the same spirit as to your suggestion.

15

Thanks! I'll check it out in the next few days.
best, Rob