fix(errors): add res param to onError hook and guard against internal throw#102
Merged
Conversation
added 5 commits
May 12, 2026 19:07
… throw - onError(err, req, res): response object now available for observability - Wrap onError call in try/catch — hook failure must not suppress original error - Type definition updated: onError?: (error: Error, request: Request, response: Response) => void Closes #101
…params restana.Request/Response are generic types requiring Protocol<P> — incompatible with the Hooks interface which is not parameterized. Node's native types are the correct base types (restana extends them) and require no type arguments.
- Type: use Function for onError (consistent with all other hooks in Hooks interface) - Async: await onError call so async hooks that reject are caught by try/catch - Tests: 4 new tests covering sync, async, throwing, and no-error paths - All 4 new tests pass (54 total, 1 pre-existing failure unchanged)
restana v5.2.0 sanitizes error messages — returns 'Internal Server Error' instead of the thrown message. The test contract is '500 is returned', not the specific error string.
Collaborator
Author
Verification Certificate v5.1 — PR #102Classification: Axes Summary (9 axes)
ρ Breakdown
Verdict: Auto-Approve ✅All 9 axes pass. The spec-independence flag fires (same author wrote both) and adds +0.05 to ρ, but under v5.1 this no longer mechanically blocks — it's recorded in the certificate as an attestation. η=0.95 and ρ=0.05 both clear their thresholds. Protocol v5.1 — §7.4 auto-correction mandate active. |
jkyberneees
approved these changes
May 12, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Fixes issues identified in #101's onError hook implementation, then hardened via AI Verification Protocol (v4.0) review.
Protocol-driven fixes from review:
Function(wasimport("http").IncomingMessage/ServerResponse). All other hooks useFunction— the native http types are technically accurate (restana objects ARE IncomingMessage/ServerResponse) but strip restana-augmented methods likeres.send()from the TypeScript consumer. Consistency wins.await onError()— the original sync call left async hook rejections unhandled (Node 16+ terminates on unhandled rejections).awaitcatches both sync throws and async rejections in the same try/catch.Verification
on-request-errortest — unchanged)onError(err, req)handlers ignore extra parameter; sync hooks work viaawaitCloses #101