starred/healthchecks

Fork 0

mirror of https://github.com/healthchecks/healthchecks.git synced 2026-04-25 06:55:53 +03:00

[GH-ISSUE #939] Truncate beginning of long request bodies instead of the end #661

New issue

Open

opened 2026-02-25 23:43:11 +03:00 by kerem · 5 comments

kerem commented

2026-02-25 23:43:11 +03:00

Owner

Originally created by @StevenMassaro on GitHub (Jan 8, 2024).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/939

I've started making use of the feature to send log data to healthchecks. I like that I get a truncated copy of the logs in my notification provider.

Under most circumstances I can imagine, an error in the script would show up at the end, and typically this error is truncated away.

I'm proposing a change to the truncating logic here, something like this:

    if body and maxlen and len(body) > maxlen:
        body = body[-maxlen:] + "\n[truncated]"

but I wanted to get feedback first before spending time on this change.

This would ensure that the end of the log message is included in the notification, and the beginning of the log message is omitted.

Originally created by @StevenMassaro on GitHub (Jan 8, 2024). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/939 I've started making use of the [feature to send log data to healthchecks](https://healthchecks.io/docs/attaching_logs/). I like that I get a truncated copy of the logs in my notification provider. Under most circumstances I can imagine, an error in the script would show up at the end, and typically this error is truncated away. I'm proposing a change to the truncating logic [here](https://github.com/healthchecks/healthchecks/blob/master/hc/api/transports.py#L70), something like this: ``` if body and maxlen and len(body) > maxlen: body = body[-maxlen:] + "\n[truncated]" ``` but I wanted to get feedback first before spending time on this change. This would ensure that the end of the log message is included in the notification, and the beginning of the log message is omitted.

kerem commented

2026-02-25 23:43:12 +03:00

Author

Owner

@cuu508 commented on GitHub (Jan 8, 2024):

Hi @StevenMassaro, thanks for the suggestion.

We truncate the request bodies for two main reasons:

to prevent storage from ballooning
to make the handling of each individual ping request quick and efficient

For (1) it would not matter if we keep the head or the tail part of the request body.
For (2) it does matter: suppose the client sends 1GB request body, we process it all and keep the last 100kB. This would be a waste of time, bandwidth and processing power, and would complicate the code (loading the entire request body in memory would be a bad idea, so body = body[-maxlen:] would not work). This is an extreme example but even sending 10MB and keeping last 100kB would not be great.

I suggest doing one of the following:

make your log output less verbose so it fits in 100kB
do the truncation on the client side. runitor, for example, does this out of the box: it truncates the log output on the client side, and sends the tail not the the head part to the server.

@cuu508 commented on GitHub (Jan 8, 2024): Hi @StevenMassaro, thanks for the suggestion. We truncate the request bodies for two main reasons: 1. to prevent storage from ballooning 2. to make the handling of each individual ping request quick and efficient For (1) it would not matter if we keep the head or the tail part of the request body. For (2) it does matter: suppose the client sends 1GB request body, we process it all and keep the last 100kB. This would be a waste of time, bandwidth and processing power, and would complicate the code (loading the entire request body in memory would be a bad idea, so `body = body[-maxlen:]` would not work). This is an extreme example but even sending 10MB and keeping last 100kB would not be great. I suggest doing one of the following: - make your log output less verbose so it fits in 100kB - do the truncation on the client side. [runitor](https://github.com/bdd/runitor), for example, does this out of the box: it truncates the log output on the client side, and sends the *tail* not the the head part to the server.

kerem commented

2026-02-25 23:43:12 +03:00

Author

Owner

@StevenMassaro commented on GitHub (Jan 8, 2024):

Hi @cuu508

I think I must be missing something with regards to your #2.

As the code currently reads to me, it looks like the body is loaded into memory on line 67, then truncated later. Thus, it shouldn't matter whether we retain the head or tail of the body, since it is already loaded into memory.

Let me also clarify my goal here. I am already doing truncation on the client side, as described in the documentation. My problem is that the request body is further truncated when a message is sent via telegram (see code here), and it is omitting the error message, because it is retaining the head, not the tail of the message:

@StevenMassaro commented on GitHub (Jan 8, 2024): Hi @cuu508 I think I must be missing something with regards to your #2. As the code currently reads to me, it looks like the body is loaded into memory on line 67, then truncated later. Thus, it shouldn't matter whether we retain the head or tail of the body, since it is already loaded into memory. Let me also clarify my goal here. I am already doing truncation on the client side, as described in the documentation. My problem is that the request body is further truncated when a message is sent via telegram ([see code here](https://github.com/healthchecks/healthchecks/blob/master/hc/api/transports.py#L455)), and it is omitting the error message, because it is retaining the head, not the tail of the message: ![image](https://github.com/healthchecks/healthchecks/assets/25826807/933fdaf8-f9aa-41be-931f-8c840b212ec7)

kerem commented

2026-02-25 23:43:12 +03:00

Author

Owner

@cuu508 commented on GitHub (Jan 8, 2024):

Ah, sorry, I did not read carefully and misunderstood – I was thinking about truncation when ingesting a ping request, but you were talking about truncation when preparing a notification. I'll look into this again.

@cuu508 commented on GitHub (Jan 8, 2024): Ah, sorry, I did not read carefully and misunderstood – I was thinking about truncation when ingesting a ping request, but you were talking about truncation when preparing a notification. I'll look into this again.

kerem commented

2026-02-25 23:43:12 +03:00

Author

Owner

@StevenMassaro commented on GitHub (Jan 18, 2024):

@cuu508 Wondering if you've had a chance to ponder this request

@StevenMassaro commented on GitHub (Jan 18, 2024): @cuu508 Wondering if you've had a chance to ponder this request

kerem commented

2026-02-25 23:43:12 +03:00

Author

Owner

@moraj-turing commented on GitHub (Apr 11, 2024):

Hey @StevenMassaro I have since created a PR including settings for this behavior

@moraj-turing commented on GitHub (Apr 11, 2024): Hey @StevenMassaro I have since created a PR including settings for this behavior