Host controls in the live video stage fail silently

Fermée Adaptée aux débutants
#205 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
84/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
react, typescript
Domaine
frontend

Piste de recherche

Commencez dans apps/frontend/src/components/live/LiveStage.tsx en comparant la gestion des erreurs du bouton d’action de l’hôte avec les commandes du micro du lecteur qui utilisent streamError et affichent problem. Vérifiez l’autre chemin d’erreur qui n’apparaît que dans la console, mentionné vers la ligne 472. Le travail est terminé lorsque les actions de l’hôte qui échouent affichent un message compréhensible à côté de la commande, qu’une nouvelle tentative réussie l’efface et que le comportement côté lecteur reste inchangé.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug good first issue help wanted UI & UX

In apps/frontend/src/components/live/LiveStage.tsx, the host's action buttons — letting a player speak, taking the floor back — swallow their errors into the console:

onClick={async () => {
  setBusy(true);
  try {
    await onClick();
  } catch (err) {
    console.error("[live] host action failed", err);   // nothing reaches the host
  } finally {
    setBusy(false);
  }
}}

The button goes busy, comes back, and nothing changes. No message, no retry, no indication the request failed at all.

Why it matters

This happens live, in front of a room. A host taps "let in" on a raised hand, the button flickers, and the player stays silent. The host has no idea whether they misclicked, whether the player's connection is bad, or whether the request failed — so they tap it again, and again.

Meanwhile the player is waiting to speak and can see their hand is still up.

There is already a correct pattern in the same file

The player-side mic controls handle this properly:

const run = async (action: () => Promise<unknown>, failure: string) => {
  setBusy(true);
  setProblem(null);
  try {
    await action();
  } catch (err) {
    setProblem(streamError(err, failure));   // shown to the user
  } finally {
    setBusy(false);
  }
};

streamError already turns a failed request into a readable message, and the component already renders problem. The host buttons just never got the same treatment.

What a fix looks like

Give the host actions the same error state the player controls have, and show the message near the control that failed rather than at the top of the stage — the host is looking at a list of participants, so an error floating elsewhere is easy to miss.

Worth checking the whole file for other places that only console.error. The two paths I know about are the host action button and one around line 472.

Definition of done
  • A failed host action shows a readable message, not just a console line
  • The message appears near the control the host used
  • The error clears on a successful retry
  • The player-side behaviour is unchanged

Good first issue: the working pattern is a few hundred lines below in the same file, so this is mostly applying something that already exists.

Langage dominant
TypeScript
Étoiles
21
Forks
7
Merge moyen
8 h 12 min
PR mergées (30 j)
36

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de TheCodeHeist-Coder/Rexial

Toutes les issues de TheCodeHeist-Coder/Rexial

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.