fix: avoid duplicate Content-Type header in fetch402

[rolznz]

Summary

When a body is passed to fetch402, it is sent as JSON so we default the Content-Type header. The agent isn't required to set the header itself but might do so anyway (potentially in different casing), which previously produced two Content-Type headers via object spread.

This only adds our default Content-Type: application/json when one isn't already present (matched case-insensitively).

Fixes #47

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes
  • Improved request handling for non-GET/HEAD calls so JSON requests now set a default Content-Type: application/json only when one isn’t already provided.
  • Preserved any existing request headers and avoided duplicate Content-Type entries.

[coderabbitai]

📝 Walkthrough

Walkthrough

The fetch402 function's header-construction logic was modified so that a default Content-Type: application/json header is only added when no Content-Type header is already present in params.headers, checked case-insensitively, preventing duplicate header values.

Changes

Header deduplication fix

Layer / File(s)	Summary
Conditional Content-Type header assignment src/tools/lightning/fetch.ts	Clones params.headers, checks case-insensitively whether a Content-Type header already exists, and only adds the default application/json value when absent, replacing the prior unconditional overwrite/merge.

Estimated code review effort: 1 (Trivial) | ~3 minutes

Related issues: Fixes duplicate Content-Type header being sent when both a JSON body (-b) and an explicit -H content-type header are passed to fetch.

Suggested reviewers: rolznz

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly matches the main change: preventing duplicate Content-Type headers in fetch402.
Linked Issues check	✅ Passed	The code addresses #47 by avoiding a second Content-Type when a user header already exists, including case-insensitive matches.
Out of Scope Changes check	✅ Passed	The patch is narrowly scoped to fetch402 header handling and adds no unrelated changes.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/duplicate-content-type-header

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (1)

src/tools/lightning/fetch.ts (1)

25-32: 🎯 Functional Correctness | 🔵 Trivial | 💤 Low value

Consider generalizing header deduplication, if broader fetch402Lib/undici header merging is a concern.

This fix only guards against a duplicate Content-Type. The linked issue notes the fix "should ideally be handled as a general header deduplication improvement" for other headers too. Since fetch402Lib's handling of requestOptions.headers downstream isn't shown here, if it merges headers again (e.g., with its own defaults for other header names), the same duplicate-value issue could reappear for headers other than Content-Type. Given the issue explicitly scoped this as a possible follow-up rather than a blocking requirement, this is optional.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/tools/lightning/fetch.ts` around lines 25 - 32, The current fix in
fetch.ts only de-dupes Content-Type before assigning requestOptions.headers, but
the review notes this may need to be generalized if fetch402Lib or undici merges
other headers downstream. Update the header handling around
params.headers/requestOptions.headers so duplicate values are prevented for all
header names, not just Content-Type, while keeping the existing behavior intact
in the fetch path.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@src/tools/lightning/fetch.ts`:
- Around line 25-32: The current fix in fetch.ts only de-dupes Content-Type
before assigning requestOptions.headers, but the review notes this may need to
be generalized if fetch402Lib or undici merges other headers downstream. Update
the header handling around params.headers/requestOptions.headers so duplicate
values are prevented for all header names, not just Content-Type, while keeping
the existing behavior intact in the fetch path.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 67235fd1-e318-465e-be35-07efdcd3aadb

📥 Commits

Reviewing files that changed from the base of the PR and between 4dee856 and 37909ad.

📒 Files selected for processing (1)

• src/tools/lightning/fetch.ts