Questdb Nodejs Client not working

I get this error when trying to run the questdb client in miniflare. I have posted a minimum reproducible error - https://github.com/apolo-damasco/cf-workers-questdb
⎔ Starting local server...
✘ [ERROR] Error sending data TypeError [ERR_INVALID_ARG_TYPE]t" argument must be of type number. Received type string ('utf8')

at validateNumber (node-internal:internal_buffer:1552:15)
at Uint8Array.fill (node-internal:internal_buffer:1197:9)
at Buffer.alloc (node-internal:internal_buffer:220:23)
at _Sender.resize
(file:///home/dietpi/worker-testing/node_modules/@questdb/nodejs-client/src/sender.js:269:34)
at new Sender
(file:///home/dietpi/worker-testing/node_modules/@questdb/nodejs-client/src/sender.js:218:14)
at Sender.fromConfig
(file:///home/dietpi/worker-testing/node_modules/@questdb/nodejs-client/src/sender.js:235:16)
at Array.<anonymous> (file:///home/dietpi/worker-testing/src/index.ts:10:27)
at #dispatch (file:///home/dietpi/worker-testing/node_modules/hono/dist/hono-base.js:181:37)
at Hono2.fetch (file:///home/dietpi/worker-testing/node_modules/hono/dist/hono-base.js:207:17)
at fetchDispatcher
(file:///home/dietpi/worker-testing/.wrangler/tmp/bundle-4eTtYr/middleware-loader.entry.ts:54:17)
{
code: 'ERR_INVALID_ARG_TYPE',
toString: [Function (anonymous)]
}
⎔ Starting local server...
✘ [ERROR] Error sending data TypeError [ERR_INVALID_ARG_TYPE]t" argument must be of type number. Received type string ('utf8')

at validateNumber (node-internal:internal_buffer:1552:15)
at Uint8Array.fill (node-internal:internal_buffer:1197:9)
at Buffer.alloc (node-internal:internal_buffer:220:23)
at _Sender.resize
(file:///home/dietpi/worker-testing/node_modules/@questdb/nodejs-client/src/sender.js:269:34)
at new Sender
(file:///home/dietpi/worker-testing/node_modules/@questdb/nodejs-client/src/sender.js:218:14)
at Sender.fromConfig
(file:///home/dietpi/worker-testing/node_modules/@questdb/nodejs-client/src/sender.js:235:16)
at Array.<anonymous> (file:///home/dietpi/worker-testing/src/index.ts:10:27)
at #dispatch (file:///home/dietpi/worker-testing/node_modules/hono/dist/hono-base.js:181:37)
at Hono2.fetch (file:///home/dietpi/worker-testing/node_modules/hono/dist/hono-base.js:207:17)
at fetchDispatcher
(file:///home/dietpi/worker-testing/.wrangler/tmp/bundle-4eTtYr/middleware-loader.entry.ts:54:17)
{
code: 'ERR_INVALID_ARG_TYPE',
toString: [Function (anonymous)]
}
1 Reply
apolodoro
apolodoroOP2d ago
I have contacted the questdb team which came back with this From the error stacktrace it seems like somehow node.js is messed up, like Uint8Array.fill() would have a different prototype, or could be from the a different version of node?Node source code:
/**
* Creates a new filled Buffer instance.
* alloc(size[, fill[, encoding]])
*/
Buffer.alloc = function alloc(size, fill, encoding) {
validateNumber(size, 'size', 0, kMaxLength);
if (fill !== undefined && fill !== 0 && size > 0) {
const buf = createUnsafeBuffer(size);
return _fill(buf, fill, 0, buf.length, encoding);
}
return new FastBuffer(size);
};
/**
* Creates a new filled Buffer instance.
* alloc(size[, fill[, encoding]])
*/
Buffer.alloc = function alloc(size, fill, encoding) {
validateNumber(size, 'size', 0, kMaxLength);
if (fill !== undefined && fill !== 0 && size > 0) {
const buf = createUnsafeBuffer(size);
return _fill(buf, fill, 0, buf.length, encoding);
}
return new FastBuffer(size);
};
In our case the fill parameter is 0, so ending up creating a new FastBuffer, which extends Uint8Array.
class FastBuffer extends Uint8Array {
// Using an explicit constructor here is necessary to avoid relying on
// `Array.prototype[Symbol.iterator]`, which can be mutated by users.
// eslint-disable-next-line no-useless-constructor
constructor(bufferOrLength, byteOffset, length) {
super(bufferOrLength, byteOffset, length);
}
}
class FastBuffer extends Uint8Array {
// Using an explicit constructor here is necessary to avoid relying on
// `Array.prototype[Symbol.iterator]`, which can be mutated by users.
// eslint-disable-next-line no-useless-constructor
constructor(bufferOrLength, byteOffset, length) {
super(bufferOrLength, byteOffset, length);
}
}
…and after this I am kind of lost. According to the stacktrace Uint8Array.fill(...) is called with the wrong parameters. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray/fillstart is the second parameter. How the utf8 string gets there ??? It could also be that typescript compiles into some weird js code, so maybe it is a tsc bug? But no one ever reported any issues with using the client from typescript. 1:27 I wonder if Cloudfare could help to investigate the issue? Maybe it is really something to do with how they run the code, maybe the node libraries get mixed up somehow, or they bind a new prototype for the fill() function?

Did you find this page helpful?