insert with specified time silently fails if time is in the future

[m-mcgowan]

My app is intended to use UTC time, but I had a failing test case that wasn't inserting any
test data.

[...snip... hours of debugging and playing with http://hurl.it to try to figure out why no rows were inserted]

Long story short: if the specified time is in the future, the insert silently fails, but returns HTTP response 200.

In my case, the time used in the test was created in my time-zone which is UTC+1, and so in the future compared to UTC time.

Possible resolutions of this bug could be either an explicit failure message, or support for future times. For example, for simulation/planning work, storing a computed/predicted time series would be useful.

[toddboom]

@m-mcgowan Apologies for the massive amounts of time you spent tracking down the source of the issue. I'll write a test against this today and get it patched quickly if necessary.

Can you tell me what version of InfluxDB you're currently running? (influxdb -v)

[m-mcgowan]

I'm running against the sandbox. No worries about the time spent debugging, I realize this is beta quality software. I shouldn't really have grumbled, just was up all night unable to sleep!

[toddboom]

Well, we'd like you to be able to be more productive the next time you're grappling with insomnia, so thanks for letting us know! The sandbox should be running the latest release, so I'll double check it and try to get a fix out later today.

[m-mcgowan]

Your welcome. Just thinking aloud, another solution to add to the 2 I mentioned above could be to make future times an option, probably disabled by default. When disabled the insert call with a future time returns an error. When enabled, the call succeeds. (Although maybe there is a danger here if the client and server clocks are not synchronized and the client is ahead of the server.)

In my app, there should not be any future times. This was caused by my own bug in test code that was using a non-UTC time.

[toddboom]

@m-mcgowan So, I think your points are actually getting written in, but your queries aren't returning them because the select query has a default end time of now(). Based on what I saw in our testing, you should see the expected output if you write in your future-dated points and modify the query like this:

select * from foo where time < now() + 5h;

Can you give that a try and let me know if it works?

[m-mcgowan]

Hi,

Thanks for the tip - I hadn't realized the default start time - changing that does fix the problem.

It didn't work straight away - I'd made some other changes, including changing the select column list from '*' to an explicit column list. In my app, I have a list of columns that are inserted in to the JSON - time, beerTemp etc... I used the same list to build the select query, so the column list included 'time' - if time is included as a select column the result returns no datapoints. I realize 'time' is a special column, but this looks like another silent error.

[jvshahid]

I believe that this isn't an issue anymore. I opened another #200 issue to track the issue with the time column.

[litchfield]

Just ran into this too 😦

[beckettsean]

@litchfield on 0.8 or 0.9? If 0.9, what exact version?

This issue references an 0.8 problem, and I know from experience that submitting points in the future works just fine in 0.9.0-0.9.3.

[julienvienne]

Hello,
In my experience, the problem still there in the 0.12 release.
I'm simply unable to write points in the future.

Date in future :
$ date -d '@1460738281'
vendredi 15 avril 2016, 18:38:01 (UTC+0200)

$ curl -X POST 'http://server01:8086/write?db=test_database' --data-binary 'measurement_test value=68.67 1460738281000000000'
-> Result : No measurement saved in test_database

Any workaround would be appreciated

Best regards,

[julienvienne]

Oops, adding time < now() + 5dcriteria in select did the job.
Sorry for the noise.

[beckettsean]

For future reference: http://docs.influxdata.com/influxdb/v0.12/troubleshooting/frequently_encountered_issues/#querying-after-now

[geordie-dostal-qxbranch]

This page has the incorrect values for max and min long:
Smallest valid timestamp: -9023372036854775808 (approximately 1684-01-22T14:50:02Z)
Largest valid timestamp: 9023372036854775807 (approximately 2255-12-09T23:13:56Z)

Should be 92... not 90...

[beckettsean]

@geordie-dostal-qxbranch can you open an issue on the Docs repo, please?