fix(langchain): prefer metadata ls_provider in SummarizationMiddleware token check

[Michael Chin (michaelnchin)]

Fixes langchain-ai/langchain-aws#946

Part 2 of the proposed fix noted in langchain-ai/langchain-aws#946 (comment). The first PR in langchain-aws adds response_metadata["ls_provider"] = "amazon_bedrock" to messages generated by ChatBedrock and ChatBedrockConverse.

This follow-up PR will update SummarizationMiddleware's _should_summarize_based_on_reported_tokens method to prefer response_metadata["ls_provider"] over model_provider when checking if a message came from the current provider.

This is specifically unblocks optimal use with Bedrock chat models, where Converse API and Invoke API requests require unique model_provider values (bedrock/bedrock_converse), but share the same tracing ls_provider (amazon_bedrock) for token pricing. For messages from other providers that don't set ls_provider in metadata, model_provider will still be used as the fallback.

[ccurme (ccurme)]

are both these keys in message metadata? I only see model_provider. Do we actually need to update ls_params or message.response_metadata["model_provider"] to make them consistent?

[Michael Chin (michaelnchin)]

It's not in a langchain-aws release yet, but ChatBedrock and ChatBedrockConverse will both start adding response_metadata["ls_provider"] = "amazon_bedrock" to outgoing messages with this PR: langchain-ai/langchain-aws#981

model_provider and ls_params can't be directly updated in the Bedrock chat models, as they have distinct values that other mechanisms are dependent on (context here: langchain-ai/langchain-aws#946 (comment)), so this extra metadata field is a workaround to positively identify the base ls_provider directly from messages.