Ladder99
Cannot read properties of undefined (reading 'Header')
After configuring the setup.yaml, and adding relay alias's the relays logs roll through several items (some warning on missing alias for devices, and finally all the endpoints with Autoprune start job scheduler for { hour: 0, minute: 0, dayOfWeek: 0, tz:'America/Chicago' } Autoprune scheduled for 2022-10-02T05:00:00.000Z . It finally chokes on an error that looks like the following :
db signal uncaughtException received - shutting down...
TypeError: Cannot read properties of undefined (reading 'Header')
at Probe.read (file:///usr/app/src/data.js:46:38)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async Probe.read (file:///usr/app/src/dataProbe.js:18:5)
at async AgentReader.start (file:///usr/app/src/agentReader.js:48:7)
Diving into the problem
Identification
Diving into the exact line on the data.js script it seems like the following is the key code snippet that is causing the error.
// get Header attributes for probe, current, or sample xmls.
// includes { instanceId, firstSequence, nextSequence, lastSequence, bufferSize, ... }
this.header = this.jsTree.MTConnectDevices
? this.jsTree.MTConnectDevices.Header._
: this.jsTree.MTConnectStreams.Header._
Javascript ternary operator :
condition ? exprIfTrue : exprIfFalse
This line seems to try to check the object MTConnectDevices is not null and set the header to MTConnectDevices if not set it to MTConnectStreams.
I added a console.log to the script and found out that the console.log(this.jsTree.MTConnectDevices) is outputting undefined
Seems like this is not really a header issue but a problem parsing out an endpoint.
Going Deeper
I exposed the entire this.jsTree in the console and started looking at a pattern. After some endpoints I was able to get a successful response of the object. Note: I hid my uuid, host and port information.
Relay warning: the following devices have no alias - could add in setup.yaml.
Alias missing for device
db upsert node **{uuid}**/device: **{uuid}**/device
{
MTConnectDevices: {
_: {
'xmlns:m': 'urn:mtconnect.org:MTConnectDevices:1.5',
xmlns: 'urn:mtconnect.org:MTConnectDevices:1.5',
'xmlns:xsi': 'http://www.w3.org/2001/XMLSchema-instance',
'xsi:schemaLocation': 'urn:mtconnect.org:MTConnectDevices:1.5 /schemas/MTConnectDevices_1.5.xsd'
},
Header: { _: [Object] },
Devices: { Device: [Object] }
}
}
Then shortly after another output from the relay log shows the error propping up right after a not so verbose log output.
Relay warning: the following devices have no alias - could add in setup.yaml.
Alias missing for device
db upsert node **{uuid-2}**/device: **{uuid-2}**/device
{ html: { head: { title: [Object] }, body: { center: [Object] } } }
db signal uncaughtException received - shutting down...
TypeError: Cannot read properties of undefined (reading 'Header')
at Probe.read (file:///usr/app/src/data.js:48:38)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async Probe.read (file:///usr/app/src/dataProbe.js:18:5)
at async AgentReader.start (file:///usr/app/src/agentReader.js:48:7)
Summary
After noticing that the endpoints for both agents where nearly identical the issue may lie elsewhere in the endpoint collection methods. The fix I would propose is to return a handled exception instead of an unhandled exception that stops the relay service all together. I added the following to the data.js file to handle the error :
if (this.jsTree.MTConnectDevices == undefined) {
console.log(this.jsTree)
console.log("TypeError: Cannot read properties of undefined (reading 'Header')")
return false
}
// get Header attributes for probe, current, or sample xmls.
// includes { instanceId, firstSequence, nextSequence, lastSequence, bufferSize, ... }
this.header = this.jsTree.MTConnectDevices
? this.jsTree.MTConnectDevices.Header._
: this.jsTree.MTConnectStreams.Header._
Welp... That didnt work
Caught a nice error in the face with that last idea. Looks like the best thing to do is prob a bunch of conditionals everywhere ... I ended up sticking some variation of the following in the agentReader.js do/while loops.
if ( {insert object from error} == undefined) { continue;}
Hey Hector, thanks a lot for tracking this down! My guess is that one of your agents is returning HTML instead of XML for some reason, as this indicates -
{ html: { head: { title: [Object] }, body: { center: [Object] } } }
I added some more error handling, and had the fetch method loop until it gets a valid looking agent response -
async fetchJsTree(type, from, count) {
const url = this.getUrl(type, from, count)
let jsTree
do {
try {
const response = await fetch(url)
const xml = await response.text() // try to parse response as xml
jsTree = convert.xml2js(xml, convertOptions) // try to convert to js tree
// make sure we have a valid agent response
if (
!jsTree.MTConnectDevices &&
!jsTree.MTConnectStreams &&
!jsTree.MTConnectError
) {
throw new Error(
'Invalid agent response - should have MTConnectDevices, MTConnectStreams, or MTConnectError.'
)
}
} catch (error) {
// error.code could be ENOTFOUND, ECONNREFUSED, EHOSTUNREACH, etc
console.error('Relay error', error)
console.log(`Relay error reading`, url)
console.log(`Relay jsTree:`)
console.dir(jsTree, { depth: 3 })
console.log(`Relay error retrying in ${waitTryAgain} ms...`)
await lib.sleep(waitTryAgain)
jsTree = null // so loop again
}
} while (!jsTree)
return jsTree
}
Hopefully that will be more robust. It's there if you'd like to give it a try - just do git pull in the ladder99/ladder99 folder.
Awesome! I wouldnt know how the agent is sending html instead of a valid xml. I wonder if it has something to do with the agent 2.0 "agent-adapter" that we have been testing.
