Fix nested field access in message template formatting

[ayaangazali]

Fixes #174. getField in packages/logfire-api/src/formatter.ts resolved every dotted path segment against the top-level attribute record, so {user.name} fell back to the raw template and {a.b} could silently render an unrelated top-level b. Nested paths now walk into the attribute value, and a literal dotted key like http.method still wins over traversal so flat OTel-style attribute names keep their behavior.

Both follow-ups from the issue are in: field lookups use Object.hasOwn at the top level and during traversal, so prototype members like {user.toString} no longer resolve (regression tests included), and the changeset now mentions the bracket-syntax change ({a[0]} used to render the string undefined, now it warns and falls back to the raw template).

New formatter.test.ts covers nested resolution, precedence, debug = syntax, missing-field fallbacks, and the prototype cases; changeset is a patch for logfire. Ran pnpm run check from the root, all green on Node 24.

quick note: built with Claude Code's help, and I went through the final diff myself. freshman in college doing my best here, so if anything looks off I'd honestly love to know why :)

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: a719c73f-1d05-4816-8b92-57420c8dc5cf

📥 Commits

Reviewing files that changed from the base of the PR and between 4b82908 and 4ba94d4.

📒 Files selected for processing (1)

• packages/logfire-api/src/formatter.test.ts

🔗 Linked repositories identified

CodeRabbit considers these linked repositories for cross-repo context during reviews:

• pydantic/logfire (manual)
• pydantic/pydantic-ai (manual)

🚧 Files skipped from review as they are similar to previous changes (1)

• packages/logfire-api/src/formatter.test.ts

---

📝 Walkthrough

Walkthrough

Message template formatting now resolves dotted fields by traversing nested attribute values, while literal dotted keys retain precedence. Field access uses own-property checks to exclude prototype members. Unsupported or unresolved paths fall back to the raw template with warnings. Tests cover nested and deep fields, precedence, debug formatting, missing values, bracket syntax, and prototype-member protection. A patch changeset documents the updated behavior.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: fixing nested field access in message template formatting.
Description check	✅ Passed	The description is directly related to the code changes and issue scope.
Linked Issues check	✅ Passed	The changes implement the linked issue's nested-path fix, preserve literal key precedence, and add the requested regressions.
Out of Scope Changes check	✅ Passed	The patch stays focused on formatter behavior, tests, and the changeset without unrelated additions.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

[coderabbitai]

Actionable comments posted: 1

🤖 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.

Inline comments:
In `@packages/logfire-api/src/formatter.ts`:
- Around line 59-64: Reject unsupported bracket syntax in the formatter before
literal-key lookup: update the field-resolution logic around Object.hasOwn in
packages/logfire-api/src/formatter.ts lines 59-64 to throw KnownFormattingError
whenever fieldName contains [ or ]. Add a regression test in
packages/logfire-api/src/formatter.test.ts line 10 using a record with an own
"a[0]" key, asserting the raw template is returned and the warning matches
exactly.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 0fff08e8-db78-410d-ad3f-1e9ac7f29f23

📥 Commits

Reviewing files that changed from the base of the PR and between 333e8b9 and d05322a.

📒 Files selected for processing (3)

• .changeset/nested-template-fields.md
• packages/logfire-api/src/formatter.test.ts
• packages/logfire-api/src/formatter.ts

🔗 Linked repositories identified

CodeRabbit considers these linked repositories for cross-repo context during reviews:

• pydantic/logfire (manual)
• pydantic/pydantic-ai (manual)

[petyosi]

Please add paired regressions for the bracket behavior documented in the changeset: {a[0]} with no matching literal key should warn and return the raw template, while {a[0]} with an own 'a[0]' key should render that value. The latter preserves existing main behavior and literal-key precedence, so we should test it rather than reject bracket characters before lookup.

[ayaangazali]

added both in 4ba94d4: {a[0]} with { a: ['zero'] } warns and returns the raw template, and {a[0]} with an own 'a[0]' key renders the value. tests green (vp run logfire#test, 446 passing).

[ayaangazali]

ready for another look: paired bracket regressions landed in 4ba94d4 (no-literal-key falls back with a warning, own 'a[0]' key still renders), and the coderabbit thread is resolved after the changeset clarification in 4b82908.

[ayaangazali]

since you're doing a review pass (thanks for the #172 approval!): this one is fully addressed too. the paired bracket regressions you asked for landed in 4ba94d4, coderabbit approved after the changeset clarification, and there are no open threads left. ready whenever you are. same honest workflow as the rest: built with Claude Code's help, final diff read by me.