You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a field uuid that shows up in our JSON logs, but may not be present for every log event. When it is not present, the logger will output a null in place of the UUID string. We get this error in our log events which are ingested by FluentBit:
Clearly this is an issue with the inferred schema not being able to handle the optional string values for this field. Should we be doing something different, or is this a bug?
The text was updated successfully, but these errors were encountered:
sfriedowitz
changed the title
Unreachable data type when parsing optional UUID field in JSON logs
Unsupported data type when parsing optional UUID field in JSON logs
Dec 19, 2024
is there a way to specify an optional field that can be Null or string? From the docs, it looks like theres no notion of an "option" type for a static schema
I've also tried changing our log formatter so that null fields are removed from the log record, and am getting new errors in the ingestion pod after purging our old log records from S3
│ thread 'main' panicked at src/utils/arrow/batch_adapter.rs:47:47: │
│ called `Result::unwrap()` on an `Err` value: InvalidArgumentError("column types must match schema types, expected Utf8 but found Null at column index 3") │
│ note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace │
│ 2024-12-20T18:15:06.000019Z ERROR parseable::handlers::http::modal::server: Error joining remote_sync_handler: JoinError::Panic(Id(58), ...)
/about
output:Description:
We have a field
uuid
that shows up in our JSON logs, but may not be present for every log event. When it is not present, the logger will output anull
in place of the UUID string. We get this error in our log events which are ingested by FluentBit:Clearly this is an issue with the inferred schema not being able to handle the optional string values for this field. Should we be doing something different, or is this a bug?
The text was updated successfully, but these errors were encountered: