fix(instrumentation-langchain): Fix langchain end span

[DRXD1000]

• I have added tests that cover my changes.
• If adding a new instrumentation or changing an existing one, I've added screenshots from some observability platform showing the change.
• PR name follows conventional commits format: feat(instrumentation): ... or fix(instrumentation): ....
• (If applicable) I have updated the documentation accordingly.

Regarding #2790 i have experimented with this change. As far as i have seen it in my applications, this reduces the memory leak significantly, but does not fix it completely.

I would really much appreciate if someone could look at this change and check its usability.

---

Important

Fixes memory leak in TraceloopCallbackHandler by ensuring spans are deleted from self.spans after ending.

• Behavior:
  • Fixes memory leak in TraceloopCallbackHandler by deleting spans from self.spans after they are ended in _end_span().
  • Specifically deletes child_id and run_id from self.spans if they exist.
• Misc:
  • Addresses issue 🐛 Bug Report: Memory Leak When Enabled opentelemetry-instrumentation-langchain #2790 by reducing memory leak, though not completely fixing it.

^{This description was created by for 0993186. You can customize this summary. It will automatically update as commits are pushed.}

[CLAassistant]

All committers have signed the CLA.

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to 0993186 in 1 minute and 32 seconds. Click for details.

• Reviewed 18 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 1 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. packages/opentelemetry-instrumentation-langchain/opentelemetry/instrumentation/langchain/callback_handler.py:397

• Draft comment:
  Consider using self.spans.pop(run_id, None) for removing the span associated with run_id. This approach is more concise and reduces the chance of errors.
• Reason this comment was not posted:
  Marked as duplicate.

Workflow ID: wflow_RwfZg1GoT5gbkyj1

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[dinmukhamedm]

Hey @DRXD1000 thanks for opening this! I'm happy to jump into the investigation on

but does not fix it completely.

Do you have any minimal repro application and setup for tracking memory consumption?

[DRXD1000]

@dinmukhamedm sadly not. I tested with a running application using the memray package locally and grafana kubernetes Dashboards. The application i tested with is a langgraph stategraph inside a fastapi application. Maybe someone from the mentioned issue can provide a minimal example.

What i can provide right now are screenshots of the memray graphs. The only thing i changed is the openllmetry package. Both runs have gone trough 120 requests to the fastapi service.

Openllmetry main branch without modification 512MB -> 543.3 MB

Branch of this pull request 455.9MB -> 458.3MB