Allow only certain whitelisted chars to be present in messages in order to avoid too much diversity

[flaviostutz]

In some cases the error-info message comes with variable parts in the message, like "message code" or "account code". As the message is a metrics label, each different string then creates whole new metrics, skyrocketing the number of different metrics (they are not summed), leading to memory leak on the client application, creating network bottlenecks and generating tons of data on Prometheus/Cortex or other infrastructure that will handle the metrics unnecessarily.

Some examples are "Account 546775 couldn't not be created", "There was an error processing your request. erroid=538-433.456", "There are 4 pending approvals for your profile".

Proposal

The proposal is to limit the permitted characters to a fixed whitelist through a regex expression, specially removing all numbers present in the message, thus avoiding the type of issues described as examples.

By applying the following regex cleanup code to the messages, the examples would become:

const regex = /[^A-zÀ-ú\s\.\,]+/ig;
p.replaceAll(regex, "Account 546775 couldn't not be created");

• "Account couldn't not be created"
• "There was an error processing your request. erroid=-."
• "There are pending approvals for your profile"

This way, even if the client sets the error-info attribute with numeric variables we won't have metrics diversification as it will be handled as the same metrics/message (after transformation).

What do you think?

[CarlosPanarello]

We can use this regex for default, but it can be changed with some environment. But limited by 50 chars.

[flaviostutz]

Agree. Maybe init-param "info-regex"?

[CarlosPanarello]

what about error-info-regex? info-regex maybe is too generic, info about what?
This name will be relation only with error-info http header parameter.

[flaviostutz]

That’s perfect! Even makes it more aligned to the attribute name set in request (error-info).

…

Sent from my iPhone

On 17 May 2021, at 08:01, Carlos Eduardo Panarello ***@***.***> wrote:  what about error-info-regex? info-regex maybe is too generic, info about what? This name will be relation only with error-info http header parameter. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Ziul]

I created the PR #33 that accepts up to three environment variables: filter-regex, filter-index, and filter-max-size. With it, we can solve the problem about the max size of the message, apply a regex to the message and even get which matching group of the regex the user desires. To get more aligned with your discussion I can rename the variables to error-info-regex, error-info-index and error-info-max-size.

[CarlosPanarello]

I created the PR #33 that accepts up to three environment variables: filter-regex, filter-index, and filter-max-size. With it, we can solve the problem about the max size of the message, apply a regex to the message and even get which matching group of the regex the user desires. To get more aligned with your discussion I can rename the variables to error-info-regex, error-info-index and error-info-max-size.

it would be great if you did that.