汎用Receiver Registry APIを追加 - #591
Conversation
WalkthroughReceiver Registry APIを追加しました。Receiver ID、種別、表示名、能力、状態一覧、指定配送を実装しました。 ChangesReceiver Registry
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant Receiver as MessageReceiver
participant Status as Client Status API
participant Gateway as MessageGateway
participant Control as External Control API
participant Registry as Receivers API
Receiver->>Status: Receiver statusを送信
Status->>Gateway: ClientStatusを保存
Control->>Registry: Receiver一覧を要求
Registry->>Gateway: listActiveReceivers()を実行
Gateway-->>Registry: ActiveReceiver一覧を返却
Control->>Gateway: receiverIdを指定してメッセージを配送
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/components/messageReceiver.tsx`:
- Around line 590-602: Update fetchMessages so Receiver mode uses a new
API-key-protected message retrieval endpoint, while Legacy mode continues
calling the existing unauthenticated /api/messages route. Add the Receiver-only
endpoint with API-key authentication and dequeueMessages(clientId) behavior,
then route mode === 'receiver' requests through it without changing Legacy
behavior.
In `@src/pages/api/v1/events.ts`:
- Around line 17-22: Update the clientId selection logic to trim both
req.query.receiverId and req.query.clientId, prioritize receiverId only when its
trimmed value is non-empty, and otherwise fall back to the trimmed clientId.
Preserve undefined when neither value contains usable content so the existing
downstream behavior remains correct.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 5a0bff46-b9e9-4d5b-866b-4a5f9464b4e8
📒 Files selected for processing (11)
docs/receiver-registry-api-spec.mdsrc/__tests__/features/api/receiverRegistry.test.tssrc/__tests__/pages/api/v1/externalApi.test.tssrc/components/messageReceiver.tsxsrc/features/api/http.tssrc/features/api/messageGateway.tssrc/features/api/receiverRegistry.tssrc/lib/accessPolicy/routePolicies.tssrc/pages/api/v1/client/status.tssrc/pages/api/v1/events.tssrc/pages/api/v1/receivers.ts
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/pages/api/v1/client/messages.ts (1)
7-14: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winHTTPメソッドを検証してください。
handlerはHTTPメソッドを確認していません。dequeueMessagesはキューからメッセージを削除する副作用を持つと推測されます。GET以外のメソッドでもこの副作用が発生します。
req.methodが想定するメソッド(例:GET)でない場合、405を返す処理を追加してください。💡 メソッド検証の追加案
const handler = (req: NextApiRequest, res: NextApiResponse) => { + if (req.method !== 'GET') { + return res.status(405).json({ error: 'Method Not Allowed' }) + } + const clientId = getClientIdFromRequest(req) if (!clientId) { return res.status(400).json({ error: 'Client ID is required' }) }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/pages/api/v1/client/messages.ts` around lines 7 - 14, handlerでgetClientIdFromRequestを呼ぶ前にreq.methodを検証し、想定するGET以外のメソッドには405を返して処理を終了するよう更新してください。GETの場合のみ既存のclientId検証とdequeueMessages(clientId)呼び出しを実行し、その他のレスポンス処理は維持してください。
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/pages/api/v1/client/messages.ts`:
- Around line 7-14:
handlerでgetClientIdFromRequestを呼ぶ前にreq.methodを検証し、想定するGET以外のメソッドには405を返して処理を終了するよう更新してください。GETの場合のみ既存のclientId検証とdequeueMessages(clientId)呼び出しを実行し、その他のレスポンス処理は維持してください。
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 75c52de9-30db-4060-8173-fca6bbd14c34
📒 Files selected for processing (6)
docs/receiver-registry-api-spec.mdsrc/__tests__/pages/api/v1/externalApi.test.tssrc/components/messageReceiver.tsxsrc/lib/accessPolicy/routePolicies.tssrc/pages/api/v1/client/messages.tssrc/pages/api/v1/events.ts
🚧 Files skipped from review as they are similar to previous changes (5)
- src/pages/api/v1/events.ts
- src/tests/pages/api/v1/externalApi.test.ts
- src/lib/accessPolicy/routePolicies.ts
- docs/receiver-registry-api-spec.md
- src/components/messageReceiver.tsx
Summary
receiverIdを登録し、接続中Receiverを列挙する認証付きGET /api/v1/receiversを追加しました。receiverIdを優先配送先として受け付け、従来のclientId経路も後方互換として維持しました。Verification
npm exec -- eslint(変更したTypeScript/TSXファイル)npm exec -- prettier --check(変更ファイルと仕様書)npm test -- --runInBand src/__tests__/features/api/clientTabLeadership.test.ts src/__tests__/features/api/receiverRegistry.test.ts src/__tests__/pages/api/v1/externalApi.test.ts(3 suites / 30 tests passed)npm run build(成功、/api/v1/receiversの生成を確認)src/__tests__/features/stores/images.test.tsのみ、NodeのlocalStorage未設定による14件の失敗があり、未変更のdevelop系worktreeでも単独再現することを確認済みです。Notes
Summary by CodeRabbit
新機能
receiverIdを優先したメッセージ配送に対応し、従来のclientIdも引き続き利用できます。ドキュメント
セキュリティ