Description
lib/svg/staleWatermark.ts exports two functions:
export function injectStaleWatermark(svg: string): string { ... }
export function hasStaleWatermark(svg: string): boolean { ... }
A repo-wide search confirms neither function is imported or called
anywhere else in the codebase:
$ grep -rn "staleWatermark|StaleWatermark" --include=".ts" --include=".tsx" .
./lib/svg/staleWatermark.ts:1:export function injectStaleWatermark(svg: string): string {
./lib/svg/staleWatermark.ts:15:export function hasStaleWatermark(svg: string): boolean {
This is a fully-written, self-contained feature (inject a small "? cached"
badge overlay into the bottom-right corner of any generated SVG) that was
never wired into app/api/streak/route.ts. Given the function's purpose
("Cached data" aria-label, ? cached text) and the fact that the route
already sets stale-while-revalidate in its Cache-Control headers, this
looks like it was meant to visually mark a badge as served from a stale
cache — e.g. when the GitHub API call fails and a cached/fallback response
is served instead — but that integration point was never built. The file
also has zero test coverage (no staleWatermark.test.ts exists anywhere).
Steps to Reproduce
- grep -rn "injectStaleWatermark" the entire repo — the only match is
the function's own definition.
- Trigger any condition where the GitHub API is unreachable (e.g. mock a
failed fetch) and observe the served SVG — no "? cached" watermark ever
appears, regardless of whether the response came from a fresh fetch or
a stale/fallback cache entry.
Expected Behavior
Either:
(a) the watermark should be wired into the actual stale-serving code path
in app/api/streak/route.ts, so users can visually tell when they're
looking at cached data during a GitHub API outage, or
(b) if the feature was abandoned intentionally, the dead code should be
removed rather than left as an unreachable, untested module.
Screenshots / Logs
Wire it up rather than delete it — the feature is well-formed and useful.
Specifically:
- Have the code path that serves a stale/cached SVG on GitHub API failure
(in app/api/streak/route.ts) track whether the response is a fresh
fetch or a fallback/stale cache hit.
- When serving a stale/fallback response, call injectStaleWatermark(svg)
before returning it.
- Add test coverage for both functions directly (currently zero), plus
an integration test asserting the watermark appears in the route's
response only on the stale-serve path, not on a normal fresh fetch.
GitHub Username (If applicable)
No response
Environment
Chrome
Description
lib/svg/staleWatermark.ts exports two functions:
export function injectStaleWatermark(svg: string): string { ... }
export function hasStaleWatermark(svg: string): boolean { ... }
A repo-wide search confirms neither function is imported or called
anywhere else in the codebase:
$ grep -rn "staleWatermark|StaleWatermark" --include=".ts" --include=".tsx" .
./lib/svg/staleWatermark.ts:1:export function injectStaleWatermark(svg: string): string {
./lib/svg/staleWatermark.ts:15:export function hasStaleWatermark(svg: string): boolean {
This is a fully-written, self-contained feature (inject a small "? cached"
badge overlay into the bottom-right corner of any generated SVG) that was
never wired into app/api/streak/route.ts. Given the function's purpose
("Cached data" aria-label,
? cachedtext) and the fact that the routealready sets
stale-while-revalidatein its Cache-Control headers, thislooks like it was meant to visually mark a badge as served from a stale
cache — e.g. when the GitHub API call fails and a cached/fallback response
is served instead — but that integration point was never built. The file
also has zero test coverage (no staleWatermark.test.ts exists anywhere).
Steps to Reproduce
the function's own definition.
failed fetch) and observe the served SVG — no "? cached" watermark ever
appears, regardless of whether the response came from a fresh fetch or
a stale/fallback cache entry.
Expected Behavior
Either:
(a) the watermark should be wired into the actual stale-serving code path
in app/api/streak/route.ts, so users can visually tell when they're
looking at cached data during a GitHub API outage, or
(b) if the feature was abandoned intentionally, the dead code should be
removed rather than left as an unreachable, untested module.
Screenshots / Logs
Wire it up rather than delete it — the feature is well-formed and useful.
Specifically:
(in app/api/streak/route.ts) track whether the response is a fresh
fetch or a fallback/stale cache hit.
before returning it.
an integration test asserting the watermark appears in the route's
response only on the stale-serve path, not on a normal fresh fetch.
GitHub Username (If applicable)
No response
Environment
Chrome