Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Catch provider setup errors instead of crashing the server at boot

Geschlossen Anfängerfreundlich
  • Stimmt etwas nicht?
#175 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
83/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
node.js, typescript
Bereich
backend

Rechercherichtung

Beginne in packages/server/src/handler.ts bei der Provider-Erstellung um Zeile 18 und beim await in handleChat um Zeile 33. Lies anschließend die vorhandenen Handler-Tests in packages/server/tests/handler.test.ts, die createProvider mocken. Prüfe, wie Fehler beim Erstellen einer Antwort zurückgegeben werden und wie Validierung und Rate Limiting abgedeckt sind. Fertig ist die Arbeit, wenn eine Ablehnung beim Setup behandelt und einmal protokolliert wird, Anfragen { error: 'provider_error' } zurückgeben und die Tests einen Patch Changeset für @chatcops/server enthalten.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
TypeScript
Sterne
13
Forks
7
Ø Merge
3 Std. 41 Min.
Gemergte PRs (30 T.)
155

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus codercops/chatcops

Alle Issues in codercops/chatcops

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.