-
Notifications
You must be signed in to change notification settings - Fork 58
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
Vector stops with panic at to_unix_timestamp format:nanoseconds VRL function #978
Comments
We have some workarounds:
But we still want to use nanoseconds precision. |
This was done on purpose, reference this: chronotope/chrono#1123
The timestamp has elapsed since The next Y2K bug will strike in 2262. 🤣 |
But it may be worth throwing errors rather than panic in vector. @jszwedko WDYT? |
Agreed, I think we should catch this and return an error from I'll transfer this issue to the VRL repo. |
Good catch, thanks! I will prepare a fix. I will also do a grep for usages of |
A note for the community
Problem
Vector panics at timestamp conversation to_unix_timestamp and crashes. Log messages:
We found out that it was a very small date in some of the logs. This one message has crashed all our 3 aggregators. How: we have Kafka between agents and aggregators, one message crashed first vector and was not consumed, then other two after rebalancing tried to consume this message and also crashed. All 3 aggregators were continuously restarting every 10 seconds, until our fix in VRL.
Configuration
Version
0.33.1
Debug Output
No response
Example Data
Input:
"ts": "1677-09-21 00:12:43.145224192Z" - OK. VRL Playground
"ts": "1677-09-21 00:12:43.145224191Z" - Fail. thread 'vector-worker' panicked at 'value can not be represented in a timestamp with nanosecond precision.' VRL Playground
"ts": "0000-09-21 00:12:43.145224192Z" - Fail. thread 'vector-worker' panicked at 'value can not be represented in a timestamp with nanosecond precision.' VRL Playground
Reproduced in VRL Playground
Additional Context
No response
References
vrl/src/stdlib/to_unix_timestamp.rs
Line 4 in 1688993
Tasks
The text was updated successfully, but these errors were encountered: