at main
1 folder
17 files
fix(webhooks): send ntfy.sh URLs ntfy's native format
Our generic JSON envelope is unusable on ntfy. With a topic in the URL,
ntfy treats the whole request body as the message text, so subscribers
got a raw JSON dump instead of a notification — and once that body grows
past ~4 KB, which any alert with a few dozen matched auctions does, ntfy
converts it into a file attachment, so the notification only reads "You
received a file: attachment.json". Posting the envelope to an instance
root instead fails outright with `40009 topic invalid`, because ntfy's
own JSON publish format expects a `topic` field. Both routes were
reported by a user, and the settings copy has been advertising ntfy
support the whole time.
ntfy.sh URLs now get a plain-text body plus X-Title/X-Click/X-Tags
headers. Publishing that way needs no topic parsing, so every alias a
user might paste (`/topic`, `/topic/publish`) behaves identically, and
the body is a one-line summary that stays well clear of the attachment
threshold. Titles outside printable ASCII are RFC 2047-encoded, since
fetch rejects non-latin-1 header values and alert names are
user-supplied.
Detection is limited to the hosted service: self-hosted instances live
on arbitrary domains and can't be recognised from the URL alone, so they
keep receiving the JSON envelope. Non-ntfy endpoints are unchanged. The
settings Test button imports the same formatter the worker uses, so it
exercises the real wire format rather than a parallel one.
Verified against a local ntfy instance: title, click action, tags and
UTF-8 alert names all round-trip, with no attachment fallback.
fix(worker): fix the 26 production type errors and gate all of src in CI
worker/tsconfig.check.json gated 18 of 45 files. The 7 ungated production files
were the load-bearing ones — index, http-router, both Durable Objects,
alert-service, auction-service, analytics-query-service — so CI type-checked
everything except the code that fires alerts and imports data.
Root causes rather than symptoms:
- tsconfig targeted es2021, whose lib does not declare ErrorOptions, so every
'new Error(msg, { cause })' failed. Four errors from one config line; module
was already es2022 and workerd is well past it.
- Both DOs redeclared ctx/env on top of DurableObject's own protected members.
Parameterizing the generic (DurableObject<AuctionImportEnv>) lets the base
declare them at the right types. Six errors.
- http-router took triggerAuctionImport as () => Promise<unknown>, so the result
could not be spread and the failure could not be read. Typed against
AuctionImportResult, with isAuctionImportFailure to narrow the thrown value.
Two real bugs the checker had been catching:
- auction-service's no-valid-data path returned only 4 of the 9 declared fields,
so callers reading fetched/timestamp got undefined.
- the success path omitted timestamp entirely, despite computing it two lines
above and declaring it in the return type.
Both tests that asserted the incomplete shapes are updated — they had been
pinning the bug.
tsconfig.check.json now includes src/**/*.ts and excludes only src/__tests__,
so a new production file is gated by default instead of silently exempt. 26
files checked, up from 18. The ~236 remaining errors are all in test mocks and
stay tracked in the spec.
fix(webhooks): send ntfy.sh URLs ntfy's native format
Our generic JSON envelope is unusable on ntfy. With a topic in the URL,
ntfy treats the whole request body as the message text, so subscribers
got a raw JSON dump instead of a notification — and once that body grows
past ~4 KB, which any alert with a few dozen matched auctions does, ntfy
converts it into a file attachment, so the notification only reads "You
received a file: attachment.json". Posting the envelope to an instance
root instead fails outright with `40009 topic invalid`, because ntfy's
own JSON publish format expects a `topic` field. Both routes were
reported by a user, and the settings copy has been advertising ntfy
support the whole time.
ntfy.sh URLs now get a plain-text body plus X-Title/X-Click/X-Tags
headers. Publishing that way needs no topic parsing, so every alias a
user might paste (`/topic`, `/topic/publish`) behaves identically, and
the body is a one-line summary that stays well clear of the attachment
threshold. Titles outside printable ASCII are RFC 2047-encoded, since
fetch rejects non-latin-1 header values and alert names are
user-supplied.
Detection is limited to the hosted service: self-hosted instances live
on arbitrary domains and can't be recognised from the URL alone, so they
keep receiving the JSON envelope. Non-ntfy endpoints are unchanged. The
settings Test button imports the same formatter the worker uses, so it
exercises the real wire format rather than a parallel one.
Verified against a local ntfy instance: title, click action, tags and
UTF-8 alert names all round-trip, with no attachment fallback.
fix(webhooks): send ntfy.sh URLs ntfy's native format
Our generic JSON envelope is unusable on ntfy. With a topic in the URL,
ntfy treats the whole request body as the message text, so subscribers
got a raw JSON dump instead of a notification — and once that body grows
past ~4 KB, which any alert with a few dozen matched auctions does, ntfy
converts it into a file attachment, so the notification only reads "You
received a file: attachment.json". Posting the envelope to an instance
root instead fails outright with `40009 topic invalid`, because ntfy's
own JSON publish format expects a `topic` field. Both routes were
reported by a user, and the settings copy has been advertising ntfy
support the whole time.
ntfy.sh URLs now get a plain-text body plus X-Title/X-Click/X-Tags
headers. Publishing that way needs no topic parsing, so every alias a
user might paste (`/topic`, `/topic/publish`) behaves identically, and
the body is a one-line summary that stays well clear of the attachment
threshold. Titles outside printable ASCII are RFC 2047-encoded, since
fetch rejects non-latin-1 header values and alert names are
user-supplied.
Detection is limited to the hosted service: self-hosted instances live
on arbitrary domains and can't be recognised from the URL alone, so they
keep receiving the JSON envelope. Non-ntfy endpoints are unchanged. The
settings Test button imports the same formatter the worker uses, so it
exercises the real wire format rather than a parallel one.
Verified against a local ntfy instance: title, click action, tags and
UTF-8 alert names all round-trip, with no attachment fallback.