fix: propagate HTTP status from persistence.get through DocRoom.fetch response#134
Merged
fix: propagate HTTP status from persistence.get through DocRoom.fetch response#134
Conversation
… response When da-admin returns 401/403/404, the error thrown by persistence.get now carries an err.status property. DocRoom.fetch reads err.status ?? 500 so the client receives the real status code instead of always getting 500. This lets clients (and monitoring) distinguish auth failures from actual server errors and enables correct retry / redirect behaviour on the client side. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
bosschaert
approved these changes
Apr 30, 2026
adobe-bot
pushed a commit
that referenced
this pull request
Apr 30, 2026
## [1.2.1](v1.2.0...v1.2.1) (2026-04-30) ### Bug Fixes * propagate HTTP status from persistence.get through DocRoom.fetch response ([#134](#134)) ([eac219d](eac219d))
|
🎉 This PR is included in version 1.2.1 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
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
3 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.
Summary
persistence.get()now attacheserr.status = initialReq.statusto thrown errors so callers can read the original HTTP status codeDocRoom.fetchcatch block readserr.status ?? 500— 401/403/404 errors are now returned with their real status code; unknown errors still return 500 with "Internal Server Error"Background
When da-admin returns 401 or 403 (auth failure), the WebSocket upgrade path in
DocRoom.fetchwas catching those errors and always returning 500 "Internal Server Error". This made it impossible for clients and monitoring to distinguish auth failures from actual server bugs.Observed in production logs: 401/403 auth errors showing up as 500 responses, making them look like worker crashes rather than expected auth rejections.
Test plan
npm test)Test persistence get 404— verifies error carriesstatus: 404Test persistence get throws— verifies error carriesstatus: 500Test persistence get 401 carries status for propagation— new test for 401Test persistence get 403 carries status for propagation— new test for 403Test DocRoom fetch fails when document deleted after auth— updated: now expects 404Test DocRoom fetch propagates 401 when auth check fails— new testTest DocRoom fetch returns 500 for unexpected errors— new test verifying untyped errors still produce 500🤖 Generated with Claude Code