1.8 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| feedback_ascii_only_api_payloads | On Windows/Git-bash, non-ASCII chars (em-dash, arrow, smart quotes) in JSON payload TEXT passed to curl get mangled and rejected — Discord bot-alert returns 400, the coord API returns "error parsing the body". Use ASCII-only in API payload text, or a single-quoted heredoc. |
|
When building JSON API payloads on Windows/Git-bash and sending via curl, non-ASCII characters
in the text fields get mangled in transit and rejected by the server, even though jq -n
produces valid UTF-8 JSON. Hit twice on 2026-06-01:
post-bot-alert.sh→ Discord 400{"message":"The request body contains invalid JSON","code":50109}on a message containing—(em-dash) and→(arrow).- Coord todos API (
POST /api/coord/todos) →{"detail":"There was an error parsing the body"}on todo text containing em-dashes (both the inline$(jq -n ...)and theP=$(jq -n ...); curl --data-binary "$P"patterns failed).
Why: the round-trip through a bash variable → curl --data-binary re-encodes/mangles the
multibyte UTF-8 (Git-bash codepage quirk), so the bytes the server receives are no longer valid JSON.
Fix: keep API payload text ASCII-only — use - not —, -> not →, straight quotes not
smart quotes. The most robust transport is a single-quoted heredoc piped to curl:
curl -s -X POST "$API" -H "Content-Type: application/json" --data-binary @- <<'JSON'
{"text":"ASCII only - no em-dashes or arrows","project_key":"..."}
JSON
This bit the Syncro bot-alert (resolved by ASCII retry) and the coord-todo filings the same day. NOTE-TO-SELF tie-in: the project's NO-EMOJIS rule already pushes ASCII markers; extend that habit to all API payload text, not just console output.