fix: drop redundant decodeURIComponent and repair urlencoded schema validation

[lzeligman-mark43]

Summary

Fixes two bugs in lambda/parse-request-body.ts that together break every valid application/x-www-form-urlencoded GitHub webhook. Both bugs were introduced by the recent 094cda1 (feat(repo): switch to bun) refactor that introduced URLSearchParams.

Bug 1 — schema is parsed against the wrong shape

const params = new URLSearchParams(body);
const payloadParam = params.get("payload");        // string | null
const { payload } = bodySchema.parse(payloadParam); // bodySchema is z.object({ payload: z.string() })

URLSearchParams.get returns the value of the payload= field as a string | null. bodySchema is declared as z.object({ payload: z.string() }), so zod throws Invalid input: expected object, received string and parseRequestBody returns undefined. The handler then 403s every valid urlencoded GitHub webhook.

The existing fixture-based test (fixtures/invalid-payload-urlencoded.txt) hides this because the fixture is deliberately invalid and the test only checks that invalid payloads are rejected — it does not exercise a valid urlencoded payload's success path.

Bug 2 — redundant decodeURIComponent throws on literal %

return JSON.parse(decodeURIComponent(payload));

URLSearchParams.get already URL-decodes the value once (%7B → {, etc.). Calling decodeURIComponent a second time on the already-decoded JSON string throws URIError: URI malformed whenever the JSON contains a bare % that doesn't begin a valid %XX escape — extremely common in real user content:

Pattern	Example
Percentage in PR title / commit message	30% threshold rollout, 100% complete
Trailing %	rate: 5%
Windows env-var reference	set %USERPROFILE% to ~, %PATH%
SQL LIKE wildcard	WHERE name LIKE '%foo%'
C / Go format verbs	printf("%s\n", val), log.Printf("%v", obj)
Bare % followed by non-hex	look here: %g and %h

GitHub sends webhook bodies single-URL-encoded per the form-urlencoded spec; the second decode was never needed for correct decoding of real traffic.

Fix

       case CONTENT_TYPES.URL_ENCODED:
         const params = new URLSearchParams(body);
-        const payloadParam = params.get("payload");
-        const { payload } = bodySchema.parse(payloadParam);
-        return JSON.parse(decodeURIComponent(payload));
+        const { payload } = bodySchema.parse({
+          payload: params.get("payload"),
+        });
+        return JSON.parse(payload);

1. Wraps params.get("payload") into the { payload: string } shape bodySchema expects, so validation actually runs.
2. Drops the redundant decodeURIComponent so literal % characters in user content no longer crash the parse.

Tests

Adds 9 new test cases in lambda/proxy.test.ts:

• One end-to-end test through the handler driving a urlencoded webhook whose JSON contains literal % characters (multiple patterns combined).
• A new describe("parseRequestBody — urlencoded payloads with literal '%' characters", …) block exercising parseRequestBody directly for each of the user-content patterns listed in the table above, plus:
  • A control with no special characters to confirm normal payloads still parse.
  • A %20 preservation test confirming that literal %20 in a JSON string value is preserved verbatim (not re-decoded to a space), which is the correct semantic now that the outer URLSearchParams.get is the sole decode pass.

Local run: 22 pass, 0 fail (12 existing + 10 new).

Backwards-compatibility analysis

The only scenario where removing the second decode would change behavior is a hypothetical client that double-URL-encodes the body. GitHub never does this. Even if it happened, the lambda only inspects enterprise.slug and sender.login for the routing/auth decision (both are GitHub identifier strings that cannot contain %), and the raw original body is forwarded byte-for-byte to the destination via axios.post(url, body, …) — so the routing decision and forwarded payload are unchanged in that edge case.

Notes

• No deps changed.
• bun run format-check clean.
• bun test passes 22/22.

[danadajian]

Thanks for the fix @lzeligman-mark43!

[eg-oss-ci]

🎉 This PR is included in version 2.4.2 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀