-
Notifications
You must be signed in to change notification settings - Fork 16
feat!: Add support for filtering with hierarchal and auto-generated keys. #199
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
Changes from all commits
1b8bc4e
bbff8bc
f0a3b64
25c13ef
a6aa0f7
2732e7f
cc5ec13
7d254f0
3463375
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,58 @@ | ||
import {DecoderOptions} from "../../typings/decoders"; | ||
import { | ||
ParsedKey, | ||
REPLACEMENT_CHARACTER, | ||
} from "../../typings/formatters"; | ||
import { | ||
EXISTING_REPLACEMENT_CHARACTER_WARNING, | ||
parseKey, | ||
replaceDoubleBacklash, | ||
UNEXPECTED_AUTOGENERATED_SYMBOL_ERROR_MESSAGE, | ||
} from "../formatters/YscopeFormatter/utils"; | ||
|
||
|
||
/** | ||
* Preprocesses filter key by removing escaped backlash to facilitate simpler parsing, then parses | ||
* the key. | ||
* | ||
* @param filterKey | ||
* @return The parsed key. | ||
*/ | ||
const preprocessThenParseFilterKey = (filterKey: string): ParsedKey => { | ||
if (filterKey.includes(REPLACEMENT_CHARACTER)) { | ||
console.warn(EXISTING_REPLACEMENT_CHARACTER_WARNING); | ||
} | ||
|
||
return parseKey(replaceDoubleBacklash(filterKey)); | ||
}; | ||
|
||
/** | ||
* Parses the log level key and timestamp key from the decoder options. | ||
* | ||
* @param decoderOptions | ||
* @param supportsAutoGeneratedKeys | ||
* @return An object containing the parsed log level key and timestamp key. | ||
* @throws {Error} If the keys contain reserved symbols. | ||
*/ | ||
const parseFilterKeys = (decoderOptions: DecoderOptions, supportsAutoGeneratedKeys: boolean): { | ||
logLevelKey: ParsedKey; | ||
timestampKey: ParsedKey; | ||
} => { | ||
const parsedLogLevelKey = preprocessThenParseFilterKey(decoderOptions.logLevelKey); | ||
const parsedTimestampKey = preprocessThenParseFilterKey(decoderOptions.timestampKey); | ||
|
||
if (false === supportsAutoGeneratedKeys && | ||
(parsedLogLevelKey.isAutoGenerated || parsedTimestampKey.isAutoGenerated)) { | ||
throw new Error(UNEXPECTED_AUTOGENERATED_SYMBOL_ERROR_MESSAGE); | ||
} | ||
|
||
return { | ||
logLevelKey: parsedLogLevelKey, | ||
timestampKey: parsedTimestampKey, | ||
}; | ||
}; | ||
|
||
export { | ||
parseFilterKeys, | ||
preprocessThenParseFilterKey, | ||
}; |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -60,12 +60,12 @@ interface YscopeFieldFormatterMap { | |
|
||
|
||
/** | ||
* Parsed field name from YScope format string. | ||
* Parsed key from YScope format string or filter keys. | ||
* | ||
* @property isAutoGenerated whether the key is prefixed with `AUTO_GENERATED_KEY_PREFIX`. | ||
* @property parts The key split into its hierarchical components. | ||
*/ | ||
type ParsedFieldName = { | ||
type ParsedKey = { | ||
isAutoGenerated: boolean; | ||
parts: string[]; | ||
}; | ||
|
@@ -74,7 +74,7 @@ type ParsedFieldName = { | |
* Parsed field placeholder from a YScope format string. | ||
*/ | ||
type YscopeFieldPlaceholder = { | ||
parsedFieldName: ParsedFieldName; | ||
parsedFieldName: ParsedKey; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. just curious, how do we differentiate between a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We discussed offline: The concept of "field names" are usually referenced in the context of field formatters / formatter strings. The docs also references this part of the specifier as |
||
fieldFormatter: Nullable<YscopeFieldFormatter>; | ||
|
||
// Location of field placeholder in format string including braces. | ||
|
@@ -124,7 +124,7 @@ const PERIOD_REGEX = Object.freeze(/(?<!\\)\./); | |
export type { | ||
Formatter, | ||
FormatterOptionsType, | ||
ParsedFieldName, | ||
ParsedKey, | ||
YscopeFieldFormatter, | ||
YscopeFieldFormatterMap, | ||
YscopeFieldPlaceholder, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(no need to address this right now - we can revisit in a future PR. we can file an issue if you also agree
With my recent experiences, i believe the Unicode Replacement character is used for replacing sequences that can't be decoded as UTF-8 characters, which means it may have a higher chance of occurrence than any other Unicode characters, depending on how users generate IRv2 logs.
In that case, we may want use a different character for replacement.
anyways, let's make sure this behaviour is covered when we put up the docs
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see your point. tbh i only chose Unicode Replacement character because i thought the name was fitting. Note however, the error will only trigger on the keys not the values, which are probably human generated, so less likely to encounter replacement character.
Also, i think we want to get rid of this eventually with antler parser. With all that being said, if you want to change it to something else, we just need to change the character in the code in one place and replace the function docstrings in a few places.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fair. a rare example of how this would happen is that people can write
SHIFT-JIS
Japanese in the keys and the logging framework / text editor decides to encode the log events as only UTF-8 in the logs. Then to select the key in the log viewer as a level / timestamp key, they would put the key partially (or fully) containing the unicode replacement character. again, i agree this is a multi-point failure, should be really rare, and for the existing use cases we're serving, likely we won't encounter such issues.yeah, hopefully we won't really see odd use cases before we migrate there