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
As of v2.1 responses include a Ping-Body-Limit header indicating how large the log payload can be. We could cache this value somewhere like /tmp/.healthchecks-<base_url_slug>.Ping-Body-Limit to be used in subsequent invocations.
Also, the existing hard-coded value doesn't support other installs with different limits, so a --body_limit flag should be added so callers can proactively specify the limit they'd like to use.
The text was updated successfully, but these errors were encountered:
Another option would be adding start ping support to task-mon and grabbing the instance's ping body limit from that response, so you don't need to maintain any local state.
Start pings are already supported via the --time flag; I'd intentionally made it an opt-in feature, but I do take your point about the benefits of turning it on by default. I'll split that out into a separate FR.
if they don't a report status grace_time after the start ping.
IIRC that was part of my motivation for not enabling --time by default. I didn't want users to need to configure the grace time properly if it didn't align with their use case.
As of v2.1 responses include a Ping-Body-Limit header indicating how large the log payload can be. We could cache this value somewhere like
/tmp/.healthchecks-<base_url_slug>.Ping-Body-Limit
to be used in subsequent invocations.Also, the existing hard-coded value doesn't support other installs with different limits, so a
--body_limit
flag should be added so callers can proactively specify the limit they'd like to use.The text was updated successfully, but these errors were encountered: