Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Walkthrough今回のプルリクエストでは、Misskeyの設定・デプロイ環境やCI/CDパイプライン、各種ミドルウェアの設定変更に加え、データベースマイグレーションや複数のコアサービスの機能改善が実施されました。特に、Meta管理の方法をMetaServiceからMiMetaへ移行し、Sentryの統合、Webhookおよび通知処理、AbuseReport・リアクション処理の新機能とリファクタリングが中心となっています。 Changes
Sequence Diagram(s)sequenceDiagram
participant U as ユーザー
participant ARS as AbuseReportService
participant ARNS as AbuseReportNotificationService
participant ES as EmailService
participant SWS as SystemWebhookService
participant DB as データベース
U->>ARS: 苦情報告を送信
ARS->>DB: 報告データを保存
ARS->>ARNS: 通知処理を開始
ARNS->>ES: 管理者へメール通知
ARNS->>SWS: システムWebhookで通知
ES-->>ARS: 通知完了レスポンス
SWS-->>ARS: 通知完了レスポンス
Poem
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
🎉 Snyk checks have passed. No issues have been found so far.✅ security/snyk check is complete. No issues have been found. (View Details) |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 19
🔭 Outside diff range comments (5)
packages/backend/src/core/DownloadService.ts (2)
93-97:⚠️ Potential issueダウンロード進行中のサイズチェックへの影響
ダウンロード進行中のサイズチェックも同様に、
maxSizeがundefinedの場合は機能しなくなります。これにより、設定ファイルに値が指定されていない場合、無制限のファイルサイズがダウンロードされる可能性があります。
75-78: 💡 Verification agent🧩 Analysis chain
サイズチェックロジックへの影響
この箇所では
maxSizeと比較してダウンロードを中断するロジックがあります。maxSizeがundefinedの場合、size > maxSizeの比較が常にfalseとなり、意図しない大きなファイルのダウンロードが許可される可能性があります。
🏁 Script executed:
#!/bin/bash # 設定ファイルでmaxFileSizeが定義されているか確認する echo "Checking config files for maxFileSize definition..." fd --type f -e ts -e js -e json -p ".config/" | xargs grep -l "maxFileSize" echo "Checking default config values..." fd --type f -p "packages/backend/src" | xargs grep -l "maxFileSize"Length of output: 561
ご確認：DownloadService.tsのサイズチェックロジックにおける未定義値の取り扱い
- 設定ファイル（例：
packages/backend/src/config.ts）にmaxFileSizeが定義されていることは確認できました。- しかし、現在のコードでは
maxSizeがundefinedの場合のガードがなく、設定の読み込みに失敗した場合などにsize > maxSizeの比較が常にfalseとなるリスクがあります。- このリスクを低減するため、
maxSizeが未定義の場合のエラーハンドリングやデフォルト値の設定を追加することを推奨します。packages/backend/src/core/EmailService.ts (1)
263-265:⚠️ Potential issueverifyMail メソッドが metaService を使用している
このメソッドではまだ
metaService.fetch()を使用していますが、他の部分はthis.metaに更新されています。一貫性のために更新する必要があります。このメソッドは、まだ
metaService.fetch()を使用していますが、metaServiceは注入されていないため、実行時エラーになります。以下のように修正してください：private async verifyMail(domain: string): Promise<{ valid: boolean; reason: 'used' | 'format' | 'disposable' | 'mx' | 'smtp' | null; }> { - const meta = await this.metaService.fetch(); + const meta = this.meta; if (meta.verifymailAuthKey == null) throw new Error('verifymailAuthKey is not set');packages/backend/src/core/ReactionService.ts (1)
134-162:⚠️ Potential issueカスタム絵文字リアクションのロジック強化
mediaSilencedHost判定や、すでに定義済の絵文字かをチェックしている部分が拡張されました。バリデーション漏れがないか、特に外部からの入力に対するセキュリティ対策を再度ご確認ください。+ // 例示: この辺りで不正なカスタム絵文字やホスト名を検証する仕組みを追加するなどpackages/backend/src/core/CustomEmojiService.ts (1)
112-129: 🛠️ Refactor suggestionパラメータの型仕様（Union型）の検証について
updateメソッドがidまたはnameのどちらかを必須としつつ両方を許容するUnion型になっていますが、両方未指定のケースが発生した場合、内部でdata.name!が使われており実行時エラーの可能性があります。利用箇所のバリデーションを必ず明示的に行い、呼び出しコードに誤りがあった場合は検知しやすいようにしておくことをおすすめします。
🧹 Nitpick comments (113)
compose_example.yml (1)
20-21: 環境変数設定方法の変更提案
webサービスのenv_file設定がコメントアウトされました。この変更は、環境変数の設定方法について別のアプローチを提案していると考えられます。これにより、ユーザーは環境変数をどのように提供するかについて柔軟性が増しますが、現在
dbサービスは依然として同じ.config/docker.envファイルを使用しているため、設定方法の一貫性については検討が必要かもしれません。- # env_file: - # - .config/docker.env + # 環境変数の設定方法: + # 1. env_file: + # - .config/docker.env + # 2. environment: + # - KEY: value.github/ISSUE_TEMPLATE/config.yml (1)
5-8: GitHub Discussionsへのリンク追加「仮」（一時的）というコメント付きで、GitHubディスカッションフォーラムへの新しいリンクが追加されました。これにより、ユーザーはIssueトラッカーとは別に、より会話形式の質問や議論を行う場所が提供されます。
「仮」というコメントは、この変更がまだ暫定的であることを示しています。リリース前にこのコメントを削除するか、このリンクが実際に最終的なものであるかを確認するとよいでしょう。
- # 仮 - name: 💬 Start discussionpackages/backend/migration/1729486255072-makeNotesHiddenBefore.js (1)
6-18: 新しいマイグレーションの追加ユーザーテーブルに新しい2つのカラムを追加するマイグレーションが実装されています。名前から推測すると、これらのカラムは特定の時点より前のノートの可視性設定に関連すると思われます。
makeNotesFollowersOnlyBefore: フォロワーのみに表示を制限する時点（タイムスタンプ）makeNotesHiddenBefore: ノートを非表示にする時点（タイムスタンプ）実装については問題ありませんが、いくつかの点を考慮することをお勧めします：
- カラムにNULLを許可するかどうかの指定がありません。デフォルトではNULLが許可されますが、明示的に指定することも検討してください。
- これらの新しいカラムを活用するためのUIやAPIの実装も必要になるでしょう。
- マイグレーション後、既存のレコードのデフォルト値をどのように扱うかも検討してください。
このマイグレーションに関連するUI実装やAPIエンドポイントの実装についてお手伝いが必要でしたら、お知らせください。
packages/backend/migration/1728550878802-testcaptcha.js (2)
6-16: テストキャプチャ機能の追加「enableTestcaptcha」カラムをmetaテーブルに追加するマイグレーションが作成されています。この機能の目的や使用方法についてコメントを追加すると、将来のメンテナンスがしやすくなります。
export class Testcaptcha1728550878802 { name = 'Testcaptcha1728550878802' + /** + * テストキャプチャ機能を有効/無効にするための設定をmetaテーブルに追加します。 + * この機能は開発環境でのキャプチャテストを容易にするために使用されます。 + */ async up(queryRunner) { await queryRunner.query(`ALTER TABLE "meta" ADD "enableTestcaptcha" boolean NOT NULL DEFAULT false`); } async down(queryRunner) { await queryRunner.query(`ALTER TABLE "meta" DROP COLUMN "enableTestcaptcha"`); } }
10-10: インデントの不一致このファイルでは、インデントにタブとスペースが混在しています。タブとスペースのどちらかに統一することをお勧めします。
async up(queryRunner) { - await queryRunner.query(`ALTER TABLE "meta" ADD "enableTestcaptcha" boolean NOT NULL DEFAULT false`); + await queryRunner.query(`ALTER TABLE "meta" ADD "enableTestcaptcha" boolean NOT NULL DEFAULT false`); }packages/backend/migration/1713656541000-abuse-report-notification.js (1)
1-62: 不正行為報告の通知機能のためのマイグレーションは全体的に良く実装されています。このマイグレーションでは、
system_webhookテーブルとabuse_report_notification_recipientテーブルを作成し、不正行為報告の通知機能を実装しています。インデックスや外部キー制約も適切に設定されています。いくつかの考慮点：
abuse_report_notification_recipientテーブルのuserIdフィールドに対して、2つの外部キー制約が設定されています（35-36行目）:
userテーブルのidを参照する制約user_profileテーブルのuserIdを参照する制約これは冗長である可能性があります。
user_profile.userIdは既にuser.idを参照しているはずです。両方の制約が必要かどうか確認してください。
system_webhookテーブルのsecretフィールドは平文で保存されています。セキュリティ上の懸念から、機密データの暗号化や安全な保存方法を検討することをお勧めします。
nameフィールドには一意性制約がありません。ユーザーが重複した名前を作成できるようにする意図があるなら問題ありませんが、UIで混乱を招く可能性があります。.config/docker_example.env (2)
6-6: データベース設定の変数名に注意してください。
DATABASE_PASSWORDとPOSTGRES_PASSWORDの区別を明確にするために、コメントに用途を追記すると混乱が減ります。
8-8: ユーザー名変数の扱いも同様に明示しておくとよいです。
DATABASE_USERとPOSTGRES_USERの場所を使い分ける理由や目的をコメントに記述すると保守性が高まります。packages/backend/migration/1716447138870-SuspensionStateInsteadOfIsSspended.js (1)
6-8: クラス名のスペルに注意
IsSspendedは意図的かもしれませんが、一般的にはIsSuspendedとなる場合が多いため、念のためご確認ください。packages/backend/src/core/FlashService.ts (1)
24-39:featuredメソッドの実装に改善の余地があります。メソッドは基本的な機能を果たしていますが、いくつかの改善点があります：
- 戻り値の型が明示されていません
- 結果がパックされていないため、
FlashEntityServiceのpackManyを使用することを検討してください以下のような実装に改善することをお勧めします：
- public async featured(opts?: { offset?: number, limit: number }) { + public async featured(opts?: { offset?: number, limit: number }): Promise<MiFlash[]> { const builder = this.flashRepository.createQueryBuilder('flash') .andWhere('flash.likedCount > 0') .andWhere('flash.visibility = :visibility', { visibility: 'public' }) .addOrderBy('flash.likedCount', 'DESC') .addOrderBy('flash.updatedAt', 'DESC') .addOrderBy('flash.id', 'DESC'); if (opts?.offset) { builder.skip(opts.offset); } builder.take(opts?.limit ?? 10); return await builder.getMany(); }また、
FlashEntityServiceを注入して結果をパックすることも検討してください。これにより、APIレスポンスと一貫性のある形式でデータを返すことができます。packages/backend/src/core/AnnouncementService.ts (1)
382-387: アナウンスメント自動非アクティブ化機能の追加ユーザーが自分のアナウンスメントを読んだ際に自動的に非アクティブ化する機能が追加されています。これは便利な自動化機能ですが、以下の点を確認する必要があります：
- この動作変更はドキュメントに記載されていますか？
- この自動非アクティブ化が他の機能に影響しないか確認しましたか？
この機能変更については、ユーザードキュメントに記載することをお勧めします。また、ログメッセージを追加することで、デバッグがより容易になります：
if (announcement != null && announcement.userId === user.id) { + this.globalEventService.publishMainStream(user.id, 'announcementMarkedAsRead', { + announcementId: announcementId, + }); await this.announcementsRepository.update(announcementId, { isActive: false, }); }CHANGELOG.md (2)
9-9: Bare URL の書式改善をお願いします。
ファイル内の複数箇所において、URL がそのまま記載されているため、Markdown のスタイルガイド（MD034）に反しています。たとえば、https://github.com/misskey-dev/misskey/security/advisories/ghsa-gq5q-c77c-v236という記述は、
[GitHub Advisory](https://github.com/misskey-dev/misskey/security/advisories/ghsa-gq5q-c77c-v236)のように、リンクテキストを付けた形式に修正することで可読性が向上します。その他の同様の箇所も見直してください。
Also applies to: 21-21, 28-29, 33-33, 59-59, 85-85, 97-97, 103-103, 122-124, 127-127, 136-139, 141-143, 172-174, 180-180, 212-214, 223-223, 234-237, 243-243, 286-293, 298-298, 339-339
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
9-9: Bare URL used
null(MD034, no-bare-urls)
42-42: Markdown インデントとタブの使用についての改善をお願いします。
いくつかの箇所（例: 行42、68、300～301）で、リストのインデントがプロジェクトのガイドラインと異なり、ハードタブが使用されているため、Markdown の読みやすさが損なわれています。すべての箇所でスペースによるインデント（通常、2または4スペース）に統一するようにしてください。Also applies to: 68-68, 300-301
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
42-42: Unordered list indentation
Expected: 2; Actual: 1(MD007, ul-indent)
42-42: Hard tabs
Column: 1(MD010, no-hard-tabs)
packages/backend/src/core/activitypub/ApResolverService.ts (1)
106-109: フェデレーション許可ホストチェックを追加ホストがフェデレーション許可リストに含まれているかをチェックする新しいバリデーションを追加しています。ただし、TODOコメントが残っており、さらなる改善が必要かもしれません。
「TODO なおす」コメントは具体的な情報がなく、今後の開発者にとって分かりにくいかもしれません。もう少し具体的なTODOコメントにすることをお勧めします：
-// TODO なおす +// TODO: この実装を適切なフェデレーションポリシーに基づいて見直すpackages/backend/src/core/WebhookTestService.ts (4)
25-50: ダミーデータ生成ロジックの明確化を検討してください。ダミーデータを返す関数
generateAbuseReportは単一の固定値に対してoverrideを上書きする構造ですが、引数によっては整合性が破綻する可能性があります。型レベルでのチェック（例：assigneeIdがある場合はassigneeも必要）などがあると、テスト時の誤用を防げます。
289-298: DIパラメータの型チェックを推奨します。コンストラクタで受け取るDIパラメータ（
userWebhookService,systemWebhookService,queueService）は必須依存として問題ありませんが、万一nullやundefinedが渡された場合のハンドリングがないため、型チェックや例外スローによる防御的プログラミングを検討してください。
309-392:testUserWebhookメソッドのスキップされるチェックについて説明を追加してください。このメソッドはWebhookの無効化設定やイベント種別の設定が無視される設計である点がコメントに明記されていますが、該当箇所をより強調するコメントを追加することで、テスト用途のみで使う想定を確実に伝えられます。
403-470: エラー処理を検討してください。
testSystemWebhook内でfetchSystemWebhooksの呼び出し後、キューへの追加に失敗した場合の対処が未考慮です。テスト用途のため通常不要と思われますが、デバッグの利便性向上のため、例外が発生した際のロギングを含む基本的なエラーハンドリングの導入を検討してください。locales/ko-GS.yml (8)
585-587: 表示テキストの一貫性に注意してください。
large,medium,smallに対して커게,엔갆게,쪼맪게と書かれていますが、他のUI用語との整合性を一度確認してみてください。方言表現が問題なければこのままで問題ありません。
625-625: キー重複に注意してください。
middle: "엔갆게"が他にも使われていないか、既存のキーと衝突しないかを確認し、重複定義を避けてください。
651-651: 差別化した説明を追加してください。
hiddenTags: "수ᇚ훈 해시태그"の翻訳で、何が隠されるのかをユーザが理解しやすい説明（コメント）をファイル内に追加すると安心です。
653-653: 予約語への注記を検討してください。
preservedUsernames: "예약 사용자 이럼"は衝突を防ぐための予約名のリストと推測されます。管理者向け説明コメントを入れるとトラブルが少なくなるでしょう。
659-662: キーの階層構造が不明瞭になる可能性があります。
_delivery配下にstopと_typeなどが混在しており、付随情報の管理が煩雑になるかもしれません。可読性を保つため、別セクションに分割することを検討してください。
720-728: 役割（ロール）設定の柔軟性を検討ください。
displayOrder,_priority,_options,_conditionと多層的になっています。別ファイル等で管理しないと管理負荷が高まる可能性があります。設定を分割してメンテナンス性を向上させることを検討してもよいでしょう。
814-814: 翻訳チェッカーの導入を検討してください。
reaction: "반엉"など固有の方言表記が多い場合、機械翻訳や翻訳メモリとの突合が難しくなる可能性があります。運用上の翻訳チェッカー設置で整合性を維持すると便利です。
829-831: セクション区分を明確にすると可読性が向上します。
_abuseReport,_notificationRecipient,_recipientTypeなど、今後の拡張に備えて階層化が深くなりがちなキーは、独立したセクションに分割してもよいでしょう。packages/backend/src/core/UserSearchService.ts (1)
61-96: クエリ数が増加する場合のパフォーマンスに留意してください。
searchメソッドでは複数のクエリをループしながらIDを取得しています。行数が極端に多い場合、DB負荷やパフォーマンスへの影響が気になる可能性があります。バッチ処理や結合でまとめられないか検討してみてください。packages/backend/src/core/WebAuthnService.ts (3)
45-46:DI.metaの注入が導入されました。
metaServiceとの併用が続いているようですが、このファイル内ではmetaServiceは呼び出されていないようです。もし不要であれば、metaServiceの注入も削除し、コードを整理すると可読性が向上します。
180-196: パスキー認証を開始するメソッドが新規追加されました。
期限付きチャレンジを Redis に保存するフローは既存の WebAuthn 処理と整合性があります。
ただし、getRelyingParty()は同期で戻り値を返すので、awaitは不要です。以下のように修正可能です。- const relyingParty = await this.getRelyingParty(); + const relyingParty = this.getRelyingParty();
198-259: パスキー認証を検証するメソッドが新規追加されました。
チャレンジを取得 → 検証 → カウンター更新、という流れは正しく、WebAuthn の仕様に沿っています。
getRelyingParty()が非同期でない点を踏まえ、awaitは削除可能です。また、TODOコメントが残っていますが、未実装処理がある場合は別途対応を検討ください。「TODO: 確認する」となっている箇所について、詳細がわかれば修正対応の提案や Issue 化をお手伝いできますが、いかがでしょうか？
packages/backend/src/core/DriveService.ts (6)
47-47: UtilityServiceのインポート追加
UtilityServiceの利用目的が明確であれば問題ありませんが、依存が肥大化しないよう注意してください。
178-179: オブジェクトストレージのbaseUrl生成
this.meta.objectStorageBaseUrlを優先し、未設定ならプロトコルやポートを組み立てています。想定外のポート設定や空文字列などのエッジケースを洗い出すことをおすすめします。
207-208: サムネイル用キー生成
thumbnailKeyとthumbnailUrlを同様の方法で生成しています。こちらも拡張子の有無を確実に保証する実装かご確認ください。
468-469:this.metaをinstanceに代入
NSFW検知等で繰り返し参照するためにローカル変数化しています。競合や代入漏れがないか確認としては良いですが、可読性上のメリットを考慮しつつ管理してください。
493-493: ポルノ検知のコメントアウト
this.meta.disallowUploadWhenPredictedAsPornの判定がコメントアウトされています。不要なコードなら削除を検討してください。
659-659: 連合インスタンス向けチャート更新
enableChartsForFederatedInstancesフラグでチャート集計を分岐しています。パフォーマンス上の負荷を考慮しながら必要最小限の集計範囲を設定することを推奨します。packages/backend/src/core/QueueModule.ts (1)
113-114: エクスポート項目にユーザ・システムWebHookキューを追加
外部から利用できるようにしている点は適切です。利用箇所での依存関係が増えすぎないようお気をつけください。packages/backend/src/core/ReactionService.ts (5)
30-33: isQuote, isRenote, ReactionsBufferingService, PER_NOTE_REACTION_USER_PAIR_CACHE_MAXのインポート
複数のユーティリティ・サービス・定数を読込むことで、機能が散逸しないように統合管理されている印象です。命名や配置にブレがないか再度ご確認ください。
126-129: Renoteかどうかの判定と例外スロー
isRenote(note)かつ!isQuote(note)の場合にリアクションを禁止する仕様に変更されました。意図された振る舞いならば問題ありませんが、UX的に混乱がないようドキュメント化が望ましいです。
207-219: ReactionsBufferingServiceを用いたリアクション数インクリメント
this.meta.enableReactionsBufferingフラグでDB直接更新とバッファリング更新を切り替えています。バッファ解放のタイミングやエラー時の再送など、フローの追跡が複雑化しないよう注意してください。
351-360: convertLegacyReactionメソッドの追加
旧形式のリアクションを新形式に変換しつつ、ローカルホストを'@.'に補正する方針はわかりやすいです。利用箇所が増えた際に、レガシー形式が完全に排除される時期を見極めてリファクタリングすると保守性が向上します。
361-379: convertLegacyReactions処理のリファクタ
0個のリアクションが残らないようにフィルタする工夫がされています。レガシー形式の一部が混在している際の挙動など、余分なマージ処理が起きていないか定期的に点検をお願いします。packages/backend/src/core/AbuseReportService.ts (3)
53-69: 複数のレポート挿入をまとめることでパフォーマンス最適化を検討できます。現在、
forループで個別にinsertOneを呼び出していますが、件数が多い場合バルクインサートを用いることでDBアクセスが減りパフォーマンス向上が期待できます。
70-74:Promise.allの部分的失敗を考慮するか再検討してください。複数通知を同時に行う際、いずれかが失敗した場合に全体が失敗してしまうので、個別の失敗を許容するなら
Promise.allSettledなども検討できます。
167-174: モデレーションノートの差分を詳細に記録する方法を検討してください。現在はノートの変更があった際のみログを記録していますが、追加・削除など区別した追跡が必要な場合は差分を詳細に扱う方法も検討可能です。
packages/backend/src/core/UtilityService.ts (2)
56-59:isMediaSilencedHostの一致条件の拡充可否をご検討ください。現在は完全一致で判定していますが、サブドメインを含む広範なマッチングが必要なケースがあればロジックを拡充する必要があります。
226-239: 連合（Federation）判定ロジックの将来的な拡張性を検討してください。ホワイトリスト制やドメイン別のより詳細な制限が必要になる可能性があるため、
isFederationAllowedHost/isFederationAllowedUriを拡張しやすいように設計しておくと保守性が向上します。packages/backend/src/core/QueueService.ts (3)
103-109:bakeBufferedReactionsジョブの実行頻度を再検討してみてください。深夜0時にのみ実行する設定ですが、反応をよりリアルタイムに反映させる必要がある場合は、短い間隔での繰り返しスケジュールを検討するとよいでしょう。
110-115:checkModeratorsActivityジョブの実行タイミングを見直んでみてはどうでしょう。毎時30分に限定せず、頻度を多くする・あるいはさらに間を開けるなど、運用負荷やリソース状況によって調整の余地があります。
544-573:systemWebhookDeliverの実装重複を解消し、共通ロジック化を検討してください。
userWebhookDeliverとよく似た構造のため、共通化によって保守性・可読性を高められる可能性があります。packages/backend/src/core/CoreModule.ts (2)
53-53: ReactionsBufferingService のインポート
高負荷環境などでバッファリングを行いたい意図が読み取れますが、現状の用途をドキュメント化すると保守しやすいです。
641-641: ReactionsBufferingService を exports
モジュール外部からも使うなら意図として理解できますが、過度な exports は必要性を再確認してみてください。packages/backend/src/core/UserFollowingService.ts (4)
21-21: MiMeta 型の追加インポート
MetaService を介さずに直接メタデータへアクセスできるのは効率的ですが、メンテナンス性に注意してください。
280-283: フォローリクエストが存在する場合の削除後、alreadyFollowed 判定を追加
重複フォローのエッジケースを丁寧に扱っているようです。稀な競合状況での影響をテストしたほうが安心です。
285-290: follower.host === null の場合のみ通知作成 + followedMessage を利用
ローカルユーザーに向けたメッセージ送信ロジックと思われます。メッセージが null のケースも考慮してください。
543-543: 挿入後の処理ブロック終了
小さな変更ですが、try-catch 内のロジックなど漏れがないか再度チェックをお勧めします。packages/backend/src/core/activitypub/ApInboxService.ts (3)
135-135: "TODO なおして" コメント
後で修正が必要な箇所のようです。忘れないますように issue 立てを検討してください。
600-601: TODO コメントと AbuseReport 通報フロー
//TODO あとでなおすが残っています。後日修正する意図をドキュメント化し、重複通報の考慮なども検討してください。Also applies to: 606-606
689-691: エラーを throw ではなく return する変更
上位ロジックのハンドリングに影響する可能性があります。想定通りの挙動か再チェックをお願いします。packages/backend/src/core/CustomEmojiService.ts (3)
130-141: ローカル絵文字とリモート絵文字の重複チェックについて
checkDuplicateメソッドはhost: IsNull()でローカル絵文字のみ重複を確認していますが、将来的にリモート絵文字名とも競合させたくない場合は、同ホスト以外にも重複チェック機構を拡張する必要があるかもしれません。運用方針に応じて要件を整理し、処理を統合・拡張する可能性を検討してください。
164-164: リネームイベント時のストリーム発行について
doNameUpdateがtrueの場合にemojiDeletedとemojiAddedイベントを連続発行してリネームを表現していますが、運用上わかりやすいかどうか再度確認したほうがよいかもしれません。必要に応じて新しいイベント名 (emojiRenamed) を設けるなど、イベントの意味がはっきり伝わる設計を検討してください。
186-186: 成功時の戻り値nullについて正常終了時に
nullを返す仕様はわかりやすいですが、呼び出し側で判定を行う際にnullであることが成功か失敗かを一目で把握するのが難しい可能性があります。成功時の明示的なステータスやシンボル的な値（例:'OK'）を返すなども検討してください。packages/backend/src/core/UserWebhookService.ts (4)
20-27: コンストラクタのRedis購読登録についてRedisのメッセージ購読をコンストラクタで行う場合、アプリケーション起動時のタイミングで問題が発生した際にメッセージ未購読のまま進行してしまうリスクがあります。必要に応じて、
onModuleInitを利用して購読処理を行うなど、初期化タイミングを明示化することも検討してください。
29-39:getActiveWebhooksのキャッシュ制御について一度取得した後は再取得しない方針のようですが、外部リポジトリでアクティブ状態が変更された際にデータの不整合が生じるおそれがあります。アクティブなWebhook数が頻繁に変動しないのであればこの方法でもよいですが、定期的なリフレッシュや手動でのリセットも可能にすると安全性が高まります。
44-64:fetchWebhooksメソッドのクエリビルダ使用可否についてクエリビルダでフィルタを柔軟に組み立てており、可読性も悪くありません。
ただし、同じような条件構築ロジックが他の箇所でも必要になりそうな場合、ユーティリティ関数にまとめることで再利用性と保守性を向上できます。
120-123: アプリケーションシャットダウン時のリソース解放
onApplicationShutdownでdispose()を呼び出してRedis購読を解除しています。必要であればシャットダウンフックでその他のリソース（DBコネクション等）が残っていないか確認し、確実にクリーンアップする処理を追加してもよいでしょう。locales/ko-KR.yml (3)
11-13: 初期設定用パスワード関連キーの追加について
行11～13では、初期設定用のパスワードに関する3つの新しいキー（initialPasswordForSetup、initialPasswordIsIncorrect、initialPasswordForSetupDescription）が追加されています。説明文は詳細で、ユーザーが自前でMisskeyを直接インストールする場合と、ホスティングサービスを利用する場合の違いを明確に示しています。
156-156: リノートミュート機能の文言追加について
行156でrenoteMuteが追加されています。この新規キーはリノート操作に関連するミュートの機能を示すものです。用語選択と表現がプロジェクト全体のトーンに沿っているかご確認ください。
1-2883: 全体的な文言および一貫性の確認について
このファイル全体にわたって、多数の新規キーの追加および既存文言の更新が行われています。各メッセージがユーザーインターフェース全体の翻訳ガイドラインに沿っていること、他の言語ファイルとの一貫性が保たれていること、そして技術的な説明が正確に伝わっていることを確認するようお願いします。locales/pt-PT.yml (3)
85-112: 投稿および再投稿関連の翻訳調整
noteの値が "Publicar" に変更され、またrenotedToXが "Repostar em {name}." と更新されています。これにより、投稿や再投稿に関するユーザーへの説明がより直感的になっています。ただし、文末の句点の有無については、全体の統一感を再度確認するとさらに良くなるでしょう。
158-158: スペースの不整合の指摘
createAntennaの翻訳 "Criar uma antena" において、「Criar」と「uma」の間に余分なスペースが存在しています。ここは1つのスペースに統一することを推奨します。
1-2641: 全体的な評価と細部の確認
今回の更新では、UI、エラーメッセージ、通知など多数の翻訳キーが見直され、より明瞭で利用者に優しい表現へと改善されています。プレースホルダー（例: {name}, {n}）の使用も一貫しており、全体的な統一感は非常に高いです。
なお、細かい点としては、余分なスペースや句読点の一貫性など、いくつかの微調整が見受けられるため、それらの修正を検討するとさらに完成度が上がると思われます。locales/zh-CN.yml (1)
1474-1477: サーバ設定関連の新規キーとその説明の追加について
行1474〜1477において、reactionsBufferingDescription、inquiryUrl、およびinquiryUrlDescriptionが追加・更新されています。これにより、投稿時の反応バッファリング機能や運用者向けの問い合わせ用URLの設定が導入され、サーバ負荷軽減やユーザーサポートの観点での改善が図られています。内容が意図どおりか、また他の設定との整合性を再確認してください。locales/ca-ES.yml (4)
5-1055: 初期セクションの翻訳修正と追加について
このセクションでは、例えば「poweredByMisskeyDescription」や「initialPasswordForSetup」、「initialPasswordIsIncorrect」、「initialPasswordForSetupDescription」、および「renotedBy」、「searchThisUsersNotes」、「renotedToX」、「renoteToChannel」、「renoteToOtherChannel」、「createAntenna」、「selectSelf」、「mediaSilencedInstances」、「federationAllowedHosts」「federationAllowedHostsDescription」、「s3ForcePathStyleDesc」、「noInquiryUrlWarning」、「collapseRenotesDescription」など、初期設定や基本的なUIメッセージに関連するキーの追加・修正が行われています。
文法の改善や用語の統一が図られており、全体としてユーザーへの説明がより明確になっています。各文言が他の部分と一貫しているか、また現行の機能仕様に合致しているか再確認をお願いします。
1316-1400: モデレーションと報告機能に関する文言追加について
このエリアでは、「_abuseUserReport」に関連するキーや、報告手順、承認・却下の指示などが詳細に追加されています。ユーザーおよびモデレーター向けの案内が明確になっている一方で、専門用語の使用や説明の整合性に注意が必要です。
各文言が正確な運用手順を伝えているか、また他の通知メッセージと統一されているかの確認をお願いします。
1400-2100: UI、通知、エラーメッセージなどの新規キー追加について
この範囲では、多数のユーザーインターフェイス、通知、エラー、アナウンスメントなどに関する新規キーが追加されています。全般的に翻訳は明確で、ユーザーに分かりやすい表現が使われていますが、一部の文言は長文になっているため、適宜簡潔化することで可読性の向上が期待できます。
また、各セクション間で用語の一貫性やトーンが維持されているか、細かく確認すると良いでしょう。
2101-2741: 許可、認証、その他追加機能関連の文言充実について
ファイル後半では、パーミッション設定、認証プロセス、APIアクセス、さらには複数の追加機能（例：アプリケーションアクセス、ウィジェット、テーマ、通知の詳細設定など）に関する数多くの新規キーが追加されています。
技術的な詳細が豊富な分、翻訳が正確であるか、各設定項目がユーザーにとって直感的であるか、また長大なリスト内で表現の一貫性が保たれているかの確認が重要です。
全体として非常に充実しており、ユーザー体験の向上につながる変更と考えられますが、再度各文言を見直し、必要に応じて微調整をお勧めします。packages/backend/src/core/ReactionsBufferingService.ts (3)
38-56: onMessage によるメタ更新検知Redis のメッセージ購読で
metaUpdatedを検知し、バッファリング無効化時に即bake()する実装は合理的です。エラー時のログ出力や再試行フローを検討すると、障害対応がよりしやすくなる可能性があります。🧰 Tools
🪛 Biome (1.9.4)
[error] 47-50: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
70-77:deleteメソッドのエッジケース削除時に「消した要素一覧」を記録しない場合、後続で本来消されたはずのリアクションが復活する可能性があることを
TODOで指摘しています。今後の拡張が想定されるので注意が必要です。
144-188:bakeメソッドの一括処理Redis のキーを走査し、まとめてDBへ反映するフローは妥当ですが、scan 処理が多量のキーを扱う場合にパフォーマンス問題が予想されます。
bufferedNoteIdsを別途管理する最適化案（コメントにある TODO）も検討するとよいでしょう。locales/en-US.yml (7)
11-13: 初期パスワード設定キーの追加について
「initialPasswordForSetup」、「initialPasswordIsIncorrect」、および「initialPasswordForSetupDescription」の各キーは、ユーザーが初期パスワードを設定する際の情報提供に用いられています。改行（\n）の使用や文末の句読点が他の説明文と統一されているか、最終的なユーザーインタフェースとの整合性を再確認してください。
66-66: 検索機能の案内文について
「searchThisUsersNotes」のキーは、特定ユーザーのノートを検索する目的で追加されています。アポストロフィーの表現（’s）の使い方が他のキーと一貫しているか、またユーザーにとって違和感がない表現になっているか確認をお願いします。
115-115: リノート操作に関する表現の確認
「renotedToX」キーは、リノート操作の結果として「〜にリノートされた」を表現しています。Misskey固有の用語として定着しているか、またUI内の他箇所と用語の統一がとれているか見直してください。
121-122: チャンネル向けリノート操作の文言について
「renoteToChannel」と「renoteToOtherChannel」は、それぞれチャンネルへのリノート操作を示すキーです。これらの表現がユーザーにとって直感的に理解できるか、また他の操作説明とのトーンの一貫性が取れているか再検討をお願いします。
132-133: ピン留め絵文字設定の説明文について
「pinnedEmojisForReactionSettingDescription」と「pinnedEmojisSettingDescription」は、反応時および絵文字ピッカーにおけるピン留め絵文字の設定を案内しています。両者の文言・用語が一貫しており、ユーザーに分かりやすい説明となっているかを確認してください。
176-176: リモートファイルキャッシュの説明文について
「cacheRemoteFilesDescription」は、リモートファイルの直接読み込みとキャッシュ利用のトレードオフについて詳述しています。文章がやや長いため、ユーザーにとって読みやすいように適切な改行や句読点の調整を検討することをお勧めします。
222-222: メディアサイレンス機能の表現について
「mediaSilenceThisInstance」は、サーバー上のメディアを一時的に非表示にする（サイレンスする）機能を示しています。「media-silence」という表現がやや専門的で分かりにくい可能性があるため、ユーザー目線の表現（例："Silence media from this server" など）との整合性を再検討してください。locales/id-ID.yml (1)
158-158: 新規キー「createAntenna」の追加について
「createAntenna」はアンテナ作成を示すメッセージですが、末尾の句点「.」がほかのエントリと一貫しているか確認してください。細かい文体の調整が必要な場合は、統一感を考慮すると良いでしょう。packages/backend/src/core/SystemWebhookService.ts (3)
53-76:fetchSystemWebhooksのクエリビルダー使用が適切です。
- 可変条件の組み立てが読みやすいです。ただし複合条件が増えた場合は再利用性を考慮し、別のヘルパーメソッドに切り出す案もあります。
81-107:createSystemWebhookのトランザクション的な扱いに注意してください。
- もし同時に複数の作成リクエストが走った場合でも矛盾が生じないか検討が必要です。
- 必要に応じてアプリケーション全体でトランザクション管理を行うか検討すると良いでしょう。
190-224:onMessageの実装が類似サービス(UserWebhookService)と一貫しています。
systemWebhookCreated/Updated/Deletedのイベントを活用し、activeSystemWebhooksを同期しています。- 副作用が増えた場合に備え、テストが不十分と感じられるため、イベント受信テストを追加することを検討してください。
packages/backend/src/core/RoleService.ts (4)
145-146:MiMetaを注入する実装について
- これまでは
redisClient等を利用していた箇所を置き換えたようですが、metaから取得する情報管理範囲を明確にしてください。
483-483:isExplorableメソッドはロール単位の探索可否を判定しています。
- ロール消失時なども想定したエラーハンドリングがあるとより安全です。
627-628: 重複したユーザ情報取得
- 直後でもう一度ユーザを
findOneByOrFailしているため、かつてのuserオブジェクトを再利用できるか検討の余地があります。
734-735:updateメソッドでの更新通知
roleUpdatedイベントの発行後、キャッシュ・フロントエンド側が適切に再取得するフローがあるか確認するとより確実です。locales/ja-KS.yml (1)
13-13: 初期設定説明文の内容確認
「initialPasswordForSetupDescription」の追加文中に「Miskkey」とありますが、正しくは「Misskey」ではないでしょうか？タイポと思われるので、修正を検討してください。locales/es-ES.yml (6)
11-12: 新規キーの追加: 初期パスワード関連
新たに追加されたキー
•initialPasswordForSetup: "Contraseña para iniciar la inicialización"
•initialPasswordIsIncorrect: "La contraseña para iniciar la configuración inicial es incorrecta."
を確認してください。
注意点として、片方で「inicialización」、もう片方で「configuración inicial」という表現が混在しているため、用語の統一を検討してください。
65-65: 空文字列の翻訳キーについて
キーsearchThisUsersNotesに空文字列が設定されています。
この値が意図的なものであるのか、デフォルトの文言が抜けているのかを確認してください。
114-114: 句読点の形式についての確認
キーrenotedToXの値 "{name} usuarios han renotado。" の末尾に全角句点「。」が使用されています。
通常、スペイン語では半角のピリオド「.」を用いるため、再検討をお願いします。
507-508: メニュースタイル関連の新規キー追加について
•menuStyle: "Diseño del menú"
•style: "Diseño"
が追加されています。
両キーが似た内容ですが、役割が異なる場合は説明文や注釈で意味合いを明確にすることを検討してください。
1251-1255: 問い合わせ・再試行関連の新規キー追加
以下のキーが追加されています。
•inquiry: "Contacto"
•tryAgain: "Por favor , inténtalo de nuevo"
•performance: "Rendimiento"
•unknownWebAuthnKey: "Esto no se ha registrado llave maestra."
•messageToFollower: "Mensaje a seguidores"
特にunknownWebAuthnKeyの訳がやや不自然に感じられるため、例えば「La clave WebAuthn no se ha registrado」といった表現を検討してください。
1256-1261: 入れ子構造の新規キー追加: abuseUserReport と delivery
以下の入れ子キーが新たに追加されています。
•_abuseUserReport.accept: "Acepte"
•_abuseUserReport.reject: "repudio"
•_delivery.stop: "Suspendido"
•_delivery._type.none: "Publicando"
一般的には命令形として、「Acepte」よりも「Aceptar」、「repudio」よりも「Rechazar」の方が自然な表現です。文言と業界標準の表現を見直してください。packages/backend/src/core/AbuseReportNotificationService.ts (5)
60-62: 複数報告がある場合のパフォーマンスに注意してください。
notifyAdminStreamメソッド内でモデレータごとに Abuse Report のループを回しているため、大量のレポートと多数のモデレータがいる場合にはパフォーマンスに影響が出る可能性があります。一括で送信するなどの最適化を検討しても良いかもしれません。
114-124: Promise.allを用いた同時送信のリソース負荷に注意。
notifyMailメソッド内でPromise.allを用いて複数のメール送信を同時に実行しており、高負荷時に外部メール送信サービスへの接続が集中する可能性があります。ジョブキューなどを使ってバッチ的に処理する方法も検討いただければと思います。
116-117: TODOコメントの早期対応を検討してください。
メソッド内に「送信処理はJobQueue化したい」とのコメントがあります。大量のメール送信時にはジョブキュー化による安定運用が望ましいため、スケジュールや優先度を見直して実装を進めることを推奨します。
221-227: クエリ条件の構築ロジックが複雑に感じられます。
orWhereの組み合わせが増えると、誤って不要なレコードが含まれる・除外されるリスクがあります。メソッドごとにクエリビルダーを分けるなど、シンプルに記述できる方法を検討してください。
424-431: リソース解放時の処理を統合し簡潔に。
disposeとonApplicationShutdownの両方で類似の処理を呼び出していますが、メンテナンス性を考慮すると、一つのメソッドにまとめる・あるいはフレームワークのライフサイクルに合わせる形がよりシンプルかと思われます。locales/ru-RU.yml (1)
1940-2148: 確認: 残りの翻訳更新と新規追加キーの一貫性の確認
ファイル全体を見ると、多数の新規翻訳キーおよび更新が行われています。更新された文言は、全般的に利用者にとって分かりやすく、各操作の意図を的確に伝える内容です。
ただし、一部の長文や専門用語については、原文との照合を通じた最終確認が望ましいかもしれません。全体としては、用語の統一と文脈に沿った表現がしっかり実現されており、非常に良好です。locales/zh-TW.yml (5)
11-13: 初期設定用パスワードキーの追加について
新たに「initialPasswordForSetup」「initialPasswordIsIncorrect」「initialPasswordForSetupDescription」が追加されています。これらの翻訳文が、ユーザーにとって明確かつ一貫性のある表現になっているか、また文脈に沿っているか再確認してください。
115-115: 転送通知キー 'renotedToX' の更新確認
「renotedToX: "轉發給 {name} 了。」が更新されています。プレースホルダー {name} の使用が適切か、また他の転送関連メッセージとの統一感があるか確認してください。
401-406: hCaptcha および mCaptcha 設定キーの確認
「hcaptchaSiteKey」「hcaptchaSecretKey」および「mcaptchaSecretKey」が変更されています。これらのキー名や説明文が、実際の設定項目としてユーザーに分かりやすく伝わるか、また他の入力フィールドとの統一感があるかを確認することをおすすめします。
497-497: リモート認証案内キーの確認
「signinOrContinueOnRemote: "若要繼續，需前往您所在的伺服器，或者註冊並登入此伺服器"」が追加されています。ユーザーが案内に従いやすい表現になっているか、また他のサーバー関連メッセージとの語調の整合性を確認してください。
2723-2730: 埋め込みコード生成設定の新オプションについて
_embedCodeGen セクションにおいて、「title」「header」「autoload」「maxHeight」などの新しい設定オプションが追加されています。これらの設定がユーザーにとって分かりやすく、またプレビューと実際の動作との間に齟齬が生じないよう、UI側での挙動も含めた検証を推奨します。
🛑 Comments failed to post (19)
locales/da-DK.yml (1)
3-4: 💡 Verification agent
🧩 Analysis chain
ローカライゼーションの修正が必要です
introMisskeyの内容が日本語のままになっています。デンマーク語（Dansk）のローカライゼーションファイルなので、この内容をデンマーク語に翻訳する必要があります。また、
headlineMisskeyが空文字列になっていますが、意図的なものでしょうか？もし適切なデンマーク語の見出しがあれば、追加することをお勧めします。
🏁 Script executed:
#!/bin/bash # 他の言語ファイルでheadlineMisskeyとintroMisskeyがどのように設定されているか確認する grep -A 2 "headlineMisskey:" locales/en-US.yml grep -A 2 "introMisskey:" locales/en-US.ymlLength of output: 1035
デンマーク語ローカライゼーションの修正が必要です
introMisskeyの値が日本語のまま記載されています。en-USの内容と同様に、正しいデンマーク語の翻訳に置き換えてください。headlineMisskeyが空文字列になっています。もし適切なデンマーク語の見出しがある場合は、こちらも設定することをお勧めします。.dockerignore (1)
34-35: 💡 Verification agent
🧩 Analysis chain
重複する除外エントリの可能性
packages/backend/test/compose.ymlのエントリが重複している可能性があります。これはタイプミスかファイル名の変更の反映漏れかもしれません。以下のスクリプトを実行して、重複するエントリを確認してください：
🏁 Script executed:
#!/bin/bash # .dockerignoreファイルの重複エントリを確認 grep -n "packages/backend/test/compose.yml" .dockerignoreLength of output: 131
重複エントリの削除をお願いします
検証の結果、ファイル
.dockerignoreの 34 行目と 35 行目に同一のエントリpackages/backend/test/compose.ymlが重複して記載されていることを確認しました。
不要な重複となりますので、どちらか一方を削除するか、意図的な記述であれば理由を明記してください。.github/misskey/test.yml (1)
3-4:
⚠️ Potential issueテスト環境用セットアップパスワードの追加
テスト環境用のセットアップパスワードが追加されました。「example_password_please_change_this_or_you_will_get_hacked」という値はデフォルト値として設定されていますが、セキュリティ上の懸念があります。
これはテスト環境用の設定ファイルですが、このようなデフォルトパスワードをソースコードに直接含めることは、誤って本番環境で使用された場合にセキュリティリスクになります。
本番環境用ではないとしても、以下のいずれかの対応を検討してください：
- パスワードをよりランダムで複雑な値に変更する
- 環境変数から読み込むように変更する
- 少なくともファイル名に「example」や「template」などを追加して、直接使用されないようにする
idea/MkAbuseReport.stories.impl.ts (1)
10-11: 💡 Verification agent
🧩 Analysis chain
インポートパスの更新
Storybookのモックとフェイクのインポートパスが更新されています。これはプロジェクト構造の再編成の一環と思われます。パスが正しく、実際のファイル構造と一致していることを確認してください。
- import { abuseUserReport } from '../../.storybook/fakes.js'; - import { commonHandlers } from '../../.storybook/mocks.js'; + import { abuseUserReport } from '../packages/frontend/.storybook/fakes.js'; + import { commonHandlers } from '../packages/frontend/.storybook/mocks.js';以下のコマンドを実行して、新しいインポートパスが有効であることを確認してください：
🏁 Script executed:
#!/bin/bash # 更新されたインポートパスが存在するか確認する echo "Checking if the new import paths exist..." if [ -f "packages/frontend/.storybook/fakes.js" ] && [ -f "packages/frontend/.storybook/mocks.js" ]; then echo "✅ Both files exist at the new paths" else echo "❌ One or both files do not exist at the new paths" echo "Checking original paths..." if [ -f ".storybook/fakes.js" ] && [ -f ".storybook/mocks.js" ]; then echo "⚠️ Files exist at the original paths but not at the new paths" fi fiLength of output: 348
インポートパスの更新に問題があります
・実行したスクリプトの結果、新しいパス
packages/frontend/.storybook/fakes.jsおよびpackages/frontend/.storybook/mocks.jsにファイルが存在しないことが確認されました。
・元のパスも存在しない模様ですので、プロジェクトのディレクトリ構造が再構成された後、正しいパスがどこにあるのか再確認する必要があります。
・該当箇所（idea/MkAbuseReport.stories.impl.ts：行10-11）のインポート文を、正しいファイルの場所に合わせて修正してください。- import { abuseUserReport } from '../../.storybook/fakes.js'; - import { commonHandlers } from '../../.storybook/mocks.js'; + import { abuseUserReport } from '../packages/frontend/.storybook/fakes.js'; + import { commonHandlers } from '../packages/frontend/.storybook/mocks.js';Committable suggestion skipped: line range outside the PR's diff.
packages/backend/src/core/DownloadService.ts (1)
44-44:
⚠️ Potential issueデフォルト値の削除によるバグの可能性
maxFileSizeのデフォルト値が削除されています。これにより、設定ファイルでmaxFileSizeが指定されていない場合、maxSizeがundefinedになる可能性があります。このコードの75-78行目と93-96行目では、ダウンロードサイズが
maxSizeを超えた場合のチェックがありますが、maxSizeがundefinedの場合、これらのチェックが正しく機能しない可能性があります。次のように修正してデフォルト値を復活させることをお勧めします：
-const maxSize = this.config.maxFileSize; +const maxSize = this.config.maxFileSize ?? 262144000; // 約250MB📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.const maxSize = this.config.maxFileSize ?? 262144000; // 約250MBcypress/support/commands.ts (1)
51-51:
⚠️ Potential issueセキュリティリスク: ハードコードされたパスワード
テスト用とはいえ、コメントにも記載されている通り「example_password_please_change_this_or_you_will_get_hacked」というパスワードをハードコードすることはセキュリティリスクがあります。環境変数または設定ファイルから読み込む方法を検討すべきです。
- ...(isAdmin ? { setupPassword: 'example_password_please_change_this_or_you_will_get_hacked' } : {}), + ...(isAdmin ? { setupPassword: process.env.ADMIN_SETUP_PASSWORD || 'testpassword' } : {}),📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements....(isAdmin ? { setupPassword: process.env.ADMIN_SETUP_PASSWORD || 'testpassword' } : {}),packages/backend/src/core/UserRenoteMutingService.ts (1)
29-29:
⚠️ Potential issue期限付きミュート機能の追加（未実装）
expiresAtパラメータが追加されましたが、実際にこのパラメータを使用するコードが実装されていません。このパラメータをデータベースに保存し、期限切れのミュートを処理するロジックを追加する必要があります。public async mute(user: MiUser, target: MiUser, expiresAt: Date | null = null): Promise<void> { await this.renoteMutingsRepository.insert({ id: this.idService.gen(), muterId: user.id, muteeId: target.id, + expiresAt: expiresAt, }); await this.cacheService.renoteMutingsCache.refresh(user.id); }また、RenoteMutingエンティティに
expiresAtカラムを追加するためのマイグレーションも必要です。healthcheck.sh (1)
7-7:
⚠️ Potential issueヘルスチェックの改善が必要です
ヘルスチェックエンドポイントを
/healthzに変更したのは良い変更ですが、curlコマンドのオプション指定に問題があります。
-Sfso/dev/nullの部分で、-oオプションと/dev/nullの間にスペースがありません。これにより、curlがオプションを正しく解釈できない可能性があります。以下の修正を提案します：
-curl -Sfso/dev/null "http://localhost:${PORT}/healthz" +curl -Sfso /dev/null "http://localhost:${PORT}/healthz"あるいは：
-curl -Sfso/dev/null "http://localhost:${PORT}/healthz" +curl -Sfs -o /dev/null "http://localhost:${PORT}/healthz"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.curl -Sfs -o /dev/null "http://localhost:${PORT}/healthz"packages/backend/src/core/FederatedInstanceService.ts (1)
73-89: 🛠️ Refactor suggestion
新しい
fetchメソッドの追加インスタンスを取得するだけで登録しない新しいメソッドが追加されました。存在しないインスタンスの処理も適切に行われています。
しかし、
fetchOrRegisterメソッドではnormalizeHostを使用していますが、この新しいfetchメソッドではtoPunyを使用しています。同じキャッシュと相互作用するため、正規化方法に一貫性を持たせるべきです。- host = this.utilityService.toPuny(host); + host = this.utilityService.normalizeHost(host);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.@bindThis public async fetch(host: string): Promise<MiInstance | null> { host = this.utilityService.normalizeHost(host); const cached = await this.federatedInstanceCache.get(host); if (cached !== undefined) return cached; const index = await this.instancesRepository.findOneBy({ host }); if (index == null) { this.federatedInstanceCache.set(host, null); return null; } else { this.federatedInstanceCache.set(host, index); return index; } }packages/backend/scripts/check_connect.js (1)
17-35:
⚠️ Potential issuePromise executor 内で
asyncを使用しているため、実行フローに問題が生じる可能性があります。
Promise executor 関数にasyncを付与すると、二重に Promise を返すような扱いになり、予期しない動作が起こるリスクがあります。下記のように修正を検討してください。- return await new Promise(async (resolve, reject) => { + return new Promise((resolve, reject) => {Committable suggestion skipped: line range outside the PR's diff.
🧰 Tools
🪛 Biome (1.9.4)
[error] 18-35: Promise executor functions should not be
async.(lint/suspicious/noAsyncPromiseExecutor)
packages/backend/src/core/NoteCreateService.ts (1)
208-208:
⚠️ Potential issueコードの重複
210行目も同じコードが記述されており、重複しています。
updateNotesCountQueueの初期化が2回行われており、1回目は不要です。-this.updateNotesCountQueue = new CollapsedQueue(process.env.NODE_ENV !== 'test' ? 60 * 1000 * 5 : 0, this.collapseNotesCount, this.performUpdateNotesCount);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.// (The duplicate initialization has been removed from line 208.) // The initialization present at line 210 remains.packages/backend/src/core/EmailService.ts (1)
20-20:
⚠️ Potential issueConfig インポートパスを変更
Configのインポートパスが
@@/js/config.jsに変更されていますが、このパスでモジュールが見つからないというパイプラインエラーが発生しています。パイプラインエラーによると、
@@/js/config.jsモジュールが見つかりません。正しいインポートパスに修正する必要があります：-import type { Config } from '@@/js/config.js'; +import type { Config } from '@/config.js';📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.import type { Config } from '@/config.js';🧰 Tools
🪛 GitHub Actions: Lint
[error] 20-20: Cannot find module '@@/js/config.js' or its corresponding type declarations.
packages/backend/src/core/DriveService.ts (1)
507-518: 🛠️ Refactor suggestion
重複ファイルの検知と感度フラグの上書き
ファイルのMD5が既存と重複する場合、isSensitiveを上書きしています。並行アクセス時に競合が起こる可能性があるため、必要に応じてロックやバージョン管理などをご検討ください。packages/backend/src/core/ReactionService.ts (1)
94-94: 🛠️ Refactor suggestion
ReactionsBufferingServiceの依存追加
バッファリング処理を中央集約管理する方針は、パフォーマンスや一貫性の向上が期待されます。負荷が高い環境での動作テストを検討ください。packages/backend/src/core/AbuseReportService.ts (1)
87-118: 🛠️ Refactor suggestion
resolve()内の一括更新にトランザクション適用を検討してください。複数の通報をループで個別に
awaitしているため、途中でエラーが起きると一部だけ更新される恐れがあります。データの整合性を重視する場合はトランザクション対応が望ましいです。locales/ko-KR.yml (1)
191-194: 🛠️ Refactor suggestion
リモートサーバー操作関連キーの更新について
行191～194では、continueOnRemote、chooseServerOnMisskeyHub、specifyServerHost、およびinputHostNameの各キーが追加されています。これらはリモートサーバーへの移行や指定に関する案内であり、ユーザーに対して分かりやすい指示を提供しています。UIフローの観点から意味が一貫しているか、再度ご確認ください。packages/backend/src/core/UserSuspendService.ts (2)
46-61: 🛠️ Refactor suggestion
エラーの握りつぶしに注意
(async () => {...})().catch(e => {})の形でエラーを無視しているため、問題発生時にデバッグが困難になるおそれがあります。最低限、ログ出力するなどの対策を行う方が望ましいです。
63-74: 🛠️ Refactor suggestion
unsuspendメソッドも同様にエラー処理を検討
suspendと同様に、無名関数内で.catch(e => {})を用いており、エラーを握りつぶす形です。ユーザーの復帰処理で異常が発生した場合のトラブルシューティングが困難になる可能性があります。locales/es-ES.yml (1)
2358-2359:
⚠️ Potential issue通知タイプのキー追加: login と test
新たに追加された通知タイプのキー：
•login: "Iniciar sesión"
•test: "Pruebas de nofiticaciones"
に関して、特にtestの値に誤字 ("nofiticaciones" → "notificaciones") が見受けられます。正しいスペルに修正してください。
|
* refactor: flatten search index * chore: use Function() to simplify parsing attribute * chore: remove comment handling * chore: simplify processing SearchLabel and SearchKeyword element * chore: use SearchLabel in mutedUsers * chore: small improvements * chore: remove a fallback path and simplify the entire code * fix: result path is not correct * chore: inline function
* New translations ja-jp.yml (Korean) * New translations ja-jp.yml (Dutch) * New translations ja-jp.yml (Dutch) * New translations ja-jp.yml (Italian) * New translations ja-jp.yml (German) * New translations ja-jp.yml (German) * New translations ja-jp.yml (Chinese Traditional) * New translations ja-jp.yml (Catalan)
本流で対策されているので、その時が来たらrevertする
いい感じに。
|
|
replaced #1029 |
11 participants
What
Why
Additional info (optional)
Checklist
Summary by CodeRabbit
新機能
クライアント向け改善
サーバー側対策・修正
その他