Exposing more boto3 client options to ChatBedrock and doc example? about langchain-aws HOT 3 OPEN

Yes, totally makes sense, exception handling is not the best at the moment and we can improve that. I have to check if there is a separate exception thrown by the API that we can surface here.

from langchain-aws.

@P1llus
All great ideas, there is plan to abstract out the client creation to a separate module with more options. Note that users can create their own client and pass in to the Bedrock classes, which supports all options available with boto3. Defaulting to a higher timeout might make sense for Opus, but not applicable universally. If there is a config that you have worked out which can work universally, open a PR with that change, and we can review it.
Agree that we need more examples and documentation, we welcome contributions from the community, and let us know if you need any help with this.

from langchain-aws.

@3coins Ah yeah that is true about the defaults, might be a bit overkill to change it like that.

I think something in-between would be if its possible for us to detect the underlying issue with some sort of logging.
As mentioned above, the only message received from Chat bedrock is that there was a timeout.
However it was actually hitting a throttle and 504's with a backoff.
There was no indication on that from the client perspective, and only the logs from the bedrock service itself would highlight it.

I am unsure if this is how boto3 logs it as well or if its the ChatBedrock class that don't surface information like that?

from langchain-aws.