Skip to content

Release: develop -> main - #128

Open
github-actions[bot] wants to merge 1 commit into
mainfrom
develop
Open

Release: develop -> main#128
github-actions[bot] wants to merge 1 commit into
mainfrom
develop

Conversation

@github-actions

Copy link
Copy Markdown

Automatic Release PR

This PR was automatically created after changes were pushed to develop.

Commits: 1 new commit(s)

Checklist

  • Review all changes
  • Verify CI passes
  • Approve and merge when ready for production

…127)

* Collapse Telegram polling-error noise into onset and recovery lines

Without a 'polling_error' listener node-telegram-bot-api writes its own
unformatted console error for every failed poll, at error level and
outside the application logger. The polling loop also retries on a fixed
300ms interval with no backoff, so a brief Telegram gateway outage
produces several lines per second — a recent nine-second 502 window
logged 27 lines — and sustained retries earn a 429 on top of the original
502 because the loop ignores Telegram's retry-after.

Attach a listener that reports one line per distinct failure plus one on
recovery with duration and attempt count. The same outage becomes two
lines, an escalation from 502 to 429 is still surfaced, and an outage
never appears to stay open. Both lines are logged at warn so they remain
visible together under a warn-level log configuration.

No unit tests added: the repo's jest config has rootDir="src" but the
sources live at the repo root, so `yarn test` finds zero tests today.

* Keep unrecovered polling outages visible in the logs

Review follow-up on the first commit.

The signature used the raw error message compared against the previous
one only, which fails in the two cases that actually occur: "Too Many
Requests: retry after N" counts down and a connect failure carries a
rotating gateway address, so each retry looked like a new failure, and
alternating errors re-reported on every poll. Mask digits out of the
signature and track the signatures already reported within the current
outage.

A permanently failing poll — a revoked token answers 401 forever —
reported once and then stayed silent, because the recovery timer only
fires once errors stop. Repeat the report every five minutes while the
outage is open.

Also move the outage shape into telegram.types.ts next to the other
state types, and truncate the error text, which wraps the upstream
response body.

* Bound the outage signature set and stop over-claiming recovery

Second review follow-up.

The signature prefixed the error code onto a message that the library
already prefixes with that same code, so the prefix discriminated
nothing. Use the message alone.

The signature set had no upper bound: a message carrying a per-attempt
token that survives digit masking - a request id in an upstream error
body reaches the parse-error branch verbatim - produced a fresh
signature per poll, which defeated the collapsing and grew the set
without limit. Cap it, past which only the periodic report remains. A
replay of 2000 such polls now yields 22 lines and 20 retained
signatures instead of 2000 of each.

An error arriving more than the grace period after the previous one
opened and closed its own outage, so an isolated blip cost two lines
where it used to cost one. Skip the closing line for a single attempt.

The closing line said "recovered", but nothing probes the poll - the
grace period only establishes that no further error arrived, and a
request that never settles would look the same. Say what is actually
known instead.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant