Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Nothing stops a player spamming the raise-hand button

オープン
  • 何か問題がありますか？
#206 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
65/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
express, react, typescript
領域
api, backend, frontend, testing

調査の方向性

Start with the hand route in apps/streaming/src/routes.ts and read routes.test.ts for the existing permission test style. Trace how the frontend sends hand changes and disables controls, then check how this service stores per room state. Done when rapid changes are refused before broadcast, the button shows the cooldown, normal toggles work, and a test covers the limit.

索引モデルが issue の本文から書いたものです。

説明

Backend first issue enhancement help wanted

The raise-hand endpoint has no rate limit:

// apps/streaming/src/routes.ts
router.post("/sessions/:sessionId/hand", async (req, res) => {
    const caller = await requireCaller(req, res);
    if (caller.kind !== "participant") {
        return errorResponse(res, 403, "Only players raise a hand.");
    }

    const raised = req.body?.raised === true;
    await roomService.updateParticipant(..., {
        attributes: { hand: raised ? "up" : "" },
    });

Every call writes a participant attribute, and attribute changes are broadcast to every client in the room. With 300 players connected, one person holding the button down produces a stream of updates to 300 clients, each of which re-renders the host's list of raised hands.

There is no rate limiting anywhere in apps/streaming — I checked.

Why it matters

Two separate problems.

For the host: the raised-hand list is how they decide who speaks next. A player toggling repeatedly makes that list flicker and reorder while the host is trying to click someone in it.

For the room: every toggle is a broadcast to 300 clients. It is not expensive per message, but it is unbounded and it costs every participant, not just the person doing it.

Neither needs malice. A player on a bad connection tapping a button that does not appear to respond will tap it several more times.

What a fix looks like

A short per-participant cooldown on the server — a second or two between hand changes — refusing anything faster.

The frontend should disable the button during the cooldown so the limit is visible rather than a request that silently fails. That is the part that actually helps the player on the bad connection.

Worth considering the same treatment for the speaker endpoints, since those write attributes too. A host clicking promote twice is less likely but the broadcast cost is identical.

Worth thinking about
  • Where does the cooldown state live? In-process is simplest and fine while apps/streaming runs as one instance, but it will not hold if that ever changes — same shape as the other state this service keeps per room. Worth a comment either way.
  • Should an ignored request be a 429 or a silent success? A 429 is more honest and lets the frontend show something useful.
Definition of done
  • Rapid hand toggles from one player are refused rather than broadcast
  • The button is visibly unavailable during the cooldown
  • Normal use — raising a hand, lowering it a moment later — is unaffected
  • A test covers the limit being hit

routes.test.ts has 22 tests covering the existing permission paths; worth reading for the style before adding to it.

主要言語
TypeScript
スター
21
フォーク
7
平均マージ
4時間 31分
マージ済み PR（30日）
22

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

TheCodeHeist-Coder/Rexial のほかの issue

TheCodeHeist-Coder/Rexial の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。