Enforce explicit async error boundaries - #75
Conversation
✅ Deploy Preview for rdlabo-ionic-angular-library ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
| let result: unknown; | ||
| try { | ||
| result = (this.#errorHandler.handleError as (reportedError: unknown) => unknown)(error); | ||
| } catch { | ||
| return; | ||
| } | ||
| if (result instanceof Promise) { | ||
| void result.catch(() => undefined); | ||
| } |
There was a problem hiding this comment.
🔴 オフライン同期のバックグラウンド失敗がアプリのエラー報告先に届かなくなる
エラー報告の呼び出し(offline-sync.service.ts:1495 の handleError 呼び出し)がメソッドを持ち主から切り離して実行するため、報告処理自体が失敗し、その失敗も握りつぶされるので、バックグラウンドの同期エラーが誰にも通知されなくなります。
Impact: 同期・プル・フック失敗の通知がアプリのエラー報告(ログ/監視)に一切届かず、障害が無言で消えます。
レシーバを失った `handleError` 呼び出しの仕組み
#dispatchError は this.#errorHandler.handleError を関数値として取り出し、レシーバ無しで呼び出しています(projects/kit/offline/src/lib/offline-sync.service.ts:1495)。この形では呼び出し時の this が undefined になるため、this を参照する ErrorHandler 実装(Angular 既定実装の this._findOriginalError(...) や、DI したロガー等を this 経由で使うアプリ独自ハンドラ)は TypeError を投げます。その例外は直後の catch { return; }(projects/kit/offline/src/lib/offline-sync.service.ts:1496-1498)で無言に破棄されるため、エラーは記録されません。
#reportError は #flushInBackground(projects/kit/offline/src/lib/offline-sync.service.ts:868)や discardAllPending の onCommandRemoved 失敗経路(projects/kit/offline/src/lib/offline-sync.service.ts:855)から使われる唯一の報告経路です。変更前は this.#errorHandler.handleError(error) とメソッド呼び出しだったため this は保持されていました。
テストでは ErrorHandler を { handleError }(プレーンな vi.fn)で差し替えているため this を使わず、この退行は検出されません。
| let result: unknown; | |
| try { | |
| result = (this.#errorHandler.handleError as (reportedError: unknown) => unknown)(error); | |
| } catch { | |
| return; | |
| } | |
| if (result instanceof Promise) { | |
| void result.catch(() => undefined); | |
| } | |
| let result: unknown; | |
| try { | |
| result = this.#errorHandler.handleError(error) as unknown; | |
| } catch { | |
| return; | |
| } | |
| if (result instanceof Promise) { | |
| void result.catch(() => undefined); | |
| } |
Was this helpful? React with 👍 or 👎 to provide feedback.
Summary
@rdlabo/eslint-plugin-rulesv21.2.6 and enable typed@rdlabo/rules/restrict-try-blocklintingPromise.resolve()scheduling with explicit synchronous boundaries, Promise rejection paths, and deterministic cleanupWhy
Broad try/catch blocks can accidentally hide rejected Promises or classify cleanup failures as primary operation failures. The shared kit now enforces small, responsible synchronous error boundaries and explicit asynchronous handling at lint time.
Review fixes
Validation
npm run lintnpx ng test kit --watch=false(45 files, 841 tests)npx ng build kit --configuration=productiongit diff --check