fix(pairing): show the server's error message instead of the raw AxiosError#38
Open
ClaydeCode wants to merge 2 commits into
Open
fix(pairing): show the server's error message instead of the raw AxiosError#38ClaydeCode wants to merge 2 commits into
ClaydeCode wants to merge 2 commits into
Conversation
…sError Pair.vue and Terminals.vue assigned the caught axios error object straight to the message rendered in the template, so a failed pairing showed "AxiosError: Received HTTP status 401" instead of what went wrong. The backend now sends a specific reason in the response body's detail field (FreeshardBase/freeshard#156); this renders it. Both views now pipe the error through the existing errorMessage filter, which already extracts response.data.detail and is used the same way in Apps.vue and AppStoreEntry.vue. That filter dereferenced error.response.data unguarded, so it threw a TypeError on any error without a response -- exactly the network-failure case where the user most needs a message. Guard the lookup and fall back to the axios message. This also fixes the same latent crash for the two existing call sites. Move the filter to lib/errors.js so it can be unit-tested: main.js mounts the app on import, so nothing defined there is reachable from a test. lib/ with a matching tests/unit spec is the existing pattern (see lib/pricing.js).
src/lib was missing from the project structure entirely although lib/pricing.js predates this change. Record it along with the rule that caught errors are rendered through the errorMessage filter, which is the convention that keeps raw AxiosError text out of the UI.
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
1 participant
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.
Frontend half of FreeshardBase/freeshard#156. Pairs with FreeshardBase/freeshard#164, which makes the backend send the reason.
Problem
Pair.vueandTerminals.vuebound the caught axios error object straight into the template, so a failed pairing renderedAxiosError: Received HTTP status 401— the exact symptom Stefan reported.Change
Both views now render through the existing
errorMessagefilter ({{ err | errorMessage }}), which already extractsresponse.data.detailand is used the same way inApps.vueandAppStoreEntry.vue. The issue spec suggested inliningresponse?.response?.data?.detail; reusing the filter avoids a third pattern for the same job, and optional chaining is not used anywhere in this codebase (Vue 2 templates cannot compile it).That filter dereferenced
error.response.dataunguarded, so it threw aTypeErroron any error without aresponse— exactly the network-failure case where the user most needs a message. It is now guarded and falls back to the axiosmessage. This also fixes the same latent crash for the two pre-existing call sites.The filter moved to
src/lib/errors.jsso it can be unit-tested:main.jsmounts the app on import, so nothing defined there is reachable from a test.lib/+ a matchingtests/unitspec is the existing pattern (seelib/pricing.js).Verification
vue-cli-service lint→ no errors.vue-cli-service build→ build complete, which is what proves the template filter compiles.Note:
buildneedsNODE_OPTIONS=--openssl-legacy-provideron Node 20 (webpack 4 / OpenSSL 3). Pre-existing on main, unrelated to this change, left alone.I did not drive the real browser end-to-end. The chain is covered in pieces: the backend returns the detail (tested in freeshard#164), the filter extracts it (tested here), and the templates apply it (build compiles).
Recommended reading order
src/lib/errors.js— extracted, now null-safesrc/main.js— filter registrationsrc/views/Pair.vue,src/views/Terminals.vue— the two render sitestests/unit/errors.spec.jsagents.mdDocs
agents.mdgained thesrc/lib/entry (missing entirely, thoughlib/pricing.jspredates this change) and the error-rendering convention.🤖 Generated with Claude Code