Core Bug: `Cannot read properties of undefined (reading 'toUpperCase')`

[titanism]

Core Bug: `Cannot read properties of undefined (reading 'toUpperCase')`

[titanism]

This seems to happen when node is a Date.

[titanism]

@andris9 see #619, we wrapped the switch statement with a conditional of if (typeof node?.type === 'string') {

[andris9]

How do you have a Date object as the node? This is not a supported value for the response compiler.

[titanism]

@andris9 Hi there 👋 We debugged this and here's what we came up with:

First, we invoke WildDuck's prepareMessage function with the options { flags, date, raw }:

{
  flags: [],
  date: 2024-02-09T17:20:55.421Z,
  raw: <Buffer 44 61 74 65 3a 20 32 30 32 34 2d 30 32 2d 30 39 54 31 37 3a 32 30 3a 35 35 2e 34 32 31 5a 0a 4d 49 4d 45 2d 56 65 72 73 69 6f 6e 3a 20 31 2e 30 0a 43 ... 197 more bytes>
}

The mime tree then gets parsed via let mimeTree = options.mimeTree || this.indexer.parseMimeTree(options.raw);:

{
  header: [
    'Date: 2024-02-09T17:20:55.421Z',
    'MIME-Version: 1.0',
    'Content-Language: en-US',
    'To: [email protected]',
    'From: [email protected]',
    'Subject: 2f46c154-efd0-4c4e-ac7f-079e6cd50200',
    'Content-Type: text/plain; charset=UTF-8; format=flowed',
    'Content-Transfer-Encoding: 7bit'
  ],
  parsedHeader: {
    'content-transfer-encoding': '7bit',
    'content-type': {
      value: 'text/plain',
      type: 'text',
      subtype: 'plain',
      params: [Object],
      hasParams: true
    },
    subject: '2f46c154-efd0-4c4e-ac7f-079e6cd50200',
    from: [ [Object] ],
    to: [ [Object] ],
    'content-language': 'en-US',
    'mime-version': '1.0',
    date: '2024-02-09T17:20:55.421Z'
  },
  body: <Buffer 74 65 73 74>,
  multipart: false,
  boundary: false,
  lineCount: 0,
  size: 4
}

Then the returned envelope object parsed via let envelope = this.indexer.getEnvelope(mimeTree); like this:

[
  '2024-02-09T17:20:55.421Z',
  <Buffer 32 66 34 36 63 31 35 34 2d 65 66 64 30 2d 34 63 34 65 2d 61 63 37 66 2d 30 37 39 65 36 63 64 35 30 32 30 30>,
  [
    [
      null,
      null,
      <Buffer 62 65 65 70>,
      <Buffer 62 65 65 70 2e 63 6f 6d>
    ]
  ],
  [
    [
      null,
      null,
      <Buffer 62 65 65 70>,
      <Buffer 62 65 65 70 2e 63 6f 6d>
    ]
  ],
  [
    [
      null,
      null,
      <Buffer 62 65 65 70>,
      <Buffer 62 65 65 70 2e 63 6f 6d>
    ]
  ],
  [ [ null, null, <Buffer 66 6f 6f>, <Buffer 66 6f 6f 2e 63 6f 6d> ] ],
  null,
  null,
  null,
  null
]

This is all OK. However we store it in SQLite and when it gets parsed/fetched again, the string looks like a date, so it gets converted to a Date. This is the culprit for the issue (totally on our side, but might be nice to have dummy-proofing it's a date to convert to a string, in case someone else has a similar approach).

[titanism]

We've fixed this on our side already, feel free to close unless you decide it's worth having a conditional check for node.type as a Date and convert to string via toISOString():

//
// NOTE: this is an edge case because of how we store envelopes
// <https://github.com/nodemailer/wildduck/issues/618#issuecomment-1933139110>
//
value = message.envelope.map((a) =>
  a instanceof Date ? a.toISOString() : a
);

Note the code above is our adaptation from getQueryResponse:

      case 'envelope': {
        if (message.envelope) {
-          value = message.envelope;
+          //
+          // NOTE: this is an edge case because of how we store envelopes
+          // <https://github.com/nodemailer/wildduck/issues/618#issuecomment-1933139110>
+          //
+          value = message.envelope.map((a) =>
+            a instanceof Date ? a.toISOString() : a
+          );

          // cast invalidly stored In-Reply-To (8) and Message-ID (9) to strings
          for (const index of [9, 10]) {
            if (value[index] && Array.isArray(value[index])) {

[andris9]

Thanks for the explanation. I'd prefer less magic here, and I think it is good to have an exception when parsing internal structures with expected values - helps to detect problems sooner. I'd also suggest not labelling issues as "core bugs" unless you have a reproducible test case, otherwise the issue can be overlooked even if it identifies a real problem.