Closed Yun-Kim closed 11 hours ago
CODEOWNERS
have been resolved as:
releasenotes/notes/fix-bedrock-early-stream-exit-81da39d97fb1b26e.yaml @DataDog/apm-python
ddtrace/contrib/internal/botocore/services/bedrock.py @DataDog/ml-observability
tests/contrib/botocore/test_bedrock.py @DataDog/ml-observability
Branch report: yunkim/backport-11499-216
Commit report: 7a007eb
Test service: dd-trace-py
:white_check_mark: 0 Failed, 592 Passed, 694 Skipped, 19m 37.52s Total duration (15m 14.39s time saved)
Benchmark execution time: 2024-11-22 19:21:14
Comparing candidate commit 7a007eb32f1cd351d903820943e29723e4d9997a in PR branch yunkim/backport-11499-216
with baseline commit 09a4236a17787d29f25383aab96fb7708419818e in branch 2.16
.
Found 0 performance improvements and 0 performance regressions! Performance is the same for 372 metrics, 2 unstable metrics.
Backport #11499 to 2.16.
Fixes #11295.
There was an issue with the langchain-aws library and our bedrock integration in that langchain-aws' ChatBedrock class was actually resulting in a GeneratorExit because of this code implicitly calling close(stream) under the hood in Python. this means that any post-processor code was actually never reached. Since GeneratorExits do not inherit from Exception (they actually inherit from BaseException), this was not caught in our
except Except
block, meaning spans never went through either of our post-processing (success or error) code.The solution is to move post processing code into a finally block, to ensure that spans will always be finished. Note that GeneratorExits are not indicative of actual user/system errors and will not be flagged as such (spans will not be marked with error, post processing will simply include only information available until the last yielded chunk)
Checklist
Reviewer Checklist