Hello,

The sample looks nice!

Is there any chance of adding function like Creation, storage, and deletion of files to be used along with the internet info. in chat?

Thanks!

Readmeに記載のCodeBuildデプロイ（CloudShell利用）や、CDKデプロイをCloud9で実施すると発生。

権限ないのでPRは出せませんでしたが、 Readme_ja.md のWarningに以下文言を記載しておくと良さそうです。

また、デプロイ時にローカル環境のストレージ容量が不足するとCDKのブートストラップがエラーとなってしまう可能性があります。Cloud9等で実行される場合は、インスタンスのボリュームサイズを拡張のうえデプロイ実施されることをお勧めします。

• instant v1 is 2 times faster than v2
• instant v1 is less expensive

As a leader who is proceeding with generative AI usage in a company, I would like to discover major use cases from conversations with active users.

For example, I can detect major use case by counting keywords in prompts (such as "please summarize", "please translate", etc). In addition, I could identify heavy users by analyzing frequency. Interviewing them would be the the first step to implement an internal prompt guide or specialized application for their business. We can find sample implementations from generative-ai-use-cases-jp.

As a minimum feature, downloading all the conversation data with the following items will be sufficient (bracket item is optional).

• user id
• date
• inputted prompt
• model name
• outputted prompt
• (instruction)
• (hyper parameter)

Please update your readme to show where to change the language.

Thanks for sharing this awesome project to give us more ideas to develop AWS Bedrock!

I would like to know how to modify the frontend code to call api (invoke()) instead of streaming via web socket (invoke_model_with_response_stream()).

Please give me some guidance to use your code more properly.

Best Regards,
Webber

ユーザー自身のデータにのみアクセス可能なように行レベルセキュリティを導入する

現在は改行されるので、省略表示にする

背景

Easy Deploymentの場合、CodeBuild内でgit cloneしたものをそのままcdk deployしていると思うので、cdk.jsonを編集するすべがなくBedrockのAPI自体は必ずus-east-1を見る必要

方針

引数でデプロイ先のリージョン・bedrockのリージョンを指定可能にする

As a developer, would like to deploy bedrock-claude-chat by Super-easy Deployment. However, it does not complete until default CodeBuild timeout (5min).

It will be necessary to extend timeout setting of timeoutInMinutesOverride.

ライトテーマとダークテーマを切り替えられるようにする

Purpose

Enable FastAPI hot reload on local development

Solution

Instead of the idea of sharing portions of the code, write it as a single application, and switch the behavior through CMD (command) or handlers at runtime

よく使うプロンプトをテンプレートとして保存する機能

初回表示時に会話一覧がロードされているかわからないので、ローディング表示を追加する

conversationのGET APIでConversationIDが存在しない場合に、現状400エラーを返しているが、404エラーで返すようにする（フロントエンドで処理しやすくするため）

it leaves you with no error message, just a blank frontend url

README.md にデプロイ後のスタック削除手順がなかったため、追記いただけるとありがたいです。

背景

• 現在はバックエンドで登録してからIDが確定するため、チャットの送信 -> IDの取得の間にラグがある
• そのラグの間に次の会話を入力すると会話が正常に登録されないので、初回登録時にフロントエンド側でIDを即時確定させたい

方針

• conversation idは登録必須（今はnull許容だが、変更後は必ず指定するようにする）
• バックエンド側でDBの存在チェック

Failed to calculate embeddings because of token limit

ストリーミングで生成されるレスポンスを中断する

下記のエラーが発生することがある

[ERROR] ProtocolError: ("Connection broken: InvalidChunkLength(got length b'', 0 bytes read)", InvalidChunkLength(got length b'', 0 bytes read))
Traceback (most recent call last):
File "/var/task/index.py", line 67, in handler
for chunk in generate_chunk(stream):
File "/var/task/index.py", line 19, in generate_chunk
for event in stream:
File "/var/lang/lib/python3.11/site-packages/botocore/eventstream.py", line 602, in iter
for event in self._event_generator:
File "/var/lang/lib/python3.11/site-packages/botocore/eventstream.py", line 609, in _create_raw_event_generator
for chunk in self._raw_stream.stream():
File "/var/lang/lib/python3.11/site-packages/urllib3/response.py", line 624, in stream
for line in self.read_chunked(amt, decode_content=decode_content):
File "/var/lang/lib/python3.11/site-packages/urllib3/response.py", line 816, in read_chunked
with self._error_catcher():
File "/var/lang/lib/python3.11/contextlib.py", line 155, in exit
self.gen.throw(typ, value, traceback)
File "/var/lang/lib/python3.11/site-packages/urllib3/response.py", line 461, in _error_catcher
raise ProtocolError("Connection broken: %r" % e, e)

一連の会話を第三者に共有する

When sending a chat message the frontend hangs forever. Looking at the CloudWatch BedrockChatStack-WebSocketHandler log stream, I see the following:

Failed to invoke bedrock: An error occurred (ResourceNotFoundException) when calling the InvokeModelWithResponseStream operation: Could not resolve the foundation model from the provided model identifier.

In the log stream request I see "model":"claude-v2", however digging into the backend bedrock.py I see get_model_id() is providing the correct modelID (in theory) before calling invoke. I looked at the docs and Bedrock in the console and the model identifiers do not appear to have changed (other than the addition of Claude v2.1).

I would also note I've had all models enabled in Bedrock for some time, and the app was deployed in the same region (us-west-2).

I haven't had time to dig in any further. It would be nice to add CloudWatch logging to bedrock.py as well as improve exception handling on the front end by passing the error message.

The install otherwise went as advertised.

• Edit message and re-send
• Store the edit history

Add WAF

Thank you very much for contributing this!
But when trying to deploy with cdk deploy, whether from my PC or CloudShell, I ran into an error indicating "Cannot connect to the Docker daemon".
Is Docker really required for deployment? Or any guideline to bypass this?

When the browser default language is configured to languages other than en,ja,ko,zh, the frontend throws an error when trying to switching languages.

Reproduction

Set the browser default language to en-us (or whatever unsupported languages):

Clear local storage for the page to reset i18nextLng, then open the page, login, and try to switch language.

The error I get:

Unexpected Application Error!
props.options.filter(...)[0] is undefined

Select/selectedLabel<@http://localhost:5173/src/components/Select.tsx?t=1698727269604:25:52
mountMemo@http://localhost:5173/node_modules/.vite/deps/chunk-GYWC62UC.js?v=f26ec844:12817:27
useMemo@http://localhost:5173/node_modules/.vite/deps/chunk-GYWC62UC.js?v=f26ec844:13141:24
useMemo@http://localhost:5173/node_modules/.vite/deps/chunk-HS5T2ZWL.js?v=f26ec844:1094:29
Select@http://localhost:5173/src/components/Select.tsx?t=1698727269604:24:32
...

Possible solution

Something like this will fix the issue (check if the find result is undefined):

-    return props.value === ''
-      ? ''
-      : props.options.filter((o) => o.value === props.value)[0].label;
+    return props.options.find((o) => o.value === props.value)?.label ?? '';

初めまして。
現在Bedrockの組織適応を行なっており、このリポジトリのAppは我々の求めているものに近しく感じています。
こちらはCognitoによるユーザー管理を軸としていますが、外部のIdP連携を実装する予定はありますでしょうか。
(我々はKeycloakを使っており、完全サポートではなくとも実装の余地があると嬉しく思います。)

現時点の実装においてはAuthがcognitoに依存しており、外部IdPによる実装はfrontend, backend, cdkと改修範囲が広く見えます。
ロードマップにない場合は諦めて実装を行いますが、計画にある場合は本リポジトリの改修の流れに乗れると嬉しく思っています。

また外部IdPをサポートしないとしても、cognitoのAuthを必須としない状態へとパラメータ等で制御可能になるだけでも、サンプルプロジェクトとして使いやすくなると感じています。

Show the source of the quote, since the custom bot does not know which Knowledge it answered from.

メッセージ編集、Regenerateの際に推論結果の履歴を保存する

Hi there. I'm just wondering if the SNS as the "decoupling" mechanism is necessary and/or if there was a specific requirement or reasoning behind it.

Your flow of getting a response from a model is as follows:

1. front-end connects to a websocket - which, under the hood, invokes the publisher Lambda - but it doesn't do much due to route_key being equal to $connect
2. then, front-end sends the user prompt to the open websocket (

   bedrock-claude-chat/frontend/src/hooks/usePostMessageStreaming.ts

   Line 25 in c2eec81

   ws.send(JSON.stringify({ ...input, token }));

   ) - it also triggers the same publisher Lambda. However, this time, it actually pushes the prompt forward to the SNS because the route_key is different.
3. now, the SNS invokes the websocket Lambda, which streams the response back to the websocket (https://github.com/aws-samples/bedrock-claude-chat/blob/main/backend/app/websocket.py#L77)

However, if (instead of being SNS consumer) your websocket Lambda was just a different route on the WS API gateway (lets call it /invoke), then the flow could look as follows:

1. front-end connects to a websocket - which, under the hood, invokes the publisher Lambda - but it doesn't do much due to route_key being equal to $connect
2. front-end sends the user prompt to the open websocket as an action /invoke - it triggers the websocket Lambda

Voila, you no longer need the SNS and it still works the same way.

Am I missing something (could be totally wrong above of course)? Is the SNS here necessary? Does it provide any additional value over this alternative method that I've described which would simplify the design?

Other than that - great work. Thanks for providing this excellent blueprint!

As the rest of the project is written in Typescript, the backend should follow the same language.

Current implementation may require rds proxy or DataAPI for scalabiliy.

Getting this error on one of my chats.

[ERROR] EventStreamError: An error occurred (validationException) when calling the InvokeModelWithResponseStream operation: Input is too long for requested model.
Traceback (most recent call last):
File "/var/task/app/websocket.py", line 84, in handler
for chunk in generate_chunk(stream):
File "/var/task/app/websocket.py", line 23, in generate_chunk
for event in stream:
File "/var/lang/lib/python3.11/site-packages/botocore/eventstream.py", line 603, in iter
parsed_event = self._parse_event(event)
File "/var/lang/lib/python3.11/site-packages/botocore/eventstream.py", line 619, in _parse_event
raise EventStreamError(parsed_response, self._operation_name)

Please add darkmode support.

It'd be great if we can sort history, create a section, and expand/collapse sections on conversation history panel. Just like the Slack channel side bar.

自身のメッセージを修正して、再度推論を実行する

概要

「続きを出力」ボタンの実装をしてほしい

背景

出力に 30 秒以上かかるリクエストがユーザーから入力された場合、30秒経過後　「回答中にエラーが発生しました。」と出力が消えてしまいます。

再現手順

入力はながければなんでもいいのですが、例えば: https://qiita.com/kei31/items/82356c4130b3ab627d32　を入力します。

下記の図のように途中まで出力されます。

29秒後画面出力がクリアされ、「回答中にエラーが発生しました。」と表示されます。

根本原因は api-gw と lambda間の統合が max 29秒であることだと考えられます。
https://stackoverflow.com/questions/61617193/aws-api-gateway-websocket-timeout でも同じ議論が見えます。

期待する機能

ユーザー入力+途中まで出力された結果を記録し、再度推論させれば、続きが出力されると思うので、「続きを出力」させる機能がほしい。

{message: "Endpoint request timed out" をキャッチした場合は、以下の図のように「続きを出力」をさせるボタンを出してほしい

Happy to help translation to english and german once the i18n framework is decided.

・一度送信したメッセージを編集可能にする
・編集履歴は見返せるように