fix(fullstack): allow the server URL to be set more than once - #5704
Merged
Conversation
`set_server_url` stored into a `OnceLock` and unwrapped the result, so a second call panicked. That makes the base URL a permanent property of the process, which a client that talks to more than one backend cannot work with: the backend has to be chosen before `launch`, since `launch` claims the slot itself when it is still empty, and it can never change afterwards. Store it in an `RwLock` instead so the most recent value wins. `fetch_inner` already reads the URL as each request is built, so a change applies to the next server function call with no restart. `get_server_url` still returns `""` when unset, so `launch`'s "set the devserver default if empty" check is unaffected. This also removes a latent panic in `launch`: the native block (`cfg(any(desktop, mobile, native))`) and the web base-path block both call `set_server_url`, and the second does so unconditionally, so a binary compiled with both feature sets panicked inside the framework whenever `dioxus_cli_config::base_path()` returned `Some`. The neighbouring `REQUEST_HEADERS` is already a `Mutex` with a re-settable `set_request_headers`, so this brings the two client-configuration globals into line.
ealmloff
approved these changes
Jul 26, 2026
ealmloff
left a comment
Member
There was a problem hiding this comment.
This seems reasonable. It lets you build re-exports of specific server functions that set and unset the url for the call. We should probably have an api to map the url for specific re-exports in the long term, but this is a fine workaround for now
Contributor
Author
|
Thanks for the review and merge @ealmloff This is a super cool project. I really appreciate the work you and the team are doing here. |
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
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.
set_server_urlstored the root URL in aOnceLockand unwrapped, so a second call panicked — pinning the base URL for the life of the process. A native client that talks to more than one backend can't work with that.Swaps the
OnceLockfor anRwLock<Option<&'static str>>so the most recent value wins.fetch_inneralready reads the URL per request, so the change applies to the next server-function call with no restart.get_server_urlstill returns""when unset, solaunch's devserver-default check is unaffected. Mirrors the neighbouringREQUEST_HEADERS, already a re-settableMutex.Also removes a latent panic: the native and web base-path blocks in
launchcan compile into one binary and both callset_server_url, the second unconditionally — panicking wheneverbase_path()isSome.Tested:
cargo fmt,check,clippy -D warnings,test --allall pass.