fix: support shrunk client payloads on v1

[yeelali14]

✨ PR Description

Purpose: Add payload resolution module to handle compressed and oversized client payloads on v1 action, replacing complex inline JSON parsing.

Main changes:

• New resolve-payload-fields.js module handles plain JSON, base64(gzip), and server-stashed payload references with decompression bomb protection
• Action workflow now uses dedicated step to resolve payload into individual outputs (github_token, url, cm_repository, etc.) consumed by subsequent steps
• Simplified action.yml by replacing nested fromJSON() expressions with resolved step outputs, improving maintainability and supporting shrunk payloads

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Description using Guidelines Learn how}

[orca-security-us]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Secrets	0   0   0   0	View in Orca

[linearb]

✨ PR Review

The PR is well-structured and thoughtfully addresses the payload normalization problem for v1. Security design in stashUrl (pinning to resolver origin) is particularly solid. Two issues worth flagging: an orphaned JSDoc comment that misattributes documentation, and a missing guard on resolverToken before it's used as a secret and in an Authorization header.

2 issues detected:

🐞 Bug - `reference.resolverToken` is used as a credential without being validated for presence, risking an unmasked or malformed Authorization header on a malformed reference payload.

Details: fetchStashedPayload passes reference.resolverToken directly to core.setSecret and uses it in the Authorization header without first checking that it is a non-empty string. If the incoming reference object is missing the field (malformed trigger payload), core.setSecret(undefined) may silently no-op, the header becomes "Bearer undefined", and the secret is never masked in logs.

File: resolve-payload-fields.js (108-110)

🧾 Readability - Two consecutive JSDoc blocks appear above `normalizeForEngine`; the first belongs to `toStepOutputs` and is misplaced, making it appear to document the wrong function.

Details: Lines 158–162 contain a JSDoc comment that describes toStepOutputs ("Maps a resolved payload to the step outputs…"), but it is immediately followed by a second JSDoc block for normalizeForEngine. The toStepOutputs function itself appears later (line 189), leaving its intended documentation stranded and the first comment misleadingly attached to normalizeForEngine.

File: resolve-payload-fields.js (158-162)

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Review using Guidelines Learn how}

[Copilot]

Pull request overview

Adds a payload-resolution layer to the v1 composite action so downstream steps can reliably consume key fields when client_payload is provided as plain JSON, gzip-compressed base64, or as a server-stashed reference.

Changes:

• Introduces resolve-payload-fields.js to parse/decode/validate the three supported payload shapes and emit step outputs.
• Wires the resolver into action.yml, replacing repeated fromJSON(fromJSON(...)) expressions with steps.payload-fields.outputs.*.
• Normalizes the payload shape passed to the rules engine while keeping YAML-facing fields small and consistent.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
resolve-payload-fields.js	New payload resolver with gzip inflation limits, stash URL validation, and step-output mapping
action.yml	Adds resolver step and refactors subsequent steps to use resolved outputs

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[MishaKav]

LGTM

[linearb]

✨ PR Review

The PR cleanly refactors payload resolution into a dedicated JS module and fixes the brittle double-fromJSON expressions in action.yml. The decompression-bomb guard, origin-pinning on the stash URL, and explicit secret-masking for the github token are all good additions. Two previously raised concerns (unguarded resolverToken and misplaced JSDoc) remain open. One new issue is noted below.

1 issues detected:

🐞 Bug - The cm repo checkout step omits the resolved `github_token` output, causing it to use `GITHUB_TOKEN` instead of the installation token when the payload provides one.

Details: The "Checkout base branch" step was updated to use steps.payload-fields.outputs.github_token || github.token, but the "Checkout cm repo" step directly below was not given the same token. If the cm repository is private and requires the installation token carried in the payload (the same reason the base-branch checkout was updated), the checkout will silently fall back to the default GITHUB_TOKEN, which likely lacks cross-repo access.

File: action.yml (113-119)

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Review using Guidelines Learn how}

[linearb]

✨ PR Review

The PR introduces a flexible payload resolution layer that handles plain, compressed, and server-stashed payloads. The SSRF mitigation in stashUrl is well-documented and structurally sound. The two previously identified issues (issue_1: unchecked resolverToken and issue_3: missing token on the cm-repo checkout) remain unresolved; issue_2 (stranded JSDoc) is now fixed by the new file layout.

2 issues detected:

🐞 Bug - `reference.resolverToken` is used without a truthy check, so a missing field results in an unmasked secret and a misleading Bearer header value.

Details: fetchStashedPayload passes reference.resolverToken directly to core.setSecret and into the Authorization header without first verifying it is a non-empty string. If the incoming reference is malformed and the field is absent, core.setSecret(undefined) silently no-ops, the token is never masked in logs, and the header becomes "Bearer undefined", which will also cause the fetch to fail with an unhelpful 401/403 rather than a clear validation error.

File: resolve-payload-fields.js (108-110)

🐞 Bug - The cm-repo checkout omits the `token` field while the base-branch checkout was explicitly patched to supply the payload's installation token for the same reason.

Details: The "Checkout cm repo" step does not specify a token, so it falls back to the default GITHUB_TOKEN. The preceding "Checkout base branch" step was explicitly updated to use steps.payload-fields.outputs.github_token || github.token precisely because the installation token in the payload may be required for cross-repo access. If the cm repository is private and requires that installation token, this checkout will silently fail or use insufficient credentials.

File: action.yml (113-119)

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Review using Guidelines Learn how}