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

Include connection info on errors

オープン
#3,334 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
42/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
javascript, postgresql

調査の方向性

まず、pg Client と Pool のエラーがどのように生成され、伝播するかを追跡します。切断後の catch ハンドラーで利用できるエラーオブジェクトに重点を置いてください。完了条件は、エラーが対象ホストまたは同等の接続情報を公開しつつ、Client や Pool を付加してメモリ保持のリスクを招かないことです。この issue では特定のファイルやテストは指定されていません。

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

説明

feature request

I have an app that connects to multiple PG instances. When a pg client/pool encounters an error, the only way to know which database was the culprit is to have a handle to the Client/Pool object. But often times your error handling code does not have a handle to the Client/Pool objects (by its nature, error handling code is often disconnected from the code that threw the error). The only thing error handling has a handle to is the error itself.

An example:

try { 
  await doSomethingWithVariableDb();
} catch (err) {
 // This does not currently work.
  console.error("Error doing something with DB " + err.host);
}

It would be nice if pg included this target host info on errors. Alternatively, pg could include the associated Client and/or Pool object on the error. Although that seems more prone to leaking memory.

主要言語
JavaScript
スター
13.2k
フォーク
1.4k
平均マージ
6日 15時間
マージ済み PR(30日)
6

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

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

brianc/node-postgres のほかの issue

brianc/node-postgres の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

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

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