Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

uint64 data points will be written as "XXXu" even if `enableUint64Support` is false #9961

Open
tekkamanendless opened this issue Jun 11, 2018 · 6 comments

Comments

@tekkamanendless
Copy link

commented Jun 11, 2018

I spent the past 4 hours troubleshooting issues involving "invalid number", and it turns out that InfluxDB (by default) can't process uint64 values (those that have a "u" suffix). However, the models/points.go writer will write an uint64 value that way instead of returning an error or quietly coercing it to an int64 value.

My guess is that writing uint64 values should be controlled by the same enableUint64Support as reading uint64 values.

So, by default, InfluxDB will write uint64 values as "XXXu" but it will fail to read them.

@jsternberg

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2018

Can you give me a specific reproducer?

@tekkamanendless

This comment has been minimized.

Copy link
Author

commented Jun 19, 2018

I'll see what I can do for you this week. The short version of the story is that I was using sirupsen/logrus to log (and send those logs to InfluxDB, using the stock container https://hub.docker.com/_/influxdb/). If I logged a uint64 value, the code logging the value (using client/v2) would encode it as 1234u, but the InfluxDB server would complain about an invalid number (or something similar; I forget the error). I was able to determine that any value of the form ^[0-9]+u$ would cause InfluxDB to spit out this error, and digging around in the code led me to this asymmetry (where a uint64 will always be encoded with u even though the InfluxDB container can't read it).

@tekkamanendless

This comment has been minimized.

Copy link
Author

commented Jun 19, 2018

Here's a simple reproducer for you:

This will run the same point-encoding code twice, once with no uint support, and once with uint support. In both cases, the uint64 value is encoded as 42u, but in the default case (where EnableUint64Support is not called), ParsePointsString cannot read the output of PrecisionString.

package main

import (
	"fmt"
	"time"

	influxmodels "github.com/influxdata/influxdb/models"
)

func main() {
	for _, support := range []bool{false, true} {
		if support {
			influxmodels.EnableUintSupport()
			fmt.Printf("Uint support: enabled\n")
		} else {
			fmt.Printf("Uint support: disabled\n")
		}

		tags := map[string]string{
			"some-key": "some-value",
		}
		fields := map[string]interface{}{
			"my-uint": uint64(42),
		}
		point, err := influxmodels.NewPoint("mypoint", influxmodels.NewTags(tags), fields, time.Now())
		if err != nil {
			fmt.Printf("Could not create a new point.\n")
			panic(err)
		}
		encodedPoint := point.PrecisionString("ns")
		if err != nil {
			fmt.Printf("Could not encode the point.\n")
			panic(err)
		}
		fmt.Printf("Encoded point: %s\n", encodedPoint)

		decodedPoints, err := influxmodels.ParsePointsString(encodedPoint)
		if err != nil {
			fmt.Printf("Could not decode the point.\n")
		} else {
			fmt.Printf("Decoded point: %v\n", decodedPoints[0])
		}
	}
}

Output:

Uint support: disabled
Encoded point: mypoint,some-key=some-value my-uint=42u 1529416074379020226
Could not decode the point.
Uint support: enabled
Encoded point: mypoint,some-key=some-value my-uint=42u 1529416074379044481
Decoded point: mypoint,some-key=some-value my-uint=42u 1529416074379044481

What I would expect to see is my-uint=42i from the first case.

@jsternberg

This comment has been minimized.

Copy link
Contributor

commented Jun 21, 2018

Ah, so the client has no idea if the feature is enabled or not so it's up to the user to make that decision. The casting needs to be explicitly done by the user.

I can see how that might be confusing though. I expect we'll need to update the documentation to make it clear that uint64 values will be encoded as unsigned and that unsigned needs to be explicitly enabled on the server. We do not have any releases out with uint64 as it's strictly a "if you find it and if you need it" basis at the moment for now until the other products in the TICK stack support the data type properly.

@dgnorton dgnorton added the 1.x label Jan 7, 2019

@halink0803

This comment has been minimized.

Copy link

commented Jun 13, 2019

I have got the same problem. When I tried to store value with uint64 type, influx return with error: invalid number. I hope there will be a simple solution for this problem.

@stale

This comment has been minimized.

Copy link

commented Sep 11, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Sep 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.