Problem
When a body assertion fails, the failure message interpolates the entire response body with no length bound. A 100 KB body produces a single 100,039-character line.
The response dump printed directly below it truncates the same body to 256 bytes — so the truncation logic exists, it just isn't applied to the assertion message.
Reproduction
Against an endpoint returning 100 KB of x:
$ http-assert --assert-body 'zzz' http://127.0.0.1:8099/large 2>&1 | awk '{print NR": "length($0)}'
1: 45
2: 19
3: 20
...
7: 100039 ← the assertion message
...
23: 256 ← the same body in the response dump, truncatedLine 7 is:
- body: expected to match "zzz", got "xxxxx…" (100,039 chars, one line)
Why it matters
A single unwrapped 100 KB line will wedge a terminal and bloat CI logs, and the useful part of the message — expected to match "zzz" — is the first 30 characters. Any endpoint returning an HTML error page hits this.
Suggested fix
Bound the Actual rendering in the failure message the same way the dump already bounds it, with an explicit marker (see the sibling issue on the dump's silent truncation).
Problem
When a body assertion fails, the failure message interpolates the entire response body with no length bound. A 100 KB body produces a single 100,039-character line.
The response dump printed directly below it truncates the same body to 256 bytes — so the truncation logic exists, it just isn't applied to the assertion message.
Reproduction
Against an endpoint returning 100 KB of
x:Line 7 is:
Why it matters
A single unwrapped 100 KB line will wedge a terminal and bloat CI logs, and the useful part of the message —
expected to match "zzz"— is the first 30 characters. Any endpoint returning an HTML error page hits this.Suggested fix
Bound the
Actualrendering in the failure message the same way the dump already bounds it, with an explicit marker (see the sibling issue on the dump's silent truncation).