Measurement name sent as ASCII after a while

[Peekayy]

Specifications

• Client Version: 1.33.2
• InfluxDB Version: 2.7.10
• Platform: Archlinux

Code sample to reproduce problem

This is pseudo-script, I didn't actually run it but it reflects my implementation.

const api = influx.getWriteApi(orgId, "ecogeo", 'ms');

async function ingest(){
    const points = [new Point("°C").timestamp(Date.now()).floatValue("tag", 0.5)];
    api.writePoints(points);
    await api.flush();
}

setInterval(ingest, 60_000);

Expected behavior

HTTP payload format should be stable even after days.

Actual behavior

It seems that the ° character is sent as utf8 0xc2b0 but after some time it is sent as ASCII 0xb0.

Additional info

Hi, I made a small nodeJs app that fetches data from my heat pump and stores it in influxdDb. I then use Grafana to have nice graphs. Basically the app gathers data every minute based on a setInterval call. It works perfectly for a day or two and then suddenly data doesn't show up anymore in Grafana. No obvious reason for it. And a simple restart of the app gets it back on rails, until next failure. After a lot of investigation on influxdb, heavy logging on nodejs. I found out that the setInterval was actually running and that influxDb was getting data. So I went on the wireshark road. And here are the results : Extract of relevant part of normal behaviour http payload :

0000   c2 b0 43 2c 6f 72 69 67 69 6e 3d 74 6f 6f 6c 73   ..C,origin=tools
0010   73 65 72 76 65 72 5f 65 63 6f 66 6f 72 65 73 74   server_ecoforest
0020   20 62 6f 72 65 68 6f 6c 65 5f 69 6e 5f 74 65 6d    borehole_in_tem
0030   70 3d 31 32 2e 33 20 31 37 32 37 39 39 31 37 38   p=12.3 172799178
0040   31 31 30 37 0a 

Extract of relevant part of faulty behaviour http payload :

0000   b0 43 2c 6f 72 69 67 69 6e 3d 74 6f 6f 6c 73 73   .C,origin=toolss
0010   65 72 76 65 72 5f 65 63 6f 66 6f 72 65 73 74 20   erver_ecoforest 
0020   62 6f 72 65 68 6f 6c 65 5f 69 6e 5f 74 65 6d 70   borehole_in_temp
0030   3d 31 32 2e 34 20 31 37 32 37 39 39 31 36 31 38   =12.4 1727991618
0040   30 37 37 0a                                       077.

The main difference between the 2 situations is at offset 0 : normal behaviour sends c2b0 which is utf8 '°' while faulty behaviour sends b0 which is also '°' but in ASCII. This makes influxdb reject the values...

Any idea why ? Any idea of things I could try ?

[karel-rehor]

I've investigated this with a simple test application (see attached) writing data to OSS InfluxDB2 over localhost and then monitoring loopback traffic with wireshark. Even with the test app running for 4 hours, I've been unable to recreate this issue. In all sampled packets (see attached) the Unicode degree character is sent as utf-8 0xcb20. I've not seen any packets with extended-ascii encoding. All batches are sent with the header content-type: text/plain; charset=utf-8 and this gets set in the internal transport implementation of the client library.

Also looking at the code-base where escape.measurement() prepares the final encoding of the measurement, also tested locally with special Unicode characters, this also uses the expected utf-8 encoding.

exploreIssue1068.ts.txt

TestPacketRandom1.txt TestPacketEarly.txt TestPacketLast.txt

These tests were made on a system with Ubuntu 22.04.

Works for me.

[Peekayy]

@karel-rehor Thanks for your investigation. However I had to make sure I could reproduce it using your script or at least a very similar one. And after 19h44min it happened again. See for yourself :

The script ran from 2024-10-15 22:36 CEST until 2024-10-16 21:24 CEST and data stopped being ingested at 2024-10-16 18:20 CEST Notice the new Measurement tag that was created "�C" however it doesn't contain any data.

The ts script I used : idbTest.ts.txt

And the console output : idsTest.log

Can you have a look? thanks

[Peekayy]

@karel-rehor Good news I found the root cause !

This is a nodejs regression in 22.7.0 : https://github.com/nodejs/node/issues/54521

Sorry for the false issue but big thanks again for your investigation as it put me on the track to find the solution !