TypeError: Cannot read property 'name' of undefined

Hi Brian,

coming from #2454, cratedb-nodejs-parameterized-returning.js is a repro in order to trigger an async/timing issue with node-postgres. It eventually reveals a problem with parameterized statements in conjunction with a RETURNING clause on the pure-JS driver variant, thus indicating a flaw within node-postgress response handling.

The documentation how to run it is inlined into the program (cratedb-nodejs-parameterized-returning.js --parameterized --returning). When adding the --improve command line option, the situation improves slightly but obviously this is not a solution. As I’ve mentioned within #2454, the problem does not happen when using pg-native which you can conveniently enable by using the --native command line option.

Below, I’ve shared details of the tracebacks. The first traceback has already been discovered by @ugate and reported through #2168.

Thanks already for looking into this!

With kind regards, Andreas.

cc @vitaly-t

---

Mostly, this repro yields:

TypeError: Cannot read property 'name' of undefined

Trace: TypeError: Cannot read property 'name' of undefined
    at Result.parseRow (/path/to/node_modules/pg/lib/result.js:66:34)
    at Query.handleDataRow (/path/to/node_modules/pg/lib/query.js:87:26)
    at Client._handleDataRow (/path/to/node_modules/pg/lib/client.js:345:22)
    at Connection.emit (events.js:315:20)
    at /path/to/node_modules/pg/lib/connection.js:115:12
    at Parser.parse (/path/to/node_modules/pg-protocol/dist/parser.js:40:17)
    at Socket.<anonymous> (/path/to/node_modules/pg-protocol/dist/index.js:10:42)
    at Socket.emit (events.js:315:20)
    at addChunk (_stream_readable.js:309:12)
    at readableAddChunk (_stream_readable.js:284:9)
    at Socket.Readable.push (_stream_readable.js:223:10)
    at TCP.onStreamRead (internal/stream_base_commons.js:188:23)
    at /Users/amo/dev/crate/troubleshooting/npm-pg-001/cratedb-nodejs-parameterized-returning.js:160:13
    at processTicksAndRejections (internal/process/task_queues.js:93:5)

Occasionally, it will also croak like:

TypeError: Cannot read property 'handleDataRow' of null

/path/to/node_modules/pg/lib/client.js:345
    this.activeQuery.handleDataRow(msg)
                     ^

TypeError: Cannot read property 'handleDataRow' of null
    at Client._handleDataRow (/path/to/node_modules/pg/lib/client.js:345:22)
    at Connection.emit (events.js:315:20)
    at /path/to/node_modules/pg/lib/connection.js:115:12
    at Parser.parse (/path/to/node_modules/pg-protocol/dist/parser.js:40:17)
    at Socket.<anonymous> (/path/to/node_modules/pg-protocol/dist/index.js:10:42)
    at Socket.emit (events.js:315:20)
    at addChunk (_stream_readable.js:309:12)
    at readableAddChunk (_stream_readable.js:284:9)
    at Socket.Readable.push (_stream_readable.js:223:10)
    at TCP.onStreamRead (internal/stream_base_commons.js:188:23)

[brianc]

I want to deeply apologize if these aspects have not been covered by other test harnesses of CrateDB and would just have been revealed by your investigations

absolutely no problemo at all, no apology needed!

At the same time, I am really grateful for this excellent feedback. I will get back to our core engineers about that and then report back to you.

great! I’m happy to debug & diagnose more too…or if you want an engineer to get on the phone or something with me just email me & we can set something up. I want to make sure cratedb has first class support with this driver all the way.

[amotl]

Dear Brian,

thank you very much for your prompt response and your investigations which revealed a problem to us, where CrateDB was not responding correctly to PostgreSQL wire protocol requests. Sorry for the noise.

@mfussenegger (also thanks a stack!) added a mitigation on behalf of https://github.com/crate/crate/pull/10979:

If the flush triggers the deferred executions, then a follow up sync() returned a completed future. This led the pg-write layer to immediately send a ReadyForQuery message to the client, even if the operations triggered by the flush weren’t finished.

This patch improves the logic so that flush sets the activeExecution property, which will then be used by sync. This ensures that the ReadyForQuery message is sent after the operations have completed.

I have been able to confirm that the repros now work flawlessly using the most recent nightly release of CrateDB. The fix will be part of the upcoming GA release 4.4.1.

With kind regards, Andreas.