Host controls in the live video stage fail silently
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
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
- Fournit un Dockerfile ou un fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de TheCodeHeist-Coder/Rexial
-
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
TheCodeHeist-Coder/Rexial#235 ·
Les mainteneurs répondent en général sous 1 jour
-
bug good first issue help wanted UI & UX
Difficulté 1/5 Moins d'une heure Accessibilité débutants 95/100
TheCodeHeist-Coder/Rexial#178 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
bug enhancement good first issue help wanted UI & UX
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
TheCodeHeist-Coder/Rexial#162 ·
Les mainteneurs répondent en général sous 1 jour
-
Critical security: a couple of access control problems in the API and ws-server (details to be shared privately)Peut-être pris @Anshuu2004 l’a pris il y a 11 jours. Ouvertelevel3 nsoc26
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
TheCodeHeist-Coder/Rexial#215 · 4 commentaires · 1 personne assignée ·
Les mainteneurs répondent en général sous 1 jour
-
enhancement help wanted UI & UX
Difficulté 4/5 3-5 jours Accessibilité débutants 54/100
TheCodeHeist-Coder/Rexial#201 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de TheCodeHeist-Coder/Rexial
Issues similaires
-
FR: Support CJK brackets, symbols and full-width markers in footnoteHeuristics (EBPAJ support)Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
readest/readest#7413 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
content triage
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
eliasstravik/herdr-projects#788 ·
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
Les mainteneurs répondent en général sous 1 jour
-
Ability to edit tagsOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
Les mainteneurs répondent en général sous 1 jour