Skip to content

Add core-owned structured diagnostics callback #244

Description

@pgherveou

Context

Dotli currently observes statement-store traffic at the host JSON-RPC transport boundary for the debug panel. We just removed the fragile part where dotli parsed Rust/core request-id strings such as :query: or :unsubscribe; request ids are now treated as opaque correlation keys.

That is a pragmatic improvement, but the host still infers some diagnostic meaning from transport methods. The long-term design should let the Rust shared core emit structured diagnostic events for core-owned flows.

Goal

Add an optional host diagnostics callback so the Rust core can publish structured debug/lifecycle events without hosts reverse-engineering request ids, JSON-RPC method names, or private flow details.

Products must not see this surface. It is platform diagnostics for host shells and developer tooling only.

Proposed API shape

pub trait CoreDiagnostics: Send + Sync {
    fn core_diagnostic_event(&self, event: CoreDiagnosticEvent) {
        let _ = event;
    }
}

pub enum CoreDiagnosticEvent {
    StatementStore(StatementStoreDiagnosticEvent),
    Sso(SsoDiagnosticEvent),
}

pub enum StatementStoreDiagnosticEvent {
    Connecting {
        chain: ChainId,
        purpose: StatementStorePurpose,
    },
    Connected {
        chain: ChainId,
        purpose: StatementStorePurpose,
    },
    Request {
        correlation_id: String,
        method: StatementStoreMethod,
        kind: StatementStoreRequestKind,
        purpose: StatementStorePurpose,
    },
    Response {
        correlation_id: Option<String>,
        method: Option<StatementStoreMethod>,
        kind: StatementStoreResponseKind,
        statement_count: Option<u32>,
        remaining: Option<u32>,
        error: Option<String>,
    },
    Disconnected {
        reason: Option<String>,
    },
}

pub enum StatementStorePurpose {
    Pairing,
    RemoteSsoRequest,
    PeerDisconnectMonitor,
    ProductStatementStore,
}

pub enum StatementStoreMethod {
    Submit,
    Subscribe,
    Unsubscribe,
}

pub enum StatementStoreRequestKind {
    Submit,
    Subscribe,
    Unsubscribe,
}

pub enum StatementStoreResponseKind {
    Ack,
    Error,
    Page,
    MalformedPage,
}

Names are illustrative; final names should match the platform trait naming style.

Design rules

  • correlation_id is opaque. Hosts may group by it, but must not parse it.
  • Rust owns event meaning: pairing, polling, query, cleanup, SSO remote request, disconnect monitor, product statement-store usage.
  • Hosts own rendering, filtering, persistence, and forwarding to debug panels.
  • The callback must be optional with a no-op default so hosts can ignore diagnostics.
  • Web should receive this through the generated host callback bridge as something like coreDiagnosticEvent(event).
  • iOS/Android should eventually receive the same typed enum through UniFFI.
  • The diagnostics surface should remain out of the product-facing TrUAPI protocol.

Why

This keeps host implementations syscall-style: hosts provide OS/browser primitives and render tooling, while Rust owns shared protocol semantics. It also prevents each host from rebuilding its own partial understanding of core internals for debug UX.

Suggested rollout

  1. Add the CoreDiagnostics trait and typed event DTOs in truapi-platform.
  2. Emit statement-store and SSO diagnostic events from the Rust runtime where the semantic context is known.
  3. Generate the Web callback type/adapter for coreDiagnosticEvent.
  4. Update dotli debug panel to consume the structured callback.
  5. Remove remaining method-level statement-store inference from dotli Chain.ts.

Acceptance criteria

  • Dotli no longer derives SSO/statement-store debug event meaning from JSON-RPC method names or request ids.
  • Request ids remain opaque correlation keys only.
  • The same event DTOs are suitable for Web, Desktop, iOS, and Android host bindings.
  • Existing product TrUAPI behavior and wire protocol are unchanged.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions