71 Commits

Include renames

Author	SHA1	Message	Date
Tunglies	d01f43cc78	refactor(deps): replace once_cell with std OnceLock and LazyLock (#8136)	2026-10-07 07:38:56 +00:00
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	2026-10-07 07:38:55 +00:00
wonfen	4a0882fc18	fix(singleton): repair Windows lock file permissions in place	2026-10-03 15:59:39 +08:00
wonfen	d87bb7b6a3	fix(singleton): acknowledge window restoration before UI work ... Dispatch blocking window restoration outside HTTP workers to prevent notification timeouts and repeated window activation in #8118. Remove the misleading failure log, update the changelog, and remove server tests as requested.	2026-10-03 10:56:41 +08:00
Tunglies	bf6f43f15b	fix(singleton): let a restart-spawned child take over the instance lock ... The secondary wait only polled the notify endpoint, which a restarting instance has already shut down before spawning its successor, so a child that lost the spawn-vs-exit race could never acquire the freed lock and died after 20s behind a startup-failure dialog. Retry try_lock_instance on every poll so the child promotes as soon as the old process exits. Double-launch handoff and wedged-holder timeout behavior are unchanged.	2026-09-10 09:09:14 +08:00
wonfen	632c5b2bc5	fix(windows): repair a data root owned by another account	2026-08-30 11:45:04 +08:00
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	2026-08-25 07:19:17 +00:00
wonfen	4869e362e3	fix: report fatal singleton startup errors	2026-08-17 07:18:34 +08:00
Tunglies	c5b641e421	fix: make profile deletion rollback-safe	2026-08-03 20:00:01 +08:00
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.	2026-07-29 03:58:47 +08:00
Tunglies	912f93fe85	fix: resolve default-feature clippy errors	2026-07-28 02:45:14 +08:00
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 389c5342. - Platform evidence that cannot be inspected is unavailable, not absent, so we never offer to install a Service that is already there. RealEnv::is_elevated reads APP_HANDLE without expect(), so reading Run State before the app handle exists degrades to "not elevated" instead of aborting. Tests: 180 -> 218. One test was removed; its assertions moved into runstate::probe. * refactor(core): derive PAC and the core-mode mirror from Run State Running Mode had twelve write sites, PAC availability ten, and the frontend mode mirror seven — all three kept in step by convention, each pairing written out by hand next to the others. Nothing checked the pairing, so a new call site could set a mode and leave PAC serving a script for a proxy port nothing was listening on. Callers now state what happened rather than what to store: core_started(Sidecar|Service) the Core is running and serving core_stopped() the Core is not running core_starting() a start attempt is under way PAC availability and the mode mirror are derived from those transitions inside the store and nowhere else, so they cannot drift. set_mode is private; after_core_process is deleted along with all seven of its calls. Ordering is fail-closed in both directions: PAC closes before the mode changes and opens after it, so a reader that catches a transition mid-flight is refused rather than handed a stale script. core_starting exists for exactly that window during a handover, where the Core being replaced is still the one that holds the mode. Both effects sit behind RunStateEnv, so FakeEnv records them instead of touching process globals, and the derivation is asserted directly. RealEnv publishes the mirror without expect(), so a Core that stops before the app handle exists no longer risks an abort. utils::server's fail-closed test now asserts the default rather than the live flag: PAC follows the Running Mode, so any test driving a Core transition legitimately moves it. The invariant that PAC can never disagree with the mode is asserted in core::runstate instead, where the environment is a fake. Tests: 218 -> 223. * refactor(core): absorb the service wait and owner monitor into Run State Four loops asked the same question — is the Service there? — with four retry policies, and the one that mattered most was the least examined: 112 lines of owner monitor with three copy-pasted counter blocks and no tests, where a missed reset silently changes when the app tears down a working proxy. The readiness wait becomes one interface. Its two callers wanted different things from a failed wait, and the old code expressed that implicitly in whether a poll returned Ok — a poll returned Ok for a readable-but-incompatible reply, which is why one caller recorded "unavailable" and the other did not. ReadyWaitError now says which happened: silence is the caller's to interpret, a rejected reply already recorded its own verdict and must not be flattened into a vaguer one. Retrying is likewise only for silence; twenty retries of a known-bad version would just delay telling the user to reinstall. The owner monitor's decision moves to core::runstate::owner as a state machine over samples. A transport error, an error code and an empty payload were three near-identical blocks; they are one Unreadable sample now, because they mean the same thing: we learned nothing. The two counters are separate and independent — silence says nothing about the Core's PID — and VerifyTransport keeps the rule that a Service we cannot reach while the Core still answers is a broken status channel, not a lost Core. 15 tests, where there were none. Privileged operations run through the environment, so the state around them is testable: a refused uninstall leaves the Service untrusted rather than absent, and a refused install does not claim it is gone. That also retires PrivilegedServiceAction, which duplicated PendingAction — apply_service_status now reads back the one mapping set_status already performed instead of re-deriving it. Fixes a test-isolation regression from the first stage: moving Running Mode out of CoreManager's per-instance State made three tests share one process-wide mode, which flaked once during this work. CoreManager now holds a reference to its Run State, so a test can supervise a Core without racing every other test. Tests: 223 -> 241, verified stable over repeated runs. * test(frontend): wire vitest and revive the orphaned proxy-view tests There was no frontend test runner, and tests/proxy-view.test.mjs — 421 lines covering the proxy view's identity and rebinding rules — was referenced by no script and no workflow. Unsurprisingly it had rotted: three of its ten tests called functions that no longer exist. vitest runs it now, and CI runs vitest. The file keeps node:assert/strict so every surviving assertion means exactly what it did before; only the harness import changed. Of the three broken tests, one was salvageable: rebindNode is still live and the deleted toNodeBinding was just { name, source }, so inlining it restores the test unchanged. The other two covered findGroup and selectRuntimeStandaloneNodes, which are gone; they are deleted rather than guessed at. If the behaviour they described still exists under another name, it is currently uncovered. The revived file is deliberately *not* type-checked. It was written as untyped .mjs — widened literals, runtime asserts that do not narrow — and retyping it would mean rewriting assertions I am trying to preserve. It is registered with ESLint's default project instead. New tests belong under src/**/*.test.ts, which tsconfig already covers, so they get full type checking from the start; untyped tests are how this one rotted. Only vitest is added. Testing-library comes with the first hook test that needs it, so knip does not flag an unused dependency in between. * refactor(core): one Run State snapshot across the IPC seam Three commands described one fact — running mode, service install state, elevation — under three query keys with three refresh intervals, and the frontend kept them coherent by writing two caches by hand after every service action. get_runtime_state replaces all of it with one snapshot under one key. The snapshot carries the derived answers, not just the fields: tunCapable, serviceUsable and serviceNeedsAttention are computed in Rust and travel with it. That is the point — "TUN can work" had three definitions across the tray, the startup path and a React hook, and the migration dialog decoded an enum ladder to decide whether to open. Transitions are pushed. Every Run State change emits verge://run-state-changed carrying the new snapshot, which the frontend writes straight into the cache instead of refetching. Polling drops from 2s-during-startup to a 30s safety net, and the startup grace period goes away: the service reports 'unknown' until it has actually been probed, so the guard no longer has to wait out a fixed 10s to know whether to trust the answer. ServiceInstallState is deleted along with the lossy install_state() narrowing that motivated splitting observation from intent in the first place. So is the isAdmin wrapper — elevation is part of the snapshot now. app_core_mode is deliberately kept: it is not a redundant mirror, it feeds export_diagnostic_info's "Running Mode" line. The publish effect now carries the whole snapshot and updates both it and the frontend, so the two cannot disagree. Rust tests 241 -> 249, covering the derived answers and that every change — health, pending action, mode, and both edges of an in-flight operation — is announced exactly once. * refactor(core): decide TUN availability where the knowledge is Turning TUN off when it stops being possible was a React effect: six conditions, a ten-second startup grace period, a one-second cooldown ref and a triple-negative predicate, guarding a write to the user's config file — and none of it covered by a test, because until now the frontend had no way to run one. The grace period and the cooldown were both approximations of things the backend actually knows. "Has the service been probed yet" is now ServiceHealth::Unknown rather than a ten-second guess, and "is a disable already being written" is a flag rather than a timer. RunState::tun_should_be_disabled is the decision and is pure, so the cases that must *not* trigger a write are pinned: an unprobed service, an operation in flight, and a decision still sitting in front of the user all mean not-yet-known. Writing the config is a separate concern in feat::tun, because Run State owns state and not actions. Behaviour is unchanged from the user's side: TUN is still switched off in verge.yaml, with the same two notices, which now travel over the existing notice channel as tun_mode::auto_disabled. Worth knowing for review: this puts a config write on the Run State transition path, and patch_verge's bitflag mapping has no tests of its own. The write is guarded against the cascade it can trigger — patching the config produces further transitions, each of which reconciles again — and is spawned so a transition never waits on it. One of the new tests caught a wrong assertion I had written: a ready service mid-operation looked like "cannot work" but is really "not yet known". That is the exact class of bug the fixed grace period was papering over. Rust tests 249 -> 256. * refactor(config): name the two questions asked of the Mixed Port Six call sites hand-copied "the user's selection, else the Merge Config" and the frontend hand-copied a different chain that prefers what the Core reports. Reading them as one duplicated rule is what made this look like a straightforward dedup; they are actually two questions. What have we configured? — needed by anything that writes config or decides what to start, and answerable before the Core exists. What is the Core serving on? — needed by anything pointing a client at the proxy, because a startup fallback or a hand-edited Core config moves the port. MixedPort::desired and MixedPort::effective say which is which, and each call site now picks one on purpose. Two defects fall out of naming them. feat::proxy built the proxy command the user pastes into a shell from verge-or-a-hardcoded-7897, ignoring the Merge Config entirely — it wanted effective(). And the six chains split three-to-three between reading the committed and the draft config layer, with feat::clash reading one of each, so mid-edit they disagreed; there is one layer now. effective() costs a round-trip, so it is used where a user triggered the work, not on paths served per request. PAC stays on desired(): it answers per browser request, and it is closed while the Core is between ports anyway. Each site says which it chose and why. The reserved-ports list in the startup fallback was a second hardcoded listener table. It is derived from the first now, filtered to exclude the Mixed Port itself — which is not a duplicate but a deliberate omission, so it is stated as one rather than left implicit in a literal. On the frontend the same four-source merge was computed twice, once in a hook and once inline in the provider. The provider was mounting two queries solely to recompute what the hook already had; both are gone. Rust tests 256 -> 262. * refactor(config): make a config change roll back by itself Editing configuration meant pairing every edit_draft with an apply or a discard on every exit path, by hand, across three independently committed layers. The startup port fallback wrote the same three-line rollback five times, save_proxy_ports called its rollback helper from eight branches, and apply_config's nested match tree had six discards and three applies. Nothing checked the pairing: a new early return that forgot one left the app describing a configuration it was not in. DraftTransaction commits a set of layers together and rolls them back when dropped, so an early return — a ?, a bail!, a panic — cannot leave a change half-applied. Committing is the explicit act, deliberately: forgetting to commit costs a retry, forgetting to roll back corrupts state. The three call sites lose their hand-written rollback and gain ordinary control flow. apply_config stops touching drafts entirely; whether the staged Runtime Config survives now follows from whether applying it worked, which is the caller's transaction to decide, and its nested matches flatten out. Two rollbacks stay explicit and are commented as to why. Files on disk and a restarted core are not part of the transaction, so those paths still restore snapshots themselves; and rollback_proxy_ports has to clear the drafts *before* it regenerates files from the committed config, which is earlier than drop would. Draft discards drop from 14 sites to 8, applies from 18 to 15. The crate gains 4 tests, including that an early return rolls back without the caller saying so. * refactor(proxy): state the delay sentinel rules once A delay from the core is not just a latency: -2 means a test is running, other negatives mean never tested, zero and anything past the timeout mean it timed out, and absurd values mean error. Every surface agreed on those rules and restated them, and the two sort comparators had already drifted — a non-numeric delay sorted among the timeouts in the proxy list and after the sentinels in the home card. classifyDelay and compareByDelay say it once, with tests, including the case the two copies disagreed on. The trap the ranks exist for is worth naming: zero encodes a timeout, so sorting delays as plain numbers puts the nodes that failed at the top of a fastest-first list. Deliberately not unified: how a *measured* delay is graded. A three-colour chip and a four-bar signal icon draw different distinctions, and collapsing 400/250 into 500/300/200 would be inventing a UI decision rather than removing a duplicated one. Those thresholds stay where they are, next to a comment saying they are a presentation choice. The report that prompted this called them "4 incompatible threshold sets"; on reading them, the sentinel half was duplication and the grading half was not. ProxySortType was declared twice; it is imported now. Frontend tests 8 -> 21. * refactor(enhance): make the app's authoritative fields one value The pipeline derives fields the app owns — ports, the external controller, the tray-driven mode — then lets the user's merge and script overrides run, then puts its own values back. That ordering is a correctness requirement: capture must follow the app's own stages and precede every override, restore must follow all of them. It was four separate calls held together by four comments. AuthoritativeFields captures and restores as one value, so the restore cannot be forgotten, reordered ahead of the overrides, or applied to a config the snapshot did not come from. Five tests state what it is for, including the two cases that are easy to get backwards: an override must not re-add a field the app deliberately left out, and reinstating dns.ipv6 must not conjure a dns block an override removed. merge_default_config now takes enable_external_controller instead of reading it out of the global config from inside its loop. A stage that looks like a function of its arguments and is not is worse than one that admits it, and this is the change that makes it testable at all. Not done here: reshaping the sixteen steps into a stage list. The value in this pipeline is the nine steps with no tests, not the shape of the function that calls them, and the two contracts above were the parts that could silently break. Rust tests 262 -> 267. * refactor(proxy): make the proxy page's outcome a closed set resolveProxyEmptyState returned `reason | 'loading' | null`, which lied twice: 'loading' is not a reason and ProxyEmptyState cannot render it, and `null` meant either "there is content" or "this is direct mode" — so the caller decided direct mode a second time, before even asking. resolveProxyListState returns one closed set of outcomes and the caller switches on it. Ten tests pin the ordering that was previously implicit, including that anything still loading outranks every verdict about emptiness, and that global mode asks about GLOBAL rather than groups. Known gap, left alone deliberately. In chain mode the model asks whether any Selector or URLTest group exists, while the renderer builds its list from selectRuleChainMembers or selectGlobalChainNodes — unrelated questions, and both a false "empty" and a false "not empty" are reachable. Fixing it means the model needs the selected group and the runtime proxies, which is the fold of emptiness into use-render-list that this candidate was really about; guessing at it from outside would add a third derivation rather than remove the second. Frontend tests 21 -> 30. * refactor(events): one subscription with one teardown Four places listened for backend events, three idioms between them, and four separate implementations of the same cleanup. One of them — app-data-provider — pushed each unlisten onto its cleanup list only after awaiting registration, with no disposed flag, so a subscription that resolved after unmount was never torn down. That is now handled in one place, because registration being asynchronous is a property of the mechanism rather than of any call site. Event names were string literals on both sides of the IPC seam, so a rename was a silent no-op. The frontend now declares each name once with its payload type, which does not make Rust check itself but does replace a per-call-site `listen<T>` guess with one place to look. use-layout-events loses about fifty lines that were registration plumbing rather than behaviour, and profiles.tsx loses a Promise.allSettled that existed to collect unlisteners. Left alone: window events — onResized, onFocusChanged, WINDOW_CLOSE_REQUESTED. They come from Tauri's window API rather than the app's own bus, and folding them in would widen the registry to things it does not name. * fix(ui): stop AppDataProvider consuming its own context The provider rendered nothing and threw "useClashConfigData must be used within AppDataProvider": a previous commit replaced its inline mixed-port merge with useDisplayedMixedPort, and that hook reads the ClashConfig context which this component is the one providing. The provider resolves the port from its own sources again. The two computations are not the duplicate they looked like — one runs inside the provider and one outside it, and a hook that reads the provider's context cannot run in both places. They share resolveDisplayedMixedPort, which is the part that was ever worth sharing; a comment now says why the hook is not used here. Nothing else in the provider consumed its own context: it imports the Context objects rather than the reader hooks, and useClashInfo and useRuntimeConfig are plain queries. * fix(core): repair regressions found by review An independent review of this branch found several defects, two of them introduced here and reachable on a normal first run. Startup could silently turn TUN off. Service health is observed as NotInstalled before the startup path decides whether to install the service, and the TUN reconciler ran against that captured snapshot — so it wrote enable_tun_mode: false to the user's config, and because prepare_startup reads that same setting, the install prompt that would have fixed the situation never appeared either. The deleted frontend guard covered this with a ten-second grace period; nothing replaced it. The reconciler now re-reads the current Run State instead of taking a snapshot, and refuses to act at all while the Core is not running, because until then no decision has been made to act on. It also overrode a decision that had already been taken. Falling back to Sidecar calls suppress_tun_for_session, which is deliberately not persistent — disable_tun_and_persist exists as the separate explicit act. The reconciler now honours the session suppression rather than escalating it to a config write. Reconciliation was additionally skipped whenever the app handle did not exist yet, because it was spawned after that early return; it is spawned before it now, which is safe since it no longer depends on the snapshot. apply_service_status wrote the requested action into the store and read it back to decide what to run. A concurrent observation clears the pending action, which would have turned a user-authorised install into a silent no-op. It derives the action from its own argument again, as the code it replaced did. save_proxy_ports opened its transaction before its first fallible read, so that early return discarded drafts staged by other code that this function never touched. It also left rollback to drop, which runs after the recovery paths that regenerate files from committed config — and a second time after those paths had already discarded. The transaction now opens after the read and is rolled back explicitly where recovery needs it to have happened already; the same ordering fix applies to the startup port fallback. DraftTransaction gained a consuming rollback for this. Two pre-existing defects the review surfaced are fixed here because this branch's code depends on them. patch_verge's `?` returned past its own `if let Err(..) { discard() }`, which the compiler could never reach, so a failed patch left the edit in the draft — and the TUN reconciler would then read that draft, believe TUN was already off, and never retry. settled() built its Notified future but never registered it before checking the flag, so an operation finishing in that window was a wakeup lost for good; the waiter would then block until some unrelated later operation, or forever. Deferred with reasons: cancellation-safety of the config futures (no cancellation site demonstrated), enter_mode's PAC/mode atomicity (pre-existing, narrow), and the draft-vs-committed reads behind MixedPort::desired (the PAC window is now closed by core_starting at staging time). Rust tests 267 -> 268. * docs(core): inline the boundary rationale into the code The comments pointed at a glossary and an ADR for why Run State owns state but not Core lifecycle. The reason is short enough to say in place, and a reason that travels with the code it constrains is worth more than a pointer to a file a reader has to go and find. * test(ui): mount AppDataProvider so a context misuse fails loudly A provider that reads a context it supplies throws during render and blanks the whole UI. That shipped: AppDataProvider called useDisplayedMixedPort, which reads ClashConfigContext. typecheck, lint, knip and web:build all passed with it present, and so did an independent three-reviewer code review — the frontend reviewer returned nothing on it. Only rendering can see it. The test stubs `invoke` and `listen` and nothing above them. Everything the provider mounts — the SWR queries, the config hooks, the event subscription, the mihomo plugin — goes through those two, so all the real application code still runs. Stubbing the hooks instead would have produced a test that could not catch what this exists to catch. Verified by reintroducing the bug: both cases fail with the production error, "useClashConfigData must be used within AppDataProvider". A smoke test that passes either way is worth nothing, so this one was checked against the defect rather than only against a working tree. Render tests opt into jsdom per file, so the DOM cost is paid only where it buys something; the rest of the suite stays on node. The libraries land in this commit rather than ahead of it, because knip fails on a dependency nothing uses yet. Frontend tests 30 -> 32. * refactor(proxy): let the list say whether it is empty The empty-state model predicted "is there anything to render" beside the renderer instead of asking it. In chain mode the two asked different questions: the model looked for any Selector or URLTest group, while the list is built from selectRuleChainMembers or selectGlobalChainNodes. Both a false "empty" and a false "not empty" were reachable — GLOBAL with standalone nodes but no Selector group showed nodes while the page said no-proxy-info, and Selector groups with no global and no standalone nodes said content over an empty list. Emptiness is now an observation. hasRenderableItems reads the list that is about to be drawn, and the two list components render the empty state themselves when it comes back with nothing. resolveProxyListState keeps only what is knowable without building a list — direct mode, still loading, and having no usable subscription — which drops proxyView and isChainMode from its input and leaves it with one job. Two details worth stating rather than leaving to be rediscovered. A group header counts as content only when the group is visible, matching what the old predicate meant by "some group is not hidden". Rows inside a hidden but expanded group now count, where the old predicate called the page empty; the user can see those rows, so claiming otherwise was a lie. Frontend tests 32 -> 38, including the chain case that was wrong in both directions. * test(enhance): cover the config transforms that had none Seven of the pipeline's steps had zero references from any test. Four of them are pure functions of their arguments and are now covered; the other three are not, and the difference is the point. use_tun, ensure_fake_ip_range6, use_sort and merge_default_config decide what ends up in the file the core reads, and each has behaviour that is easy to get backwards and impossible to notice: - a disabled listener has its port *removed*, not merely skipped, so the profile's own value cannot open a listener the user switched off - a disabled external controller is blanked rather than deleted, because an absent key lets mihomo fall back to its default and listen anyway - an empty fake-ip-range6 counts as missing, since YAML edited by hand leaves the key present with nothing after the colon - a deliberate redir-host DNS setup is left alone; only fake-ip is ours - turning TUN off does not rewrite DNS, only the system resolver - sorting drops nothing, and is stable when applied twice get_config_values and collect_profile_items are left uncovered on purpose: their whole job is reading global config, so a test would assert that a mock returns what the mock was given. apply_dns_settings and apply_builtin_scripts read the filesystem and run JS respectively; covering those means giving them a seam, which is a change to the code rather than a test of it. Rust tests 268 -> 289. * refactor(proxy): re-sort when a delay test settles Sorting a group by delay read the delay store inside a memo that had no dependency on it, so the order only refreshed when something else forced a recompute. Both places that sort by delay had their own way of forcing it, and both hooked only the "test all" path: retesting a single proxy updated that row's own number and left it sitting in the wrong place. The fix is a subscription, but the granularity is the whole design. The store already coalesces notifications onto an animation frame, so the cost was never the render count — announcing per result would re-sort continuously while a batch is still running, with rows moving out from under the pointer. So the group listener now means "a test settled": once per single test, once per batch however many proxies it covered. Measured against the code before this, a 20-proxy batch would have announced 21 times. That granularity is the thing that normally cannot be asserted, because its symptom is jumpy scrolling rather than a wrong value. Moving the trigger into the store turns it into a number a test can count, and the batch test was checked against the defect: with per-result announcements restored it fails with 21 where it expects 1. The hooks hand over a snapshot rather than a revision counter. A counter has to be listed as a dependency the memo never reads, and exhaustive-deps is right to reject that — the code this replaces satisfied the rule with a `refreshTick >= 0 ? … : 0` ternary whose only purpose was to make the counter look used. A snapshot makes sorting a pure function of a value it is handed. Both invalidation hacks and that ternary are gone. Group listeners are a set now, each with its own unsubscribe. They were one-per-group, so two views watching the same group would have silently replaced each other. Frontend tests 38 -> 43. * fix(proxy): repair the delay reactivity found by review A review of the previous commit found four defects, two of them worse than the code they replaced. The snapshot hook returned a new object on nearly every render. Its state started keyed to a null group, and in the home card the group name resolves after the first render, so the derived branch was taken until some test settled — which, with auto-testing off, is never. The sort memo therefore re-ran on every render and handed a new array downstream. The counter it replaced was at least stable. Both hooks also read during render while the store notifies from an animation frame, so a settle landing between render and the passive effect that subscribes was dropped with nothing to re-trigger it. Both are now built on useSyncExternalStore, which is the mechanism for exactly this and fixes the identity churn at the same time: the store hands out a per-group handle whose identity changes only on settle. A single test could announce while a batch was still running. The per-row delay button and "test all" hold separate locks, so a user can start one inside the other, and sorting from a half-measured group is precisely the reordering this design exists to prevent. Batches are now counted per group and a settle inside one is suppressed until it exits — in a finally, so a throw cannot leave the group unannounced with its proxies pinned at "testing" and nothing later to repair the order. One settle also invalidated every group's cached order, because all groups shared a single token. Each group carries its own handle now, so a test in one group no longer makes its neighbours re-sort. Both new behaviours were checked against their absence: removing the batch counter fails the coordination test, and the earlier granularity test still fails with 21 where it expects 1. The review's other three findings are left alone with reasons — TTL expiry mutating during a read is pre-existing and needs 30 idle minutes, NUL cannot appear in a group name from mihomo's config, and the batch-count assertion already rules out mid-flight fires because a 500ms floor per proxy prevents them collapsing into one frame. Frontend tests 43 -> 45. * feat(core): reload the core in place when switching profiles in Service mode Switching a profile in Service mode stopped and restarted the core, roughly 1.2s of dropped traffic every time. This is pre-existing, from #7569 rather than from this branch: before it, apply_config had no Service branch at all. Two independent reasons, both now addressed. The service protocol had no verb for "change the configuration" other than stop plus start, so a companion change adds `/clash/stage-runtime`. And config reaches the core differently in the two modes — in Sidecar the core reads the app's own directory, in Service it reads a directory the service materialised, with the provider paths rewritten to match. That asymmetry, not session ownership, is why the else-branch could never simply be shared. apply_config now has one shape for both modes: put the configuration where the core can read it, ask the core to reload, replace the core if that did not work. Only the first step differs. Service mode asks the service to stage the runtime in place and, if it did, points the core at the service's copy over the mihomo IPC the app already has open — the app has always been able to command the core in Service mode; only materialising the config needed the service. Every way of not staging leads back to exactly what happened before: a service too old to stage, a service that declined, a request that never came back, or a reload the core refused. `plan_config_application` is the whole of that decision and is a pure function of the attempt, so all four are unit tests rather than things you can only observe against a live service. Verified against the defects they target: treating a refusal as reloadable, and dropping the provider url during collection, both make them fail. The capability is learned once when the core starts and is held with the owner session rather than cached globally. It describes the service instance that owns this core, which is the only scope where acting on it is safe — a service upgraded underneath a running core does not silently gain abilities the core it owns was not started under. A failed protocol query reads as "no", because the only cost is the fast path. `collect_runtime_bundle` now also declares remote providers. It is not an optimisation: the core will not re-fetch a provider whose file already exists, so a download cache left from a different url keeps being served after the switch. The service can only tell a reusable cache from a stale one if the bundle says which url produced it. Not done, and it gates pushing: the dependency pin still names v2.5.3, because v2.6.0 does not exist yet. `^2.5.3` admits 2.6.0 and a local `[patch]` in ~/.cargo/config.toml supplies it, so this builds and tests here but not anywhere else. Cargo.lock is deliberately not in this commit — it currently records a filesystem path. Both need a follow-up once the service-ipc branch is pushed. Nothing here has been run in the real app. The fast path has been exercised against a real service and a real child process in the companion repository's integration tests, and mihomo's reload behaviour was measured directly before any of it was designed, but a `pnpm dev` profile switch in Service mode has not happened. * fix(core): keep a working core when the service refuses the bundle Follow-up to the review of the staging change, on the app side. Every service answer was funnelled into the same fallback. A service that looked at the bundle and refused it — an asset that is gone, a destination it will not accept, a session we no longer own — is telling us something deterministic: the fresh start that follows materialises the same bundle and fails the same way, so stopping the running core adds an outage to a failure that has already happened. `StageAttempt` now distinguishes a refusal from silence, and a refusal leaves the core running and reports why. Silence still replaces the core, because not hearing back says nothing about whether starting would work. This was not a regression — before staging existed the core was stopped in these cases too — but the information to do better only exists now, and throwing it away was the wrong default. `collect_provider_assets` decided a provider was remote by whether it carried a `url`. The core decides by `type`, so the two disagreed: a `file` provider with a stray `url` was treated as remote, its local file left uncopied, and the core could then not find what the rewritten path pointed at. It now reads `type`, and a `http` provider without a usable url is an error rather than a silent reclassification. Remote destinations now claim their slot in the same set local ones do. A path claimed by both a file the service copies and a file the core downloads is refused here rather than reaching the service, which refuses it as well — the copy would otherwise win and both records would match from then on, pinning the wrong content for the life of the generation. Verified by reintroducing each defect: treating a refusal as a restart, and losing the provider url during collection, both make their tests fail. * fix(core): only treat a bundle refusal as a reason not to restart Verification found the previous commit had over-applied its own idea, and the mistake mattered. It routed *every* non-zero service response to "leave the core running and report the error", on the premise that a fresh start would be refused the same way. That premise holds only for refusals about the bundle. `StageRuntime` also answers with a code for a protocol mismatch, a malformed request, an unauthorised owner, and a stale owner session — and for a stale session the premise is exactly backwards: `start_clash` proposes a new session rather than presenting the old one, so starting is how that gets resolved. Worse, the restart path is what notices ownership was lost: `stop_core_by_service` clears the proxy and PAC and marks the core stopped when the session is stale, and skipping it left that undone until the owner monitor came round two seconds later. Only `InvalidRuntimeAsset` and `InvalidInstallLocation` now leave the core alone; everything else replaces it, as before. `collect_provider_assets` was refusing two providers that name the same file *and* the same url. The service folds that — it is one file with two names for it, not a conflict — and mihomo accepts such a config; measured, not assumed. Since this function is also where a Service-mode *start* gets its bundle, the refusal stopped the core coming up at all. It now compares urls and refuses only genuine disagreement. Deciding remote by `type == "http"` was right, but failing the whole bundle when that classification does not fit was not. Measured against mihomo v1.19.26: it accepts a `http` provider with no url, an `inline` provider carrying both a url and a path that does not exist, and a `file` provider whose path is missing. Each of those had become "this configuration cannot be applied at all", where before it merely behaved oddly. A provider that cannot be classified now keeps the path the core was given, is not declared to the service, and is logged. Each correction has a test, and the error-code split is pinned by one that walks the codes rather than trusting a message. * build(deps): resolve the service protocol crate from its pushed branch The staging work needed protocol revision 2, which did not exist anywhere yet, so the last three commits built against a local checkout supplied by an untracked `[patch]` and deliberately left `Cargo.lock` out. That branch is pushed now, so the pin names it and the lock records the commit rather than a path on one machine — this tree builds for anyone again. Still a branch and not a tag: the protocol has only been exercised by the service's own tests and by this client compiling against it, never by the two running together. Moving to v2.6.0 is worth doing once it has. * build(deps): take the kode-bridge listener-mode fix Only reaches this repository through the service protocol crate, but the lock is where the commit is recorded, so it has to move here too. kode-bridge applied a listener's permission mode as a bind-time option on every unix except macOS, where the umask filters it — a service asking for 0o666 got 0o644 or 0o600 depending on the host. That is why the service published a control socket on Linux that no unprivileged client could open. * build(deps): advance the service protocol pin to the branch head The lock still named the commit the branch had when it was first pinned, five commits ago; two of those are the Windows CI fixes. Nothing in them changes what this repository compiles — the parts they touch are behind the `test` feature, which this dependency does not enable — but a lock that names a commit the branch has moved past means the next person to rebuild gets something different from what was tested here. Only the commit changes. `cargo update -p clash_verge_service_ipc` also rewrites twelve unrelated crates from `windows-sys 0.61.2` down to 0.60.2 and 0.52.0, which has nothing to do with this pin and is not wanted; `cargo check --locked` confirms the 0.61.2 resolution is still valid, so the downgrade is the resolver's preference rather than a requirement. * fix(ci): unblock Windows Rust checks	2026-07-27 00:44:53 -07:00
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	2026-07-24 09:01:49 +08:00
Tunglies	55ce7bffe4	refactor: avoid embed server clone	2026-06-13 19:51:14 +08:00
Tunglies	af094bfcd7	refactor: remove port_scanner dependency and simplify port checking logic	2025-12-21 16:51:55 +08:00
Tunglies	2ca8e6716d	style: adjust rustfmt max_width to 120	2025-12-06 10:31:31 +08:00
Tunglies	0866b93175	feat(logging): introduce clash-verge-logging crate for management (#5486) ... * feat(logging): introduce clash-verge-logging crate for management - Added a new crate `clash-verge-logging` with dependencies on `log`, `tokio`, `compact_str`, and `flexi_logger`. - Implemented logging types and macros for structured logging across the application. - Replaced existing logging imports with the new `clash_verge_logging` crate in various modules. - Updated logging functionality to support different logging types and error handling. - Refactored code to improve logging consistency and maintainability. * fix(logging): update import paths for clash_verge_logging in linux.rs and dns.rs * fix(logging): update import statement for clash_verge_logging in windows.rs	2025-11-17 10:42:57 +08:00
oomeow	b0089d162b	fix: dynamically modify pac content (#5468) ... * fix: dynamically modify pac content * docs: update Changelog.md	2025-11-16 18:53:43 +08:00
Tunglies	f3a3d0e8b0	refactor: update update_icon method to require a non-optional verge reference and adjust related calls (#5417)	2025-11-12 07:36:24 +08:00
Tunglies	4eeb883464	refactor: update imports to use as _ for unused identifiers across multiple files	2025-11-09 22:15:37 +08:00
oomeow	76bf91ff8a	fix: import profile panic (#5346) ... * fix: import profile panic docs: update UPDATELOG.md chore: update * perf: spawn import profile	2025-11-07 22:46:30 +08:00
Tunglies	aaf3ebe547	refactor: enhance error handling in Timer and update server argument collection	2025-11-06 10:42:21 +08:00
Tunglies	2287ea5f0b	Refactor configuration access to use latest_arc() instead of latest_ref() ... - Updated multiple instances in the codebase to replace calls to latest_ref() with latest_arc() for improved performance and memory management. - This change affects various modules including validate, enhance, feat (backup, clash, config, profile, proxy, window), utils (draft, i18n, init, network, resolve, server). - Ensured that all references to configuration data are now using the new arc-based approach to enhance concurrency and reduce cloning overhead. refactor: update imports to explicitly include ClashInfo and Config in command files	2025-11-04 06:06:20 +08:00
Tunglies	fb260fb33d	Refactor logging to use a centralized logging utility across the application (#5277) ... - Replaced direct log calls with a new logging macro that includes a logging type for better categorization. - Updated logging in various modules including `merge.rs`, `mod.rs`, `tun.rs`, `clash.rs`, `profile.rs`, `proxy.rs`, `window.rs`, `lightweight.rs`, `guard.rs`, `autostart.rs`, `dirs.rs`, `dns.rs`, `scheme.rs`, `server.rs`, and `window_manager.rs`. - Introduced logging types such as `Core`, `Network`, `ProxyMode`, `Window`, `Lightweight`, `Service`, and `File` to enhance log clarity and filtering.	2025-11-01 20:47:01 +08:00
Tunglies	9370a56337	refactor: reduce clone operation (#5268) ... * refactor: optimize item handling and improve profile management * refactor: update IVerge references to use references instead of owned values * refactor: update patch_verge to use data_ref for improved data handling * refactor: move handle_copy function to improve resource initialization logic * refactor: update profile handling to use references for improved memory efficiency * refactor: simplify get_item method and update profile item retrieval to use string slices * refactor: update profile validation and patching to use references for improved performance * refactor: update profile functions to use references for improved performance and memory efficiency * refactor: update profile patching functions to use references for improved memory efficiency * refactor: simplify merge function in PrfOption to enhance readability * refactor: update change_core function to accept a reference for improved memory efficiency * refactor: update PrfItem and profile functions to use references for improved memory efficiency * refactor: update resolve_scheme function to accept a reference for improved memory efficiency * refactor: update resolve_scheme function to accept a string slice for improved flexibility * refactor: simplify update_profile parameters and logic	2025-11-01 20:03:56 +08:00
Tunglies	2d2167e048	refactor: replace unwrap_or with unwrap_or_else for improved error handling (#5163) ... In Rust, the `or` and `or_else` methods have distinct behavioral differences. The `or` method always eagerly evaluates its argument and executes any associated function calls. This can lead to unnecessary performance costs—especially in expensive operations like string processing or file handling—and may even trigger unintended side effects. In contrast, `or_else` evaluates its closure lazily, only when necessary. Introducing a Clippy lint to disallow `or` sacrifices a bit of code simplicity but ensures predictable behavior and enforces lazy evaluation for better performance.	2025-10-22 17:33:55 +08:00
Tunglies	a05ea64bcd	perf: utilize smartstring for string handling (#5149) ... * perf: utilize smartstring for string handling - Updated various modules to replace standard String with smartstring::alias::String for improved performance and memory efficiency. - Adjusted string manipulations and conversions throughout the codebase to ensure compatibility with the new smartstring type. - Enhanced readability and maintainability by using `.into()` for conversions where applicable. - Ensured that all instances of string handling in configuration, logging, and network management leverage the benefits of smartstring. * fix: replace wrap_err with stringify_err for better error handling in UWP tool invocation * refactor: update import path for StringifyErr and adjust string handling in sysopt * fix: correct import path for CmdResult in UWP module * fix: update argument type for execute_sysproxy_command to use std::string::String * fix: add missing CmdResult import in UWP platform module * fix: improve string handling and error messaging across multiple files * style: format code for improved readability and consistency across multiple files * fix: remove unused file	2025-10-22 16:25:44 +08:00
Tunglies	afb049ca17	fix: simplify conditional checks and improve async handler usage across multiple files (#5156) ... * fix: simplify conditional checks and improve async handler usage across multiple files * fix: add missing AsyncHandler import in find_processes_by_name function * fix: remove redundant AsyncHandler import in find_processes_by_name function	2025-10-21 22:39:32 +08:00
xmk23333	b9dd62e2e6	refactor: enhance error handling and logging in core components and server initialization	2025-10-20 16:34:38 +08:00
xmk23333	786c981fe0	refactor: improve error handling in AppDataProvider and enhance configuration update logic in CoreManager	2025-10-20 13:26:24 +08:00
Tunglies	924e7d1022	Refactor string handling to use into() instead of to_string() for improved performance and consistency across the codebase. This change affects various modules including app.rs, clash.rs, config.rs, core.rs, service.rs, and others, ensuring that string conversions are streamlined and more idiomatic.	2025-10-14 09:26:20 +08:00
oomeowandSlinetrac	b91087e175	feat: support for reopen app via desktop shortcuts (#5037) ... * fix: singleton check * docs: update UPDATELOG.md --------- Co-authored-by: Slinetrac <realakayuki@gmail.com>	2025-10-12 22:55:40 +08:00
Tunglies	8c0af66ca9	Refactor logging macros to remove print control parameter ... - Updated logging macros to eliminate the boolean parameter for print control, simplifying the logging calls throughout the codebase. - Adjusted all logging calls in various modules (lib.rs, lightweight.rs, help.rs, init.rs, logging.rs, resolve/mod.rs, resolve/scheme.rs, resolve/ui.rs, resolve/window.rs, server.rs, singleton.rs, window_manager.rs) to reflect the new macro structure. - Ensured consistent logging behavior across the application by standardizing the logging format.	2025-10-10 13:05:37 +08:00
oomeow	1357913f8b	fix: restart app failed (#4974) ... * fix: failed to restart app * chore: cleanup * chore: cargo fmt * chore: use AsyncHandler * chore: clippy * chore: update	2025-10-09 20:08:25 +08:00
Tunglies	251678493c	edition 2024 (#4702) ... * feat: update Cargo.toml for 2024 edition and optimize release profiles * feat: refactor environment variable settings for Linux and improve code organization * Refactor conditional statements to use `&&` for improved readability - Updated multiple files to combine nested `if let` statements using `&&` for better clarity and conciseness. - This change enhances the readability of the code by reducing indentation levels and making the conditions more straightforward. - Affected files include: media_unlock_checker.rs, profile.rs, clash.rs, profiles.rs, async_proxy_query.rs, core.rs, handle.rs, hotkey.rs, service.rs, timer.rs, tray/mod.rs, merge.rs, seq.rs, config.rs, proxy.rs, window.rs, general.rs, dirs.rs, i18n.rs, init.rs, network.rs, and window.rs in the resolve module. * refactor: streamline conditional checks using `&&` for improved readability * fix: update release profile settings for panic behavior and optimization * fix: adjust optimization level in Cargo.toml and reorder imports in lightweight.rs	2025-09-10 09:49:06 +08:00
Tunglies	55b95a1985	Revert "feat: update Cargo.toml for 2024 edition and optimize release profiles (#4681)" ... This reverts commit 31e3104c7f.	2025-09-08 21:48:09 +08:00
Tunglies	31e3104c7f	feat: update Cargo.toml for 2024 edition and optimize release profiles (#4681) ... * feat: update Cargo.toml for 2024 edition and optimize release profiles * feat: refactor environment variable settings for Linux and improve code organization * Refactor conditional statements to use `&&` for improved readability - Updated multiple files to combine nested `if let` statements using `&&` for better clarity and conciseness. - This change enhances the readability of the code by reducing indentation levels and making the conditions more straightforward. - Affected files include: media_unlock_checker.rs, profile.rs, clash.rs, profiles.rs, async_proxy_query.rs, core.rs, handle.rs, hotkey.rs, service.rs, timer.rs, tray/mod.rs, merge.rs, seq.rs, config.rs, proxy.rs, window.rs, general.rs, dirs.rs, i18n.rs, init.rs, network.rs, and window.rs in the resolve module. * refactor: streamline conditional checks using `&&` for improved readability	2025-09-08 13:57:32 +08:00
Tunglies	d2b38a8a3c	fix: optimize async handler usage in singleton checks and resource initialization #4576, #4590, #4609	2025-09-02 13:37:14 +08:00
Tunglies	3a7be3dfb7	refactor: streamline resolve_scheme function calls and visibility in utils	2025-08-30 17:22:52 +08:00
Tunglies	c6a6ea48dd	refactor: enhance async initialization and streamline setup process (#4560) ... * feat: Implement DNS management for macOS - Added `set_public_dns` and `restore_public_dns` functions in `dns.rs` to manage system DNS settings. - Introduced `resolve` module to encapsulate DNS and scheme resolution functionalities. - Implemented `resolve_scheme` function in `scheme.rs` to handle deep links and profile imports. - Created UI readiness management in `ui.rs` to track and update UI loading states. - Developed window management logic in `window.rs` to handle window creation and visibility. - Added initial loading overlay script in `window_script.rs` for better user experience during startup. - Updated server handling in `server.rs` to integrate new resolve functionalities. - Refactored window creation calls in `window_manager.rs` to use the new window management logic. * refactor: streamline asynchronous handling in config and resolve setup * Revert "refactor: streamline asynchronous handling in config and resolve setup" This reverts commit 23d7dc86d5. * fix: optimize asynchronous memory handling * fix: enhance task logging by adding size check for special cases * refactor: enhance async initialization and streamline setup process * refactor: optimize async setup by consolidating initialization tasks * chore: update changelog for Mihomo(Meta) kernel upgrade to v1.19.13 * fix: improve startup phase initialization performance * refactor: optimize file read/write performance to reduce application wait time * refactor: simplify app instance exit logic and adjust system proxy guard initialization * refactor: change resolve_setup_async to synchronous execution for improved performance * refactor: update resolve_setup_async to accept AppHandle for improved initialization flow * refactor: remove unnecessary initialization of portable flag in run function * refactor: consolidate async initialization tasks into a single blocking call for improved execution flow * refactor: optimize resolve_setup_async by restructuring async tasks for improved concurrency * refactor: streamline resolve_setup_async and embed_server for improved async handling * refactor: separate synchronous and asynchronous setup functions for improved clarity * refactor: simplify async notification handling and remove redundant network manager initialization * refactor: enhance async handling in proxy request cache and window creation logic * refactor: improve code formatting and readability in ProxyRequestCache * refactor: adjust singleton check timeout and optimize trace size conditions * refactor: update TRACE_SPECIAL_SIZE to include additional size condition * refactor: update kode-bridge dependency to version 0.2.1-rc2 * refactor: replace RwLock with AtomicBool for UI readiness and implement event-driven monitoring * refactor: convert async functions to synchronous for window management * Update src-tauri/src/utils/resolve/window.rs * fix: handle missing app_handle in create_window function * Update src-tauri/src/module/lightweight.rs	2025-08-29 23:57:42 +08:00
Tunglies	355a18e5eb	refactor(async): migrate from sync-blocking async execution to true async with unified AsyncHandler::spawn (#4502) ... * feat: replace all tokio::spawn with unified AsyncHandler::spawn - 🚀 Core Improvements: * Replace all tokio::spawn calls with AsyncHandler::spawn for unified Tauri async task management * Prioritize converting sync functions to async functions to reduce spawn usage * Use .await directly in async contexts instead of spawn - 🔧 Major Changes: * core/hotkey.rs: Use AsyncHandler::spawn for hotkey callback functions * module/lightweight.rs: Async lightweight mode switching * feat/window.rs: Convert window operation functions to async, use .await internally * feat/proxy.rs, feat/clash.rs: Async proxy and mode switching functions * lib.rs: Window focus handling with AsyncHandler::spawn * core/tray/mod.rs: Complete async tray event handling - ✨ Technical Advantages: * Unified task tracking and debugging capabilities (via tokio-trace feature) * Better error handling and task management * Consistency with Tauri runtime * Reduced async boundaries for better performance - 🧪 Verification: * Compilation successful with 0 errors, 0 warnings * Maintains complete original functionality * Optimized async execution flow * feat: complete tokio fs migration and replace tokio::spawn with AsyncHandler 🚀 Major achievements: - Migrate 8 core modules from std::fs to tokio::fs - Create 6 Send-safe wrapper functions using spawn_blocking pattern - Replace all tokio::spawn calls with AsyncHandler::spawn for unified async task management - Solve all 19 Send trait compilation errors through innovative spawn_blocking architecture 🔧 Core changes: - config/profiles.rs: Add profiles_*_safe functions to handle Send trait constraints - cmd/profile.rs: Update all Tauri commands to use Send-safe operations - config/prfitem.rs: Replace append_item calls with profiles_append_item_safe - utils/help.rs: Convert YAML operations to async (read_yaml, save_yaml) - Multiple modules: Replace tokio::task::spawn_blocking with AsyncHandler::spawn_blocking ✅ Technical innovations: - spawn_blocking wrapper pattern resolves parking_lot RwLock Send trait conflicts - Maintain parking_lot performance while achieving Tauri async command compatibility - Preserve backwards compatibility with gradual migration strategy 🎯 Results: - Zero compilation errors - Zero warnings - All async file operations working correctly - Complete Send trait compliance for Tauri commands * feat: refactor app handle and command functions to use async/await for improved performance * feat: update async handling in profiles and logging functions for improved error handling and performance * fix: update TRACE_MINI_SIZE constant to improve task logging threshold * fix(windows): convert service management functions to async for improved performance * fix: convert service management functions to async for improved responsiveness * fix(ubuntu): convert install and reinstall service functions to async for improved performance * fix(linux): convert uninstall_service function to async for improved performance * fix: convert uninstall_service call to async for improved performance * fix: convert file and directory creation calls to async for improved performance * fix: convert hotkey functions to async for improved responsiveness * chore: update UPDATELOG.md for v2.4.1 with major improvements and performance optimizations	2025-08-26 01:49:51 +08:00
Tunglies	537d27d10b	fix: clippy errors with new config (#4428) ... * refactor: improve code quality with clippy fixes and standardized logging - Replace dangerous unwrap()/expect() calls with proper error handling - Standardize logging from log:: to logging\! macro with Type:: classifications - Fix app handle panics with graceful fallback patterns - Improve error resilience across 35+ modules without breaking functionality - Reduce clippy warnings from 300+ to 0 in main library code * chore: update Cargo.toml configuration * refactor: resolve all clippy warnings - Fix Arc clone warnings using explicit Arc::clone syntax across 9 files - Add #[allow(clippy::expect_used)] to test functions for appropriate expect usage - Remove no-effect statements from debug code cleanup - Apply clippy auto-fixes for dbg\! macro removals and path statements - Achieve zero clippy warnings on all targets with -D warnings flag * chore: update Cargo.toml clippy configuration * refactor: simplify macOS job configuration and improve caching * refactor: remove unnecessary async/await from service and proxy functions * refactor: streamline pnpm installation in CI configuration * refactor: simplify error handling and remove unnecessary else statements * refactor: replace async/await with synchronous locks for core management * refactor: add workflow_dispatch trigger to clippy job * refactor: convert async functions to synchronous for service management * refactor: convert async functions to synchronous for UWP tool invocation * fix: change wrong logging * refactor: convert proxy restoration functions to async * Revert "refactor: convert proxy restoration functions to async" This reverts commit b82f5d250b. * refactor: update proxy restoration functions to return Result types * fix: handle errors during proxy restoration and update async function signatures * fix: handle errors during proxy restoration and update async function signatures * refactor: update restore_pac_proxy and restore_sys_proxy functions to async * fix: convert restore_pac_proxy and restore_sys_proxy functions to async * fix: await restore_sys_proxy calls in proxy restoration logic * fix: suppress clippy warnings for unused async functions in proxy restoration * fix: suppress clippy warnings for unused async functions in proxy restoration	2025-08-18 02:02:25 +08:00
4 people	cdc1fd2d87	chore(deps): update cargo dependencies (#4329) ... * chore(deps): update cargo dependencies * fix: update warp dependency to include server feature * fix: update return type of scheme_handler to String for consistency * fix: add hyper-util dependency and update warp path handlers for response status --------- Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: Tunglies <tunglies.dev@outlook.com> Co-authored-by: Tunglies <77394545+Tunglies@users.noreply.github.com>	2025-08-06 22:46:46 +08:00
Tunglies	764ef48fd1	refactor(Draft): Replace latest() with latest_ref() and data() with data_mut() in multiple files for improved mutability handling and consistency across the codebase (#3987) ... * feat: add benchmarking for draft operations and new draft management structure * Refactor Config Access: Replace `latest()` with `latest_ref()` and `data()` with `data_mut()` in multiple files for improved mutability handling and consistency across the codebase. * refactor: remove DraftNew implementation and related benchmarks for cleaner codebase	2025-07-04 22:43:23 +08:00
Tunglies	a574ced428	Refactor logging statements to use the new formatting syntax for improved readability and consistency across the codebase. This includes updating error, warning, and info logs in various modules such as system commands, configuration, core functionalities, and utilities. Additionally, minor adjustments were made to string formatting in backup and proxy features to enhance clarity.	2025-06-27 23:30:59 +08:00
Tunglies	b6a6f5f434	Add AsyncHandler for wrapping task spawning	2025-04-11 17:30:30 +08:00
Tunglies	0de304d4e3	Fix and Optimize ... fix: #3187 and #3096, silent startup can not trigger lightweight mode fix: optimize startup initializing processing	2025-04-05 10:28:27 +08:00
Tunglies	e8e16f7d57	refactor(logging): replace log_err! with structured logging_error! calls ... refactor(cm-service): better error handling from Backend to Frontend	2025-03-28 03:39:34 +08:00
Tunglies	b57c6e408a	chore: git hooks for linter and formatter	2025-03-13 12:51:20 +08:00
huzibaca	1c894f3cfa	refactor: unify and simplify the call of app_handle	2024-09-23 16:31:58 +08:00