Funky behavior with big (error?) timestamps

[ryantxu]

Directions

I spent a while trying to figure out why data was not visible in the index -- eventually I figured out that I was sending invalid timestamps, but it would be nice to have errors if you send invalid data!

Bug report

System info:
Amazon Linux:
build: "e094138084855d444195b252314dfee9eae34cab" "0.12.1"
"go1.4.3"

Steps to reproduce:

1. Index with invalid timestamp
   m1 a=1.2 9223372036854775807
2. Show Fields... gives you nothing!
   SHOW FIELD KEYS
3. Index a valid value
   m2 a=1.2
4. Show Fields... now shows values for both m1 and m2
   SHOW FIELD KEYS
5. Select data from m1 & m2
   SELECT * FROM m1
SELECT * FROM m2
   nothing form m1, 1 result for m2

Expected behavior:

If I send request and get a 2XX response, i assume it is indexed. If I send a bad request i want a 4XX or 5XX response

Actual behavior:

see above

[e-dard]

@ryantxu I just wanted clarify a couple of things here.

Firstly, yes you have uncovered a bug, in fact I think there may be two bugs here!

The timestamp value 9223372036854775807 is actually valid (in fact it's the largest timestamp value InfluxDB accepts).

I'm going to figure out why the point is not being stored.

[jsternberg]

I pushed another fix related to this issue at #6693.

The shard groups when you had a shard group near the time boundary wasn't being created correctly and would result in the data point being inaccessible on a restart. Unfortunately, there's no way to fix the shard after it's been created natively. If you write any points into a shard at the time boundary, I think you're going to have to drop that shard and insert the data again.