feat: typed install_app errors, payload signing, and lair error detail - #144
feat: typed install_app errors, payload signing, and lair error detail#144zo-el wants to merge 3 commits into
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
9bb7aec to
15a2b6a
Compare
Route `Runtime::install_app` through the conductor handle directly (`install_app_bundle`) instead of `AdminInterfaceApi::handle_request`, which flattens every conductor error into a print-only `ExternalApiWireError::InternalError(String)` (holochain TODO B-01506). Going direct preserves the typed `ConductorError`, which the existing `From<ConductorError>` impl surfaces as `RuntimeError::Conductor(..)`, so callers can match on the actual failure — e.g. the benign re-install case as `ConductorError::AppAlreadyInstalled` — instead of grepping a Debug string. Previously every install failure arrived as the opaque `RuntimeError::AdminApiBadResponse`. The success path mirrors the admin `InstallApp` handler (`get_dna_definitions` + `AppInfo::from_installed_app`), and `check_running()` is preserved for fast-fail parity with the sibling `req_admin_api` calls. `tauri-plugin-holochain` re-exports `RuntimeError` and `ConductorError` so plugin consumers can destructure the error without depending on the runtime crate directly. Add `test_install_app_already_installed`, covering that the typed conductor error survives the passthrough and that a failed re-install leaves the original app untouched.
15a2b6a to
4b02203
Compare
|
Should this not go into |
The Display impl dropped the wrapped OneErr's message, so every lair failure (locked keystore, missing key, any other cause) rendered as the identical bare string "Lair Error" with no way to tell them apart from the caller side.
Runtime::sign_payload signs whatever bytes the caller supplies with a specific agent key held by the keystore, for protocols beyond zome calls that need proof of control over a Holochain identity (e.g. signing a timestamp for a re-authentication handshake). The signing key is always explicit: this keystore can hold more than one signable identity at once (the device-seed key and, in authenticated mode, a separate hc-auth key), and there is no default, since a signature from the wrong key is still valid, just for the wrong identity. Exposed through the in-process plugin as the sign_payload Tauri command: raw agent-key bytes and payload in, a base64-encoded signature out ready for a JSON body. Malformed key bytes from the webview are rejected via the fallible HoloHash parse rather than the panicking one used elsewhere at the FFI boundary, since this input comes straight off the wire.
|
Superseded by #146, which targets main as you suggested. Backport to main-0.6 to follow. |
install_appreturns the typedConductorErrorinstead of an opaque string, so callers can matchthe real failure.
Runtime::sign_payloadsigns an arbitrary payload with a caller-chosen agent key, exposed as a Tauricommand.
RuntimeError::Laircarries lair's own message, which it previously discarded.