renew: stage 4 #27

Open
opened 2026-04-30 12:02:37 +02:00 by kir68k · 0 comments
Owner

Focus: Implementing Sync actor + Supervisors

Notes

Sync actor

After login, the first thing to do would be setting up background sync, like in the old version and #19 (there it's done via ExportApp::background_sync and a detached task).

I already have actor/sync as a port of that method.
The nice thing about using a stream and intercepting sync
responses is possibly propagating the error to e.g. shut down any actors depending on bg sync
(which, from my understanding of the sdk, would be most functionality one would want).

That's what the comment in

Lines 42 to 44 in 70c3a0e
while let Some(_res) = stream.next().await {
// TODO: evaluate if the logic from gui branch should be added here
}

references.

In #19, the background_sync method spawns two tasks; a sync stream as described, and a periodic (30s interval) check for cross-signing status:

Lines 651 to 687 in 401b91e
// spawned alongside the main sync task, every 30 seconds, this updates:
// - all room data (see the RoomData type)
// - cross-signing status
cx.spawn(|view: WeakEntity<Self>, cx: &mut AsyncApp| {
let mut cx = cx.clone();
async move {
let mut roomdata_interval =
async_time::interval(async_time::Duration::from_secs(30));
roomdata_interval.set_missed_tick_behavior(async_time::MissedTickBehavior::Skip);
loop {
roomdata_interval.tick().await;
let Some(client) = view.read_with(&cx, |view, _| view.user.client.clone())?
else {
break;
};
if let Some(upd) = client.encryption().cross_signing_status().await {
view.update(&mut cx, |this, cx| {
if upd.is_complete() {
this.cross_status = CrossStatus::Active;
} else if upd.has_master || upd.has_self_signing || upd.has_user_signing
{
this.cross_status = CrossStatus::Partial;
} else {
this.cross_status = CrossStatus::Inactive;
}
cx.notify();
})?;
}
view.update(&mut cx, |this, cx| {
this.update_all_rooms(true, cx);
cx.notify();
})?;
}

Worth porting over.

To do

The main thing to change for this issue is actually spawning ClientSyncActor after login. It requires a client, so login/restored session is required.

Optionally, add messages, at least a SyncError(e), and forward them to tui Lattice.

Add a SyncStatus enum like in #19, which should be rendered in e.g. a title bar, or status line, depending on the tui layout.

Extras

In #19, the response is actually used:

Lines 625 to 643 in 401b91e
match sync_response {
Ok(_) => {
let rooms = client.joined_rooms();
view.update(&mut cx, |app, cx| {
app.user.room_list = rooms;
if app.sync_status != SyncStatus::Syncing {
app.sync_status = SyncStatus::Syncing;
}
cx.notify();
})?;
}
Err(e) => {
let err = SharedString::from(e.to_string());
view.update(&mut cx, |app, cx| {
app.sync_status = SyncStatus::Error(err);
cx.notify();
})?;
}
}

The UI responds to the sync state change, and displays either "Syncing", or "Sync error".

For now, the simplest is to just ignore the response.
Handling sync errors would come later on.
And the best would be implementing a TUI-friendly notification display system with its own actor. I like nvim-notify a lot visually, so something similar to that would have to be implemented on the tui side.

Supervisors

The currently added supervisors are:

Lines 48 to 56 in 70c3a0e
/// Supervisor for chat-related functionality.
/// (rooms, timelines, search, indexing)
pub chat: Option<ActorRef<ChatSupervisor>>,
/// Supervisor for media-related functionality.
/// (uploads, downloads, caching, indexing)
pub media: Option<ActorRef<MediaSupervisor>>,
/// Supervisor for export-related functionality.
/// (export jobs)
pub export: Option<ActorRef<ExportSupervisor>>,

I can't exactly plan out what to call them, or if they'll be used at all, as of writing. That'll be decided later.
I think new supervisors/actors should come naturally when necessary, these are more like examples I added.

**Focus**: Implementing Sync actor + Supervisors ## Notes ### Sync actor After login, the first thing to do would be setting up background sync, like in the old version and #19 (there it's done via `ExportApp::background_sync` and a detached task). I already have `actor/sync` as a port of that method. The nice thing about using a stream and intercepting sync responses is possibly propagating the error to e.g. shut down any actors depending on bg sync (which, from my understanding of the sdk, would be most functionality one would want). That's what the comment in https://l2.stylism.moe/kir68k/lattice/src/commit/70c3a0e0a5e8442645eb1c02633eaf3c999acc5f/src/actor/sync.rs#L42-L44 references. In #19, the `background_sync` method spawns *two* tasks; a sync stream as described, ***and a periodic (30s interval) check for cross-signing status***: https://l2.stylism.moe/kir68k/lattice/src/commit/401b91e21642dff891ef448621acab66f1c0a8ac/src/ui/mod.rs#L651-L687 Worth porting over. #### To do The *main* thing to change for this issue is actually spawning `ClientSyncActor` after login. It requires a client, so login/restored session is required. Optionally, add messages, at least a `SyncError(e)`, and forward them to tui `Lattice`. Add a `SyncStatus` enum like in #19, which should be rendered in e.g. a title bar, or status line, depending on the tui layout. #### Extras In #19, the response is actually used: https://l2.stylism.moe/kir68k/lattice/src/commit/401b91e21642dff891ef448621acab66f1c0a8ac/src/ui/mod.rs#L625-L643 The UI responds to the sync state change, and displays either "Syncing", or "Sync error". For now, the simplest is to just ignore the response. Handling sync errors would come later on. And the best would be implementing a TUI-friendly notification display system with its own actor. I like `nvim-notify` a lot visually, so something similar to that would have to be implemented on the tui side. ### Supervisors The currently added supervisors are: https://l2.stylism.moe/kir68k/lattice/src/commit/70c3a0e0a5e8442645eb1c02633eaf3c999acc5f/src/app/mod.rs#L48-L56 I can't exactly plan out what to call them, or if they'll be used at all, as of writing. That'll be decided later. I think new supervisors/actors should come naturally when necessary, these are more like examples I added.
kir68k added this to the a new start project 2026-04-30 12:02:37 +02:00
Sign in to join this conversation.
No description provided.