feat(helper): service-management adapter and primitives - #620
feat(helper): service-management adapter and primitives#620Alex Shabalin (alex-sparus) wants to merge 1 commit into
Conversation
This stack of pull requests is managed by jj-ryu. |
📋 PR Overview
🔬 Coverage
|
🎨 Storybook previewUpdated for a21e004
|
d28eb07 to
b8cb660
Compare
09ce796 to
69fa080
Compare
e171392 to
a4109c4
Compare
69fa080 to
d4bcf67
Compare
a4109c4 to
ac5bd9c
Compare
d4bcf67 to
64d61f6
Compare
ac5bd9c to
d1aa8ad
Compare
64d61f6 to
933bc69
Compare
d1aa8ad to
eb7a8bf
Compare
933bc69 to
f2d42f9
Compare
eb7a8bf to
3ca6982
Compare
f2d42f9 to
92010a4
Compare
3ca6982 to
49b0935
Compare
92010a4 to
71356d2
Compare
49b0935 to
d392133
Compare
71356d2 to
d78be64
Compare
| /// A raw value outside this set is an adapter error, never a fifth status: | ||
| /// every reconciliation decision is a total match over these four, and a | ||
| /// catch-all would let an unreadable registration pass for one of them. | ||
| // Only the macOS adapter reads a raw status, so off Apple nothing constructs |
There was a problem hiding this comment.
Probably meant to be a /// comment
There was a problem hiding this comment.
Actually, this is a neat trick: only /// will appear as the documentation and the // part is just a comment about building on non-macOS (allow(dead_code) etc)
| @@ -0,0 +1,318 @@ | |||
| // Observation of the helper socket: is anything listening on it? | |||
There was a problem hiding this comment.
//!
There was a problem hiding this comment.
An explanation from AI:
Four files in this module (protocol.rs, peer_auth.rs, client.rs, helper_runtime.rs) are include!d into the helper and sync-agent binaries, where //! is a hard error (E0753) — see the note at peer_auth.rs:17. socket_probe.rs isn't include!d, so //! would compile here, but keeping one header style across the module means nobody has to work out which files may take it. Only upside would be rustdoc on an internal module.
| return Ok(false); | ||
| } | ||
|
|
||
| adopt_legacy_fields(prefs, |key| store.get(key))?; |
There was a problem hiding this comment.
We should really be able to quit supporting legacy migration and rip that code out since I think it predates the major launch by a significant amount, especially for newly added preferences. I will enter an issue about this.
d392133 to
67c9fac
Compare
d78be64 to
79ab79c
Compare
Swap the hand-rolled objc SMAppService calls for objc2-service-management and add the observations and effects a helper replacement needs. Behavior-preserving: the existing facade keeps its callers and everything new is caller-less. - The published wrapper crates offer neither the asynchronous unregister nor a typed status. The async form is the point: its completion fires only after the running helper has been killed, which is the one signal that makes re-registering safe, and the synchronous call returns before the process is reaped. - A replacement refuses a main-thread caller up front. Both calls are issued on the main queue, so awaiting them there starves the queue that has to make them and reads back as a callback that never arrived — a wrong diagnosis of a deadlock we can rule out instead. - Registering only once the unregister has reported is also Apple's workaround for an immediate re-registration failing: the second dispatch is unavoidably a later run-loop turn than the first. - Stamp the build ID into the bundle's Info.plist, because a running GUI has to be able to tell that its bundle was replaced underneath it. One resolution feeds both the compiled constant and the stamp, so they cannot disagree; the tracked plist becomes a template so only the stamped copy is merged and one file reaches the bundle. - The helper preference is tri-state, not a boolean: `unset` is what lets an existing registration be adopted as an earlier opt-in without that adoption overriding an explicit disable. It is device-local, so settings import and the legacy-store migration leave it alone — no other machine's file, and no key in the old store, decides whether this Mac runs a privileged helper. - Positive absence is deliberately narrow: a refusal or a missing socket across a bounded window, never a timeout or anything else ambiguous. It is one of the few observations that authorizes terminating a registration, so an unproven absence has to stay unproven.
67c9fac to
0eea435
Compare
79ab79c to
a21e004
Compare





Summary
internal code
E1bTest Plan
Docs