I was using InfluxDB to store big int numbers as strings, and data is written into the database perfectly. However, the query result from the data inspector (the first image) is different from Grafana showing one (the second image).
Grafana lost part of the string in the end. I want to know if anyone experienced this issue, and how to fix it. Thank you very much.
this is known and there looks like two large ongoing discussions rn:
opened 03:15AM - 25 Jun 21 UTC
type/bug
area/transformations
<!--
Please use this template to create your bug report. By providing as much i… nfo as possible you help us understand the issue, reproduce it and resolve it for you quicker. Therefor take a couple of extra minutes to make sure you have provided all info needed.
PROTIP: record your screen and attach it as a gif to showcase the issue.
- Questions should be posted to: https://community.grafana.com
- Use query inspector to troubleshoot issues: https://bit.ly/2XNF6YS
- How to record and attach gif: https://bit.ly/2Mi8T6K
-->
**What happened**: When using a reduce transform on a time series with series names made of decimal representation of unsigned 64bit numbers (e.g. the string '2882377905688543293'), the resulting field column will truncate the precision of the represented number(2882377905688543000). I am assuming something is needlessly parsing to a numeric representation that is insufficient for the uint64.
**What you expected to happen**: The series name string should be duplicated verbatim in the reduced output.
**How to reproduce it (as minimally and precisely as possible)**:
- Create an influx query on a measurement with one of the tags holding 64bit unsigned integers. Group by time and tag.
- Alias the series name by tag name "$tag_My64BitTag"
- Add a reduce transformation that calculates stats on each series.
- The series name will be transformed in the reduced output. e.g. '2882377905688543293' becomes 2882377905688543000
- Adding some non numeric characters to the series alias, "$tag_My64BitTag foo" cures the loss of precision, but isn't acceptable for my use case. Presumably that is causing the attempt to parse to fail.
**Environment**:
- Grafana version: 7.4.3
opened 09:15AM - 11 Nov 21 UTC
closed 09:49AM - 12 Nov 21 UTC
type/bug
area/frontend
<!--
Please use this template to create your bug report. By providing as much i… nfo as possible you help us understand the issue, reproduce it and resolve it for you quicker. Therefore take a couple of extra minutes to make sure you have provided all info needed.
PROTIP: record your screen and attach it as a gif to showcase the issue.
- Questions should be posted to: https://community.grafana.com
- Use query inspector to troubleshoot issues: https://bit.ly/2XNF6YS
- How to record and attach gif: https://bit.ly/2Mi8T6K
-->
**What happened**:
Use csv content source, the number string will display as number, but it`s type is string.
In this function, should we add aditional condition to check value type?
https://github.com/grafana/grafana/blob/881dd9992cef1d197e6d5c32d4da4b6bb0ce33c5/packages/grafana-data/src/field/displayProcessor.ts#L103
**What you expected to happen**:
display as full string content 3701925924894146889
**How to reproduce it (as minimally and precisely as possible)**:
use gdev-testdata datasource, and input below content:
```csv
str
aa
3701925924894146889
```
**Environment**:
- Grafana version: play.grafana.com latest version
- User OS & Browser: macos chrome
Thanks for your reply, it solved my problem!
1 Like
