mirror of
https://github.com/clash-verge-rev/clash-verge-rev.git
synced 2026-10-29 10:02:09 +08:00
e790619937b4d161237d699eba1082e68d9c9d30
357
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Tunglies
|
d01f43cc78 | refactor(deps): replace once_cell with std OnceLock and LazyLock (#8136) | ||
|
Tunglies
|
720dc13e96 |
refactor(backend): downgrade lock (#8135)
* refactor(updater): drop write-only pending_* slots * refactor(notify): fold sequence counter into entries lock * refactor(port): fold startup-core-blocked flag into reason slot * refactor(service): drop redundant provider sync serial lock * refactor(port): store startup block reason in a OnceLock * refactor(core): replace macOS network monitor slot with armed latch |
||
|
Tunglies
|
8328e34208 |
refactor(backend): declarative effects (#8128)
* refactor(core): type notice statuses behind the frozen wire contract * refactor(utils): unified retry and strategy-list helpers * refactor(feat): declarative effect registry for verge and clash patches * refactor(core): derive refresh announcements from transaction commit * refactor(core): fold tray, hotkey, autostart updates into effect ensures * refactor(utils): migrate remaining bounded retry loops * docs: add src-tauri architecture guardrails * refactor(core): coalesce burst refresh announcements * refactor(core): complete bounded service retry migration * ci(backend): add architecture ban gates * test(feat): freeze representative effect registry mappings * docs(backend): record dead wire contract entries * chore(core): document watcher exit conditions * fix(backend): preserve applied state across later failures * fix(config): retain runtime after an applied core replacement * refactor(backend): flatten refresh publication and retry policies * docs(backend): focus guardrails on architecture ownership * refactor(effects): use one execution order * fix(config): publish retained runtime and reconcile proxy settings |
||
|
wonfen
|
0c7e0c8535 |
fix(dns): persist DNS override confirmation across restarts
A confirmed override on a profile with provider DNS was turned off at every startup; it now stays on until that profile's provider DNS changes. Refs #7993 |
||
|
wonfen
|
ff1ce92fac |
feat(dns): remember override state per profile
Save the DNS override switch and session confirmation per profile so automatic protection only disables the affected profile. Preserve the legacy switch as the initial preference and show the profile scope beside the settings gear and in the DNS editor. Refs #7993 |
||
|
wonfen
|
3b958acb22 |
fix(config): isolate conflicting provider cache paths
Fixes #7989 |
||
|
wonfen
|
07825afb1e |
Reapply "feat(dns): protect provider DNS from unconfirmed overrides (#7902)"
This reverts commit
|
||
|
Tunglies
|
b469bee352 | fix(logging): include paths in file failure logs | ||
|
Tunglies
|
df79ed3efb |
Revert "feat(dns): protect provider DNS from unconfirmed overrides (#7902)"
This reverts commit
|
||
|
wonfen
|
ed0e1b38f0 | feat(proxy): support dragging to swap proxy group header sections | ||
|
Tunglies
|
8812923eda |
perf(enhance): cut fixed config-generation cost
Every settings toggle reparsed the profile and chain files, ran four Boa interpreters, serialized the runtime config twice, and re-ran mihomo -t over bytes the core had just accepted. Builtin and template scripts now run without Boa, custom scripts bind the config through JSON.parse and take ownership instead of per-script clones, the config serializes once, and mihomo -t is skipped unless the bytes, core build, or geo assets changed. Heavy parses and serializations moved to spawn_blocking. Large-subscription toggles drop from hundreds of milliseconds to ~140ms with no new retained state. |
||
|
wonfen
|
35a2b6c75c |
feat(dns): protect provider DNS from unconfirmed overrides (#7902)
Fixes #7292 |
||
|
Tunglies
|
2f370d6490 |
refactor(log): in-place writer lifecycle and span-based core observability (#7889)
* refactor(log): migrate logging to tracing-estuary pipeline Swap flexi_logger + clash-verge-logger wiring for the tracing-estuary crate: buffered file sink with explicit panic/exit drains, live level switching, and tokio-trace/chrome-trace behind crate features. AsyncLogger moves in-house (VecDeque ring); file format and rotation stay unchanged. * fix(log): reset sidecar writer in place and re-pin service-ipc v2.6.7 Rebuilding the sidecar FileLogWriter on config changes leaked flexi's unstoppable flusher thread plus an fd each time; the writer is now flushed and reset in place, matching what the service crate does. get_clash_logs_by_service drops the CompactString conversion layer now that service-ipc v2.6.7 returns plain Vec<String>, and AsyncLogger is renamed LogRing to match. * refactor(log): span-based observability and log noise cleanup Instrument spans carry the structure flat lines never could: the core-start spine (mode, readiness/owner generations, pid, config file), proxy apply and clear routes with guard generations, service IPC sessions with refusal codes and outcomes, profile-switch terminal outcomes, subscription fetch strategies, core upgrades with per-proxy version probes, backup flows, timer tasks, config generation uids, and the startup setup flow; running-mode changes emit one guarded transition event each. ~90 hand-written noise lines are gone or demoted (entry+success pairs, polled getter echoes, phase brackets, window sub-steps, platform install chatter); errors keep their anyhow chain, operation name, and item id, and swallowed retry results surface per attempt. |
||
|
wonfen
|
e60285b4ae |
fix(tun): make the TUN switch reflect what the Core actually runs
The switch read enable_tun_mode while the Core was given enable_tun_mode && !session_suppression, so falling back to Sidecar left it showing a TUN that was not running, with nothing to write the flag back. Drop the session flag: the stored preference is the only truth, re-checked at startup and written off when the conditions for it are not met, and the switch renders it against current capability. |
||
|
Tunglies
|
44f6f6e19b | fix(profile): preserve files until explicit deletion | ||
|
Tunglies
|
695fadf21e |
fix(security): restrict external URL opening
Close: 7800 |
||
|
Tunglies
|
b7c4f7d39b |
refactor: api cleanup (#7812)
* refactor(config): unify YAML persistence * refactor(config): remove redundant config APIs * refactor(config): remove unused config APIs * refactor(config): narrow profile APIs * fix(config): preserve profiles on invalid reorder * refactor(startup): narrow resolve helpers * refactor(config): unify mixed port defaults * refactor(network): simplify response APIs * refactor(config): make profile builders infallible * refactor(config): make profile activation infallible * refactor(api): simplify internal runtime APIs * refactor: consolidate internal config and window APIs |
||
|
wonfen
|
e15ddab542 | test: trim redundant test coverage | ||
|
wonfen
|
807f9a206d | chore: trim excessive comments | ||
|
oomeow
|
daadb126e0 |
feat: allow manually unfixing proxy nodes (#7756)
* feat(proxy): add ability to clear persisted node selection for groups * feat(hooks): make proxy selection operations asynchronous * chore: update tauri-plugin-mihomo deps * refactor: rename clear_selected_node to forget_selected_node * refactor(hooks): rename isFixed to isFixedProxy in useProxySelection * docs: update changelog with manual node cancellation support * chore(layout): remove dev-only mihomo websocket debugging interval |
||
|
wonfen
|
747a68ef2f |
fix(port): stop the mixed port climbing on every restart
The startup fallback persisted its replacement, so a port blocked once was never asked for again. It now overrides the Runtime Config for the session only. Most of those conflicts were not real: SO_REUSEADDR cannot reuse a TIME_WAIT socket owned by another user, and a service-managed core runs as root while the app does not. A refused bind is now confirmed by asking whether anything answers. Also restores the borrowed port when saving proxy ports fails. |
||
|
wonfen
|
906ec5e63a | fix: serialize concurrent configuration updates | ||
|
wonfen
|
ec6241b30a |
feat(profile): raise auto-update intervals below 24h
Each auto-update reloads the core, which drops every connection running through a `proxy-providers` entry. Existing profiles are corrected once at startup; the form warns about shorter intervals but still saves them. |
||
|
StarsSailandwonfen
|
df7e52f25c |
fix: remove unnecessary allow_auto_update default value (#7697)
* fix: remove unnecessary allow_auto_update default value * fix: normalize missing profile auto-update state --------- Co-authored-by: wonfen <eiwonfen@gmail.com> |
||
|
Tunglies
|
c5b641e421 | fix: make profile deletion rollback-safe | ||
|
|
ef179fcf61 |
fix(home): manual update check not working when auto_check_update disabled (#7585)
* fix(config): prevent cleanup_orphaned_files from deleting active profiles When IProfiles::new() fails to parse profiles.yaml (e.g., corrupt file), it returns Self::default() with items: None. The subsequent cleanup_orphaned_files() call then sees no active files and deletes all profile files in the profiles/ directory except the two hardcoded protected files (Merge.yaml and Script.js). Guard cleanup_orphaned_files() against this by checking if items is None or empty before proceeding. When items is unavailable, skip the cleanup and log a warning instead of blindly deleting user data. Fixes #7577 * fix(home): manual update check not working when auto_check_update disabled When auto_check_update is false, useUpdate() sets enabled=false for the SWR query, which sets the SWR key to null. Calling swr.mutate() on a null key does not execute the queryFn, returning undefined instead. This caused the home page's "last check time" click to instantly show "already up to date" without actually checking for updates. Fix: use revalidateQuery() for the manual checkUpdate function, which uses the global SWR mutate with the actual query key, bypassing the enabled: false state and always triggering a real network request. Fixes #7584 * fix: preserve manual update and profile data --------- Co-authored-by: Evan Gong <evan@users.noreply.github.com> Co-authored-by: wonfen <96291150+wonfen@users.noreply.github.com> Co-authored-by: wonfen <eiwonfen@gmail.com> |
||
|
wonfen
|
3d8d7731e1 |
fix: node selection persistence (#7620)
* fix(core): put the user's node choices back when the core starts mihomo restores the node picked in each group from the `cache.db` it keeps in the directory it was started against. The app relied on that entirely, and it does not hold: `profile.store-selected` comes from a merge template a user is free to replace, and a service older than the durable runtime generation starts every core in a directory nothing has ever run in. Both end the same way — every `select` group falls back to the first entry in its `proxies:` list. The app already knows better. It records each selection in the profile, and `activate_selected_nodes` already reconciles that record against the running core — it was only ever called when switching profiles, never when a core came up. Call it from the three places a core process becomes ready. Repeat calls supersede each other, so no coordination is needed between the start paths. That makes the profile authoritative, which turns any selection it does not know about into one the next start silently undoes. The chain proxy moved a group without recording it, so recording is now one shared hook that both it and the proxy list go through. Restoration is spawned, not awaited: it polls the core until its groups are readable, and a start must not wait for that. * fix(tray): record the node the tray switched to Restoring the profile's selections when a core starts made the profile authoritative, which turns any selection it never learned about into one the next start silently undoes. The proxy list and the chain proxy both record; the tray did not. So switching node from the tray survived only until the next restart, and then reverted to whatever the profile last knew — a regression the restoration itself introduced, and only for the tray. `record_selected_node` is the backend counterpart of the frontend's `useRecordSelection`. Failing to record does not fail the switch: the core is already on the new node by then, and reporting the switch as failed would be wrong. It is logged instead. * fix(core): restoring selections must not prune what the core has not loaded Putting the profile's selections back when a core starts reused the reconciliation written for profile switches, and that one also *repairs*: a record whose group is absent from two snapshots a second apart is dropped, and the reduced list is written to profiles.yaml. After a profile switch the configuration is loaded, so absence is evidence. After a core start it is not — a provider-backed group can be empty or missing for seconds — and a record pruned on that evidence is gone for good, because the provider finishing later cannot bring it back. Restoring now keeps the records and only applies what it can match; pruning stays with the caller entitled to conclude it. The restore is also asynchronous: it reads the profile, polls the core until its groups are readable, then puts its selections. A choice the user makes inside that window is newer than what it captured, so letting it finish pushed the core back to the older node while the profile already held the newer one. Recording a selection now supersedes any activation in flight — from the tray, and from the UI and chain proxy through `patch_profile`. * fix(core): activate the selections of the profile that is actually running The activation worker read the profiles draft. A profile switch stages its target there before validating it, so a switch that fails — leaving the previous profile running — could still have handed an activation the rejected profile's selections, which it would then apply to whichever same-named groups the running profile has. Reading the committed state removes the window. The switch that succeeds commits before it activates, so nothing changes for that caller; what changes is that a restore running at core start can no longer observe a switch that never happened. * fix(core): stop a restoration from undoing a choice made while it runs Two gaps in making the profile authoritative, both found by adversarial review of the commits that introduced it. A restoration reads the profile's selections once, then polls the core until its groups can be read — seconds, on a cold start. A selection made inside that window is newer than what the restoration is carrying, and nothing told the restoration so: it went on to apply the older choice over the user's. The UI accepted the new node and traffic snapped back to the old one, with the profile and the running core then disagreeing. Recording a selection now abandons any restoration still in flight, through the same generation counter every other superseding caller uses. The other gap is the home card in global mode, which passed `skipConfigSave` and so recorded nothing. That was harmless while nothing re-applied the profile; now it means the next start undoes the choice. It was the only caller that ever set the flag, so the flag is gone rather than flipped — a parameter whose one use was a bug is not worth keeping. * fix(core): wait for the selections that can be put back, keep trying for the rest Two gaps in restoring the profile's selections when a core starts, both found by adversarial review. Restoring re-checked once, a second later, and stopped. That is enough after a profile switch, which happens with the configuration already loaded. A core start is the opposite case: a provider-backed group is present but empty until its provider finishes loading, and a `select` can fail while the core is still settling. Neither produces an activation, so the restore reported success having applied nothing and the group stayed on the first entry of its `proxies:` list — the outcome restoring exists to prevent. It now keeps looking, on a deadline, at what the core is actually on rather than at what it managed to send. Restoring was also spawned, and the caller enables the system proxy the moment the start returns — so traffic could be pointed at a core still on the wrong node. The first pass is now awaited, bounded, and the rest keeps settling in the background: a core that will not answer delays a start rather than blocking it, because being proxied through the wrong node beats not being proxied at all. TUN is deliberately not covered, and cannot be by anything here: it is configured in the core's own file, so it carries traffic from the moment the process starts. What puts a TUN user on the right node from the first packet is the core's own `cache.db`, which is why the service keeps an owner's runtime generation across restarts. `supersede_selected_activation` and `cancel_selected_node_activation` were the same function under two names, added independently for the same reason, and `patch_profile` called both. One survives, called once, after the profile is written — the only placement that needs to exist, since an activation that read the older profile is cancelled by it and one starting afterwards reads the newer one. * fix(core): record a selection by naming it, not by resending the list Recording a node selection sent the whole selection list, built from the profile the frontend had rendered. Two selections made before that list refreshed were therefore built from the same stale snapshot, and the later write dropped the earlier group's choice. Since a core start re-applies whatever the profile holds, the dropped one came back on the next restart — the profile and the running core disagreeing, in the direction the user would least expect. The tray already avoided this, because it went through `record_selected_node`, which merges one group into the profile inside `with_data_modify`. Exposing that as a command and pointing the frontend at it leaves one way to record a selection instead of two, and removes the list from the wire: what a caller knows is the group and the node, and that is now all it says. `useRecordSelection` no longer reads the profile at all, which also makes it stable across renders rather than changing identity whenever the profile does. * test(core): make every way of declining to stage answer for itself `CoreRestarted` was added to `StageRejection` upstream and reached production without a test. It inherited the right verdict — every `RestartRequired` is matched together — but nothing said so, and nothing would have noticed if it had inherited the wrong one. The list of rejections now goes through a wrapper whose `match` is exhaustive, so the next variant added upstream fails to compile here. That is the part worth having: it does not prove the list is complete, but it does mean nobody can add a way to decline without being sent to this test to say what it should lead to. * build(deps): pin the service protocol to v2.6.1 The pin tracked `feat/stage-runtime` because the protocol change it carried had no tag yet. It has one now, and a branch pin makes the build irreproducible: an upstream force-push silently changes what this compiles against. v2.6.1 carries the runtime generation an owner keeps across restarts, which is what lets the core hold on to the `cache.db` its node selections and fake-ip leases live in. The protocol itself is untouched — epoch, revision and both compatibility floors are byte-identical to v2.6.0 — so this is a fix release in both directions: an older service still works with this app, and this app still works with an older service, only without the durable generation. The lockfile change is the two lines that name it. Reaching for `cargo update -p` instead re-resolved a subtree and quietly downgraded `windows-sys`, `windows-core` and `getrandom` along the way. |
||
|
wonfen
|
cefcb150c9 |
fix: core runstate review/improve (#7617)
* fix(core): reopen PAC when a start attempt never happens `save_proxy_ports` closes the PAC endpoint before it stages a candidate, because the endpoint resolves the Mixed Port through the draft layer and would otherwise answer with a port nothing is listening on. Most ways out of that function are a rejection, though: the candidate is refused and the Core keeps serving on its old ports, having never been stopped. PAC is re-derived only when the Running Mode changes, and that is exactly what did not happen — so the endpoint stayed shut for the rest of the session, and every browser on PAC silently went direct. Give `core_starting` the counterpart it was missing. `core_start_settled` re-derives PAC from the Running Mode rather than restoring a saved flag, which makes it correct on all three endings — a start that succeeded, one that was abandoned, one that failed and left the Core down — and therefore safe to run from a guard on every path. * fix(config): refuse overlapping draft transactions instead of losing an edit A layer holds exactly one draft, so a second writer's `edit_draft` overwrites the first writer's staged value in place. `DraftTransaction` nonetheless rolled back by calling `discard` on the shared layer, which discarded whatever was staged there — including a change another transaction was about to commit. The other transaction then found no draft, and `apply` on an absent draft does nothing at all. It saved the committed value, returned Ok, and its side effect had already happened: auto-launch registered with the OS while the config that describes it says otherwise, and no log line either way. "Roll back only my edit" cannot be implemented over a single slot, so enforce the exclusivity the type already assumed. Beginning a transaction claims every layer and refuses rather than interleaving, which is the same shape as `try_start_config_update` and `begin_operation` elsewhere. `patch_verge` is the caller that matters: it holds its draft across `process_terminated_flags`, which restarts the Core and can take seconds. The TUN reconciliation runs on every Run State transition and can now lose that race, so it treats a busy layer as "later" rather than as a failure worth telling the user about. * fix(core): reconcile TUN availability when the setting itself changes Moving the TUN availability guard from the frontend into Rust also moved what triggers it. The old effect depended on `enable_tun_mode`; the new reconciliation is spawned from `RealEnv::publish`, so it only runs on a Run State transition. Those two sets are not the same, and the setting itself falls in the gap. Switching TUN on from the global hotkey is the case that reaches it. That path is not gated on availability — unlike the tray item and the settings switch, both of which read `tun_capable` — and the flags a TUN patch raises are answered by a Core reload, which changes no Run State at all. So on a machine with no Service and no elevation the setting stayed on: tray icon, settings switch and `enable_tun_mode` in verge.yaml all reported TUN as enabled while nothing carried its traffic, until some unrelated core lifecycle transition happened to reconcile it. Reconcile after any patch that touched the setting. The reconciliation writes configuration itself, so it goes through the plain apply rather than back through the patch-and-reconcile form; the absence of a cycle is then a property of the call graph rather than of a runtime early-return. `toggle_tun_mode` now reads the setting back instead of returning what it asked for, so the hotkey cannot report TUN as on moments before the notice saying it was turned off. * fix(core): an action already under way is not a decision to put to the user The legacy status could not distinguish a requested privileged operation from one already running, because readers blocked until the operation finished and so never observed the request at all. Run State pushes every transition instead, and `service_needs_attention` treated any pending action as a question for the user. So an install started from the settings page or the home card raised the migration dialog on top of it, and an uninstall raised one offering to reinstall the Service being removed. Both offer a button that can only fail, since the privileged-operation slot is already taken. An operation in flight is a report of progress. The dialog the user is already driving keeps itself open through its own loading state. `tun_should_be_disabled` is unaffected: it already refused to act while an operation was in flight, so the term this adds is redundant there. * fix(core): let the snapshot decide whether the Run State has settled `settled` read the operation slot twice: once to decide whether to wait, then again inside the snapshot it returned. An operation claiming the slot between those two reads was described rather than waited for. `prepare_startup` reads this. A start racing an install would see the requested install, flatten it to `InstallRequired`, and decide `Wait` — leaving the core stopped where waiting for the install to finish would have told it whether the Service came back. Read the slot once, inside the snapshot, so there is no window rather than a second check closing it. The rewrite that introduced this also fixed a lost wakeup here, and that fix stands: the waiter is still registered before the state is read. * fix(ui): re-read the Run State once its listener is live Replacing the poll with a push left a gap. `listen` resolves asynchronously, so between the first `get_runtime_state` and the subscription being registered there is a window, and a transition landing in it is not queued anywhere — it is simply missed. The next event is whenever the backend happens to move again, which during startup can be a long time; the 30-second safety net was all that stood behind it, where the old code polled every two seconds precisely through startup. The Run State is the one thing here that arrives only by event, so it is the one thing a missed event leaves stale. Re-read it once every listener is live, which closes the gap without going back to polling for it. `onSubscribed` fires even when a registration failed, because a resync is most needed when a subscription is missing, and not at all after teardown. * docs(config): state what makes the PAC endpoint's draft read safe `MixedPort::desired` reads the draft layer, so the PAC endpoint can name a port the Core has not moved to yet. That is only safe because the one path staging a listener port closes PAC across the change. Nothing said so at either end, and the two are in different modules. * fix(core): ask again when staging goes silent rather than assume it failed The Service commits the generation before it answers, so a reply that never arrives is not evidence that nothing was written: config.yaml can already hold the new configuration while this side concludes the staging never happened. The Core keeps running the previous configuration, so nothing looks wrong -- until the Core dies and the Service's watchdog restarts it in the same generation from whatever config.yaml says, quietly making live a configuration the app reported as failed. Silence is the one answer that has to be resolved rather than acted on, so ask once more before falling back. It is cheap exactly where it matters: staging plans against the manifest it wrote, so a bundle that already landed copies nothing and answers in milliseconds, and the Service's lifecycle lock makes a second ask wait for a first one still in flight instead of interleaving with it. A deadline keeps that wait off the caller, and a second silence goes where the first one used to. |
||
|
oomeow
|
b71a1e4ec5 |
refactor: mihomo ipc (#7601)
* refactor: mihomo ipc request * refactor: remove redundant write locks and await on mihomo handle * fix(rule): handle non-string types in ProviderButton labels * refactor: handle non-string value types in RuleItem component * refactor(tauri): remove unnecessary await in get_base_config call * chore: update tauri-plugin-mihomo deps * refactor: rename ConnectionId to WsConnectionId * chore: update tauri-plugin-mihomo-api dependency reference * chore(config): use Proxy::default in profile test initialization |
||
|
wonfen
|
c90de1355e |
refactor: core runstate (#7602)
* refactor(core): introduce core::runstate as the owner of Run State
"Is the Service available?" had five caches and three predicates, and
prepare_startup consulted all three within thirty lines. This lands the
foundation for collapsing that, with no behaviour change: the old owners
now delegate into one store.
The state model splits observation from intent. Five of ServiceStatus's
ten variants were never observations — cmd/service.rs passed
ServiceStatus::InstallRequired as the "which operation do you want"
argument — which is why narrowing to ServiceInstallState had to be lossy.
ServiceHealth now records what we saw, PendingAction records what the
session asked for, and ServiceStatus::from_run_state flattens the pair
for call sites that still expect the single slot.
Reads differ only in freshness: state() is cached, settled() waits for an
in-flight privileged operation, probe() forces IPC. What an answer means
lives on the snapshot (service_usable, tun_capable), so callers stop
writing their own formulas — the tray now asks tun_capable() instead of
recomputing "admin or ready".
Effects sit behind RunStateEnv with two adapters, RealEnv and FakeEnv.
That retires the seven tests that hand-built a private ServiceManager
struct literal, and makes the probe and detection paths testable for the
first time.
Two distinctions are now explicit rather than incidental:
- A single failed probe is not an observation and leaves confirmed
health intact; exhausting a poll's whole retry budget is one and
records unavailable. Both are tested, protecting
|
||
|
wonfen
|
7796259b03 |
feat: automatic mixed port fallback (#7579)
* feat: automatically select an available mixed proxy port * fix: coordinate listener port changes * fix: detect Windows listener port conflicts |
||
|
wonfen
|
23dda47641 |
feat: add launch guard and secure multi-user service ownership (#7569)
* feat(service): isolate macOS launch and owner runtime * ci(windows): run owner security tests * chore(deps): use kode-bridge v0.4.1 tag * fix(macos): classify installed service state * fix(macos): classify marked unavailable service * fix(macos): gate core startup on service migration * fix(macos): scope service init to supported platforms * feat(macos): prompt before migrating installed service * fix(macos): shorten sidecar IPC path * build(service): pin helper protocol and artifacts * fix(core): require confirmed service and sidecar readiness * fix(macos): harden launch roots and singleton state * fix(ui): refresh migration state before restart * fix(macos): linearize service migration lifecycle * fix(ui): keep service migration state fresh * feat(service): track authenticated owner sessions * fix(service): preserve newer owner sessions * feat(macos): route service proxy changes through helper * fix(macos): serialize service proxy guard * fix(macos): close service proxy owner lifecycle * fix(macos): close remaining proxy stop races * fix(app): do not cancel controlled service stop * fix(lifecycle): keep controlled updates cancellation-safe * fix(macos): stage dev core for service * test(macos): exercise staged core cleanup * fix(dev): await controlled macOS exit * chore: update changelog * fix(macos): recover sidecar after service install failure Allow the existing sidecar to continue when service installation leaves the manager in InstallRequired, then settle the session state as SidecarAllowed. Show neutral status text while the migration dialog waits for its final state. * fix(macos): stage dev service tools before elevation * fix(macos): localize launch guard prompts * fix(service): address cross-platform integration issues * feat: support seamless service migration * fix: pass Windows service installer path safely * fix(prebuild): derive service release from Cargo dependency * fix(dev): preserve service installation state * fix: resolve clippy warnings in service lifecycle |
||
|
oomeow
|
ccf21f4a31 | fix(config): apply runtime configuration on initialization (#7562) | ||
|
wonfen
|
50d828d0d7 | fix(profile): handle missing chain files without breaking rollback | ||
|
wonfen
|
4b04d035b6 | fix(profile): schedule imported profiles for auto-update | ||
|
Tunglies
|
d327a435ff | fix(profile): validate profile file names | ||
|
wonfen
|
d144e78aeb | perf: streamline profile switching | ||
|
wonfen
|
cd20bdb6a1 | fix: safely restore selected proxy nodes | ||
|
|
8bf5fc1aca |
chore(deps): update cargo dependencies (#7377)
* chore(deps): update cargo dependencies * fix aes feature * fix: update aes-gcm nonce conversion * refactor: use aes-gcm key init api --------- Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: Tunglies <77394545+Tunglies@users.noreply.github.com> |
||
|
oomeow
|
c2ddb5c111 |
refactor: activate selected proxies (#7285)
* feat(profiles): add automatic node activation after profile switch * refactor(use-profiles): simplify patchCurrent logic by always mutating profiles * refactor(use-profiles): remove unused activateSelected function and related imports * refactor: rename worker handle to activate selected task * fix: clippy * refactor(config): replace log statements with structured logging * refactor(config): fix incorrect retry logic in profile activation * feat(profiles): update proxy cache when switching profiles * docs: update changelog with bug fixes and logic improvements * refactor(profiles): remove unused imports and redundant cache update |
||
|
Tunglies
|
2a5d29cdb2 | fix: defer runtime config init until after window | ||
|
wonfen
|
294955cb8c | feat: add fake-ip-range6 | ||
|
wonfen
|
d0d2f4e4f5 |
fix: read clash mode tolerantly and propagate mode-switch failures
The home mode card read the proxy mode only from mihomo's /configs (strict BaseConfig); when that response drifted a single field, the whole read failed and the card showed a bare "communication error". patch_clash_mode also swallowed backend PATCH failures and always returned Ok, so the UI could not tell a switch had actually failed. - add a tolerant get_clash_mode command that reads mode from the saved clash config (IClashTemp::get_mode), bypassing strict BaseConfig deserialization, and - make change_clash_mode return Result and have patch_clash_mode propagate it; the hotkey/tray callers log-and-ignore as before. |
||
|
Tunglies
|
35c534ae1c | refactor: lazylock for profile regex | ||
|
Tunglies
|
fa27d3eae5 |
Revert "feat(cvd): add device-bound subscription protocol"
This reverts commit
|
||
|
wonfen
|
2cb9c13ab6 | feat(cvd): add device-bound subscription protocol | ||
|
Tunglies
|
761209bbbc |
refactor: backend (#7102)
* refactor(tray): move tray log opening to utils helper * refactor(enhance): move owned config through pipeline * refactor(enhance): move sequence values in use_seq * refactor(enhance): move values while sorting fields * refactor(enhance): move values when lowercasing owned config * refactor(backend): move owned config values in utilities * refactor(tray): borrow hotkey accelerators * refactor(core): borrow proxy config strings * fix(backend): preserve config patch semantics * refactor(enhance): clarify config transform names |
||
|
Tunglies
|
ec9ef0f85e | fix: report legacy TLS subscription failures | ||
|
Tunglies
|
8efbf9e7fd | fix: clippy errors for rust 1.97 | ||
|
Tunglies
|
edf5246e7f | fix: mask subscription URLs in backend logs |