Handle network failures in portal and remote channel endpoints#14813
Merged
rtibbles merged 1 commit intoJun 25, 2026
Conversation
github-actions
Bot
added
DEV: backend
Contributor
Build Artifacts
Smoke test screenshot |
rtibbles
force-pushed
the
handle-network-failures
branch
from
11b6493 to
c2e289d
Compare
akolson
reviewed
Jun 23, 2026
| return channels | ||
| except NetworkLocationResponseFailure as e: | ||
| if e.response.status_code == 404: | ||
| if e.response is not None and e.response.status_code == 404: |
Member
There was a problem hiding this comment.
Maybe we should use HTTPStatus.NOT_FOUND or from rest_framework import status instead of hardcoded codes?
Member
There was a problem hiding this comment.
Member
Author
There was a problem hiding this comment.
Yes, seems reasonable, will update!
Fixes a family of crashes in the views that proxy to the Kolibri Data Portal and Studio, surfaced while removing real network access from the test suite: - NetworkLocationResponseFailure.response is None when the request failed without an HTTP response, so accessing response.status_code or response.json() on it raised AttributeError (500) in the portal register and validate_token actions, the remote channel lookup, and the v2 community library lookup. - A non-404 upstream error in the remote channel lookup fell off the end of the except block, so list returned 200 with a null body and retrieve returned a spurious 404. - NetworkLocationResponseTimeout was uncaught in the remote channel and validate_token actions, and connection failures were uncaught in register, all returning 500. - A non-JSON error body (e.g. a Cloudflare HTML error page) crashed register, and validate_token reflected the raw bytes back to the client. Network-level failures now consistently return 503 with an "offline" status, and 404 from the content server still maps to Http404. The portal endpoints no longer reflect upstream response bodies wholesale: error bodies are reduced to the recognized error constants the frontend matches on (with ALREADY_REGISTERED_FOR_COMMUNITY now mirrored in error_constants.py), the validate_token success response is reduced to the project name the frontend uses, and a missing or non-JSON body is treated as another network-level failure: 503 offline. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
rtibbles
force-pushed
the
handle-network-failures
branch
from
c2e289d to
99355ed
Compare
akolson
approved these changes
Jun 25, 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.
Summary
register/validate_token, remote channel list/retrieve) crashed with 500s on network-level failures:NetworkLocationResponseFailure.responsecan beNone, timeouts and connection failures were uncaught, and a non-404 Studio error fell off the end of an except block (200 withnullbody on list, spurious 404 on retrieve){"status": "offline"}validate_token's success response to the project name the frontend uses; non-JSON bodies (e.g. CDN error pages) are treated as network-level failuresReferences
Reviewer guidance
RemoteChannelViewSetpreviously gave 200 with anullbody (list) or a spurious 404 (retrieve); both now give 503 offline — worth checking the device plugin's channel import flow handles thatAI usage
Written with Claude Code, test-first. I reviewed the diff and directed two revisions — first dropping reflection of raw upstream bytes, then reducing the reflection to the explicit whitelist of error constants — and verified the affected suites pass.