fix: skip response.headers.set() in GET handler side-effect check (#206)

[PranavAgarkar07]

Summary

Fixes a false positive in nextjsNoSideEffectInGetHandler where response.headers.set() was flagged as a side effect in GET route handlers.

Setting response headers is a legitimate and expected operation in Next.js GET route handlers — it does not represent a CSRF-vulnerable write. This PR adds an isHeadersChainCall helper that excludes .headers.set() (and any .headers.*() mutation) from the DB mutation check in findSideEffect.

Closes #206

---

Note

Low Risk
Low risk: small, localized change to AST side-effect detection logic to reduce false positives, with minimal impact outside GET-handler lint diagnostics.

Overview
Prevents nextjsNoSideEffectInGetHandler (and other rules using findSideEffect) from flagging response.headers.*() calls as “DB mutations” in GET handlers.

Adds an isHeadersChainCall AST helper and uses it to exclude any call whose member chain includes .headers from the isMutatingDbCall branch in findSideEffect, fixing the response.headers.set() false positive.

^{Reviewed by Cursor Bugbot for commit cc441af. Bugbot is set up for automated code reviews on this repo. Configure here.}

[reactreview]

Note

No issues found

[vercel]

@PranavAgarkar07 is attempting to deploy a commit to the Million Team on Vercel.

A member of the Team first needs to authorize it.

[NisargIO]

Working on a related fix in #260 that takes a slightly broader angle — covers .headers chains (your isHeadersChainCall shape), locally-scoped Map/Set/Headers/URLSearchParams/FormData bindings, .searchParams, aliased headers(), cron routes, and depth-bounded handler resolution for export const GET = withAuth(handler) patterns. Thanks for the report — your repro and test cases were super useful while validating the broader fix.