test: add unit tests for TypeScript ChainAgent and BedrockFlowsAgent

[nuthalapativarun]

Issue Link (REQUIRED)

Fixes #539

Summary

Changes

Adds unit test coverage for two previously untested TypeScript agents:

ChainAgent.test.ts (12 tests)

• Constructor: empty-agents guard throws, single-agent init, custom defaultOutput
• processRequest: single-agent pass-through, multi-agent pipeline (output of agent N becomes input to agent N+1), additionalParams forwarded to every agent, default response on empty content, last-agent streaming allowed, intermediate streaming returns default response, agent error propagates

BedrockFlowsAgent.test.ts (8 tests)

• Constructor: no-region default client, region-specific client, pre-built client bypass, enableTrace default/set
• processRequest: happy-path flow invocation + decode, missing response stream error, custom flowInputEncoder, custom flowOutputDecoder, client-level error wrapping

Both files follow the same mock/describe/it structure as the existing LambdaAgent.test.ts.

User experience

Before: npx jest produced no output for ChainAgent or BedrockFlowsAgent.

After: 20 new assertions covering the core behaviour and error paths of both agents.

Checklist

• I have performed a self-review of this change
• Changes have been tested
• Changes are documented
• I have linked this PR to an existing issue (required)

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[cornelcroi]

Hey @nuthalapativarun, nice work — ChainAgent and BedrockFlowsAgent had zero test coverage before this, so this is a real gap being filled. Follows the existing patterns well too.

One thing that needs to be fixed before merging:

Required:

In the ChainAgent error propagation test you're using rejects.toMatch(...) instead of rejects.toThrow(...). Every other async error assertion in the codebase uses toThrow. Using toMatch on an Error object only passes by accident due to string coercion — if the thrown type ever changes this test could silently misfire. Quick fix, just swap it out.

Smaller things (non-blocking):

• The pre-built client constructor test verifies that BedrockAgentRuntimeClient is not called, but doesn't assert that addUserAgentMiddleware was called with the injected client — easy thing to add if you want more coverage there.
• CI hasn't run on the branch yet, need to see it pass before merging.

Otherwise this looks good to go!

[hiSandog]

This test PR fills a useful gap, but the reviewer note about required behavior should probably become part of the assertions. For ChainAgent, tests around intermediate streaming returning the default response and last-agent streaming being allowed will be especially valuable because those semantics are easy to break during refactors.

[nuthalapativarun]

Thanks for the catch, @cornelcroi! Updated the ChainAgent error test to use .rejects.toThrow(...) instead of .rejects.toMatch(...).

One wrinkle: switching the matcher alone couldn't actually pass, because ChainAgent.processRequest's catch block threw a raw template-literal string rather than an Error object, and Jest's toThrow can't detect non-Error rejections. So I also fixed chainAgent.ts to throw new Error(...) with the extracted message, matching the pattern already used in BedrockFlowsAgent. Full local test suite (117 tests) and tsc --noEmit both pass.

Pushed as f3f67be. Ready for re-review.

[nuthalapativarun]

Rebased this branch onto current upstream/main (was several commits behind and had a conflict in chainAgent.ts) — it's mergeable again now. The conflict was in the catch block that f3f67be touched (the rejects.toThrow/real-Error-object fix from the previous review round); I kept the instanceof Error version from this branch since it's a strict improvement over what landed on main, and verified the fix survived intact after the rebase.

Force-pushed the rebased branch. Ran the TS suite scoped to ChainAgent.test.ts and BedrockFlowsAgent.test.ts (20/20 passing) and tsc --noEmit (clean aside from a pre-existing, unrelated @dakera-ai/dakera module-resolution error that's also present on main).

Since prior comments noted CI had never triggered on this branch, this push should let it run. @cornelcroi could you kick off a CI run and take another look when you have a chance?