improvement(event-streaming): strong type streamer IDs

[BigFish2086]

(#2207): Refactored the Streamer Id to its own enumeration type.

[Copilot]

Pull Request Overview

This PR refactors the event streaming system to use a strongly typed StreamerId enum rather than plain strings for streamer identifiers. Key changes include updating various event streamer implementations, responses, and manager functions across the codebase to adopt the new StreamerId type, and adding a new StreamerId enum with dedicated variants.

Reviewed Changes

Copilot reviewed 21 out of 21 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
mm2src/mm2_p2p/src/application/network_event.rs	Changed streamer_id return type to StreamerId for Network events.
mm2src/mm2_main/src/rpc/streaming_activations/mod.rs/disable.rs	Updated request/response types from String to StreamerId.
mm2src/mm2_main/src/* (lp_swap, orderbook_events, etc.)	Replaced String-based streamer ids with strongly typed StreamerId.
mm2src/mm2_event_stream/src/streamer.rs	Introduced the new StreamerId enum and updated Display/Debug impls.
mm2src/mm2_event_stream/src/event.rs	Changed event handling to use StreamerId instead of raw strings.
mm2src/coins/*	Updated coin-related event streamers to use StreamerId for balance, fee, tx history, etc.

[borngraced]

great work! two notes from me

[borngraced]

I can tell this that this method will be called frequently. Can you refactor StreamerId enum to something like this

#[derive(Debug)]
pub enum StreamerIdInner {
    Network,
    Heartbeat,
    SwapStatus,
    OrderStatus,
    Task(u64),
    Balance(String),
    DataNeeded(String),
    TxHistory(String),
    FeeEstimation(String),
    OrderbookUpdate(String),
    #[cfg(test)]
    ForTesting(String),
}

pub type StreamerId = Arc<StreamerIdInner>;

[BigFish2086]

seems good, I have tried this idea and pushed the changes.

[borngraced]

derive_streamer_id returns Owned value in some places while static value in another place. Let's stick to one

[BigFish2086]

I changed it to return StreamerId in all places.

[smk762]

Please add comments to related docs PR GLEECBTC/komodo-docs-mdx#457 if this includes any changes to streamer_id format etc. so I can update examples.

[borngraced]

Thanks!

[mariocynicys]

Thanks

done a quick review over the last commit. will review thoroughly next week.

[mariocynicys]

Thanks! ❤️

Done reviewing everything. Will just follow up with my comments and approve when they are done.

[mariocynicys]

so the main reason i didn't wanna do this in the original PR was that this introduces mm2 specific lingo/logic in this crate (mm2_event_stream) which is trying to be abstract.

there looks to be no way around it though - if we wanna strong type streamer ids and avoid possible dev errors.

could you please move this logic to a different isolated/new file. as it doens't really fit in streamer.rs. maybe call it streamer_ids.rs.

[BigFish2086]

I moved it to its own file, streamer_ids.rs as suggested in 044d932. I have thought about the how to make the Event more generic like this:

pub struct Event<'m, 's, M, S>
where
    M: Clone + Debug + Deserialize<'m> + Serialize,
    S: Clone + Debug + Deserialize<'s> + Eq + Hash + PartialEq + Serialize,
{
    pub streamer_id: S,
    pub message: M,
    pub error: bool,
    _phantom_streamer_id: PhantomData<&'s ()>,
    _phantom_message: PhantomData<&'m ()>,
}

pub type Event01<'m, 's> = Event<'m, 's, StreamerId, serde_json::Value>;

But that would require us using the lifetimes all over the code and I thought it would be better to discuss it more before implementing it (in another PR maybe.)

[mariocynicys]

Q about this suggestion, using S and M as generics in the event type essentially creates multiple event types for each S & M pair.

we could ofc then dyn things up and box them to be able to work with them from the streaming manager side. but just saying.

[dimxy]

Why not make this streamer list dynamic and agnostic about existing event sources?
I think, modules, which want to send events, may register themselves as event sources in the streamer. In register call they provide event prefixes. In response the streamer would return generated streamer_id which is used as a handle to streamer functions.
With that, we may add new modules as event sources, without touching the streamer code.
@mariocynicys

[mariocynicys]

so let's say we enable the orderstatus streamer. it registers itself in such list and gets an ID back. 1- what's the type of this ID? 2- how other parts of the code would know this ID so to send data to the streamer (e.g.)

[laruh]

LGTM!

@BigFish2086 @mariocynicys please leave a todo in the issue #2207 or create a new one about optimisations were discussed in the thread #2441 (comment)

@BigFish2086 good start!