Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Catch provider setup errors instead of crashing the server at boot

Fermée Adaptée aux débutants
  • Quelque chose ne va pas ?
#175 0 commentaires 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
83/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
node.js, typescript
Domaine
backend

Piste de recherche

Commencez dans packages/server/src/handler.ts, au niveau de la création du fournisseur vers la ligne 18 et du await dans handleChat vers la ligne 33, puis lisez les tests existants du handler dans packages/server/tests/handler.test.ts, qui simulent createProvider. Vérifiez comment les échecs de génération de réponse sont renvoyés et comment la validation et la limitation du débit sont couvertes. Le travail est terminé lorsque le rejet lors de la configuration est pris en charge et journalisé une seule fois, que les requêtes renvoient { error: 'provider_error' } et que les tests incluent un changeset de type patch pour @chatcops/server.

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

Description

bug good first issue hacktoberfest server

createChatHandler starts creating the provider right away and only awaits it inside the first request (packages/server/src/handler.ts, line 18 and line 33). If that promise rejects, for example with an unknown provider.type or a provider SDK that throws on a missing key, nothing handles the rejection. Node treats an unhandled rejection as fatal by default, so the whole server process exits at startup. After that, if the process survives, every request rethrows at line 33, outside the try that starts further down, and the visitor gets a bare internal_error.

What to do

  • Handle the rejection where the promise is created, and log it once with the [chatcops] prefix, for example [chatcops] Provider setup failed: <message>. Don't log the API key or the config object.
  • In handleChat, await the provider inside a try and yield { error: 'provider_error' } when setup failed, the same error the visitor already sees for a failed reply.
  • Keep request validation and rate limiting working as they do today.

Acceptance criteria

  • A handler created with a provider whose setup rejects doesn't cause an unhandled rejection (a test can listen for unhandledRejection, or check that the rejection is handled)
  • Requests to that handler yield { error: 'provider_error' } and the setup error is logged once, not once per request
  • Tests in packages/server/tests/handler.test.ts (it already mocks createProvider)
  • Changeset for @chatcops/server (patch)
  • pnpm -r build, pnpm test and pnpm -r typecheck pass

Want to work on this? Comment below and I'll assign it to you. Please take one issue at a time, branch off dev, and open your PR against dev with Closes #<this issue number>. Setup notes (pnpm, build before test) are in CONTRIBUTING.md.

Langage dominant
TypeScript
Étoiles
13
Forks
7
Merge moyen
3 h 41 min
PR mergées (30 j)
155

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 codercops/chatcops

Toutes les issues de codercops/chatcops

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.