umputun / feed-master / 35482677342

75%

push

github

fix: guard CleanText against a limit below the reserved suffix (#179)

`CleanText` sliced `[]rune(res)[:maximum-4]` with no lower bound on `maximum`, so any limit under 4 indexed negative and panicked.

it is reachable from remote feed content. `getMessageHTML` passes `CropText(description, 1024-len(header+footer))` at `app/proc/telegram.go:196`, and `header` is built from the feed item's own title and link:

```go
header = fmt.Sprintf("<a href=%q>%s</a>\n\n", item.Link, title)
```

neither is bounded anywhere, so a long enough title drives `maximum` below 4. `CropText` only checks `len([]rune(inp)) > maximum`, which a tiny or negative limit always satisfies, and forwards straight into `CleanText`.

a feed item with a 1000 character title and a five character description panics with `slice bounds out of range [:-47]`:

```
panic: runtime error: slice bounds out of range [:-47]
	app/proc/twitter.go:63
	app/proc/telegram.go:217
	app/proc/telegram.go:196
```

there is no `recover()` anywhere under `app/`, so one verbose or hostile feed item stops the daemon rather than failing a single notification.

the fix keeps the reserved-suffix branch for limits that can hold it. Below 4 there is no room for `" ..."`, so the text is truncated plainly, and a limit of zero or less returns empty.

`TestCleanText` only ever passed `max: 10`, which is why this stood. It now covers 3, 1, 0 and a negative, and `TestTruncatedMessageLongTitle` pins the path from a long title through `getMessageHTML`.

found by a revmux round on the v2.12 branch, reported as pre-existing rather than as part of that change.

Related to #174

10 of 10 new or added lines in 1 file covered. (100.0%)

1475 of 1974 relevant lines covered (74.72%)

10.72 hits per line