fix(aws): handle image_url object format in block type extraction

[caro-cc]

It looks like with the current version, a small bug was introduced: after the recent refactoring, the handling of image_url was changed to assume it's always a string. However, image_url can also be an object with a url property, which seems to be causing errors. I'm reintroducing the previous logic to handle both cases properly

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
langchainjs-docs	✅ Ready (Inspect)	Visit Preview		May 9, 2025 10:13pm

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
langchainjs-api-refs	⬜️ Ignored (Inspect)			May 9, 2025 10:13pm

[benjamincburns]

Thanks for flagging this!

[danny-avila]

Will there be a release for @langchain/aws to include this change? I believe this is affecting my app:

base64.match is not a function","pregelTaskId":"ade22b10-77dd-5fdb-8cc7-67eedf269664","stack":"TypeError: base64.match is not a function
at extractImageInfo (/node_modules/@langchain/aws/dist/common.cjs:139:32)
at convertLangChainContentBlockToConverseContentBlock (/node_modules/@langchain/aws/dist/common.cjs:176:16)
at /node_modules/@langchain/aws/dist/common.cjs:257:34
at Array.map (<anonymous>)
at convertHumanMessageToConverseMessage (/node_modules/@langchain/aws/dist/common.cjs:257:23)
at /node_modules/@langchain/aws/dist/common.cjs:327:20
at Array.map (<anonymous>)
at convertToConverseMessages (/node_modules/@langchain/aws/dist/common.cjs:322:10)
at ChatBedrockConverse._streamResponseChunks (/node_modules/@langchain/aws/dist/chat_models.cjs:686:96)
at _streamResponseChunks.next (<anonymous>)"

langchainjs/libs/langchain-aws/src/common.ts

Lines 227 to 230 in aeac259

	export function extractImageInfo(base64: string): ContentBlock.ImageMember {
	// Extract the format from the base64 string
	const formatMatch = base64.match(/^data:image\/(\w+);base64,/);
	let format: ImageFormat | undefined;

danny-avila/LibreChat#7354

[caro-cc]

@danny-avila in the meantime (until the next release), we are using the previous version (0.1.8), which is not affected by this issue