fix: Update LLMMetadataExtractor to not modify documents in place

[sjrl]

Related Issues

• an idea to address Document Embedders modify Documents in place #9505

Proposed Changes:

Update LLMMetadataExtractor to not modify Document objects in place.

I've opted to use the replace function from dataclasses to do this since it does create a new dataclass object and doesn't modify the old one in place.

How did you test it?

Notes for the reviewer

Checklist

• I have read the contributors guidelines and the code of conduct
• I have updated the related issue with new insights and changes
• I added unit tests and updated the docstrings
• I've used one of the conventional commit types for my PR title: fix:, feat:, build:, chore:, ci:, docs:, style:, refactor:, perf:, test: and added ! in case the PR includes breaking changes.
• I documented my code
• I ran pre-commit hooks and fixed any issue

[coveralls]

Pull Request Test Coverage Report for Build 15925816077

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 10 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.01%) to 90.291%

---

Files with Coverage Reduction	New Missed Lines	%
components/extractors/llm_metadata_extractor.py	10	83.78%

Totals
Change from base Build 15875178481:	0.01%
Covered Lines:	11709
Relevant Lines:	12968

---

💛 - Coveralls

[julian-risch]

I'd like to better understand the issue and where distinguishing the parent documents and the new documents is a problem right now. As an alternative we could consider creating a new id only if the content changes, which is not the case here.

[sjrl]

@julian-risch I don't think there is much utility in merging this PR anymore, but perhaps serve as a proposal for #9505

So if there are no objections, I'll go ahead and close this PR and update the issue with this proposal

[sjrl]

Closing following up on this comment #9553 (comment)