fix: inconsistent w3ui custom URL handling #404
Closed
Conversation
This file contains 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
|
Looks like @alanshaw and @hugomrdias might be good reviewers for this? (And if this PR is approved please do the merge too, since I do not have write access.) |
|
the pr has multiple changes already merged to main or unrelated can you fix this please, it would help with the review |
|
@hugomrdias D'oh! Good catch, not sure why that happened but was definitely not my intent… will clean this up. |
this is one way of resolving issue storacha#344, where a custom server URL is used only for the individual HTTP requests and not for the corresponding WebSocket connection
this also adds additional notes/documentation explaining the situation
nate-dag
force-pushed
the
nvw/fix-wsClientUrl
branch
from
9a738ae to
1fbc254
Compare
|
@hugomrdias Rebased this against current main, so it now shows just the small patch needed. |
|
i created this PR storacha/ucanto#214 in ucanto to avoid the custom types here |
|
IMHO we should just lose the additional types here to get this mergable. We can do something like storacha/ucanto#214 (comment) if we really need to appease typescript. |
|
Ah sweet - I like this approach @alanshaw - will update and get it moving |
travis
added a commit
that referenced
this pull request
Feb 21, 2023
This fixes #344 and makes it possible to connect to staging services with w3ui. This PR obsoletes #404 per @alanshaw's suggestion in #404 (comment) based on reasoning in storacha/ucanto#214 (comment) which points out that some sort of conditional or casting is probably unavoidable here. My solution casts the channel to have an optional `url` field and looks in that field for a URL before falling back to the default `HOST`.
|
closing in favor of #440 |
travis
added a commit
that referenced
this pull request
Feb 21, 2023
This fixes #344 and makes it possible to connect to staging services with w3ui. This PR obsoletes #404 per @alanshaw's suggestion in #404 (comment) based on reasoning in storacha/ucanto#214 (comment) which points out that some sort of conditional or casting is probably unavoidable here. My solution casts the channel to have an optional `url` field and looks in that field for a URL before falling back to the default `HOST`. Have tested this locally with w3ui and verified it makes it possible to connect to staging services from w3ui - huzzah!
gobengo
pushed a commit
that referenced
this pull request
Apr 11, 2023
This fixes #344 and makes it possible to connect to staging services with w3ui. This PR obsoletes #404 per @alanshaw's suggestion in #404 (comment) based on reasoning in storacha/ucanto#214 (comment) which points out that some sort of conditional or casting is probably unavoidable here. My solution casts the channel to have an optional `url` field and looks in that field for a URL before falling back to the default `HOST`. Have tested this locally with w3ui and verified it makes it possible to connect to staging services from w3ui - huzzah!
Peeja
pushed a commit
to storacha/upload-service
that referenced
this pull request
Jan 17, 2025
🤖 I have created a release *beep* *boop* --- ## [4.0.0](storacha/w3ui@vue-uploader-v3.0.1...vue-uploader-v4.0.0) (2023-03-23) ### ⚠ BREAKING CHANGES * use new account model ([storacha#400](storacha/w3ui#400)) ### Features * use new account model ([storacha#400](storacha/w3ui#400)) ([66dd20b](storacha/w3ui@66dd20b)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Travis Vachon <travis@dag.house>
Peeja
pushed a commit
to storacha/upload-service
that referenced
this pull request
Jan 29, 2025
🤖 I have created a release *beep* *boop* --- ## [4.0.0](storacha/w3ui@vue-uploader-v3.0.1...vue-uploader-v4.0.0) (2023-03-23) ### ⚠ BREAKING CHANGES * use new account model ([storacha#400](storacha/w3ui#400)) ### Features * use new account model ([storacha#400](storacha/w3ui#400)) ([b594536](storacha/w3ui@b594536)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Travis Vachon <travis@dag.house>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is imo the cleanest way of resolving issue #344, where a custom server URL is used only for the individual HTTP requests and not for the corresponding WebSocket connection.
It took a while to decide the best place to fix this. For a little while, it seemed like the internals of
createAgent()within@w3ui/keyring-coreneeded to copy out the URL into its the top-level options. But ultimately I believe that would be an incorrect workaround!The root cause is that
@web3-storage/access/agentis pulling some tricks on its own that get it into trouble: instead of theAgentrelying exclusive on itsthis.connectionfor all actual transport, it also cheats and creates its ownnew Websocket(…)on the side!That extra websocket is the only reason the
Agentinstance keeps a copy ofthis.urlat all — everything else goes through the properConnectionView<Service>abstraction. So I believe thew3uicode is fulfilling its side of the interface contract. Since it is theAgentthat bypasses the abstraction, it is responsible to look for the raw URL inside of it.This ends up being a relatively trivial code change, but did require some special (internal) extensions to the type definitions to support.