Why do chat history modifications not raise errors?

[MatthewSH]

Checked other resources

• I added a very descriptive title to this question.
• I searched the LangChain documentation with the integrated search.
• I used the GitHub search to find a similar question and didn't find it.

Commit to Help

• I commit to help with one of those options 👆

Description

I noticed that in multiple places, specifically in chat message histories, LangChain swallows any errors and sends them to a generic logger. For example: https://github.com/langchain-ai/langchain/blob/master/libs/community/langchain_community/chat_message_histories/dynamodb.py#L181

In a project we want to save chat history for DynamoDB and catch the error and handle it ourselves. Specifically we don't want to set a message count limit but we're handling when DynamoDB size limit is hit and we manually truncate some messages as needed. Because LangChain swallows these errors we have to override the methods and write our own implementation.

My questions are:

• Is there a reason for it swallowing errors and not raising them?
• Is there any way to opt out of this behavior? I'm not finding any
• If opting out doesn't exist, would we be open to adding a way to opt out?

EDIT: A message history runnable is out of the question (unless there's a different pattern) because we are using LangGraph and have specific nodes for handling message history and using consolidation patterns before some steps as well.

System Info

System Information

OS: Linux
OS Version: #1 SMP Wed Jul 17 10:51:09 UTC 2024
Python Version: 3.11.9 (main, Aug 13 2024, 18:51:01) [GCC 12.2.0]

Package Information

langchain_core: 0.2.34
langchain: 0.2.14
langchain_community: 0.2.12
langsmith: 0.1.98
langchain_aws: 0.1.16
langchain_text_splitters: 0.2.2
langgraph: 0.2.2

Optional packages not installed

langserve

Other Dependencies

aiohttp: 3.10.1
async-timeout: Installed. No version info available.
boto3: 1.34.156
dataclasses-json: 0.6.7
jsonpatch: 1.33
langgraph-checkpoint: 1.0.2
numpy: 1.26.4
orjson: 3.10.6
packaging: 23.2
pydantic: 2.8.2
PyYAML: 6.0.2
requests: 2.32.3
SQLAlchemy: 2.0.32
tenacity: 8.5.0
typing-extensions: 4.12.2

[dosubot[bot]]

LangChain swallows errors in chat message histories to provide a smoother user experience by handling tool invocation errors gracefully. This behavior can be managed by implementing custom error handling strategies, such as using try/except blocks, fallbacks, or retry mechanisms.

To opt out of this behavior, you can implement a try/except tool call as shown below:

from typing import Any
from langchain_core.runnables import Runnable, RunnableConfig

def try_except_tool(tool_args: dict, config: RunnableConfig) -> Runnable:
    try:
        complex_tool.invoke(tool_args, config=config)
    except Exception as e:
        return f"Calling tool with arguments:\n\n{tool_args}\n\nraised the following error:\n\n{type(e)}: {e}"

chain = llm_with_tools | (lambda msg: msg.tool_calls[0]["args"]) | try_except_tool

print(
    chain.invoke(
        "use complex tool. the args are 5, 2.1, empty dictionary. don't forget dict_arg"
    )
)

This code snippet demonstrates how to catch and handle errors explicitly, thus opting out of the default error-swallowing behavior ^[1].

Regarding the specific error handling logic around line 181 in the dynamodb.py file, it attempts to import ClientError from the botocore.exceptions module. If the import fails, it raises an ImportError with a message instructing the user to install the botocore package:

try:
    from botocore.exceptions import ClientError
except ImportError as e:
    raise ImportError(
        "Unable to import botocore, please install with `pip install botocore`."
    ) from e

This logic ensures that the necessary module is available and provides a clear error message if it is not ^[2].

If you need more granular control over error handling, LangChain offers various strategies, such as using the RunnableWithFallbacks class to define fallbacks for a Runnable that can be used if the primary Runnable fails. This class supports handling specific exceptions and passing them to fallback runnables if needed ^[3].

For more detailed control, you can also use the CallbackManager to manage error handling and tracing in a structured way ^[4].

To continue talking to Dosu, mention @dosu.