Run the periodic memory sync loops inside the module

[YellowSnnowmann]

Depends on nothing; unblocks the last phase of openhuman#5560.

Why

openhuman#5560's final phase deletes the second, in-process memory engine the host boots. Everything that engine was doing then has to run here. The queue worker pool and the ComposioHost / ConfigLoader seams already moved. The periodic composio and workspace-source sync loops had not, and three things stopped them working in module mode — each verified at source, each failing quietly rather than loudly.

The three

Cadence read as manual-only. EngineRuntimeConfig::memory_sync_interval_secs() returned Some(0), which effective_interval_secs defines as manual-only, so both loops skipped every source with no error at all. The value now travels in ModuleConfig and the engine answers it.

The Composio credential branch was never selected. composio_config takes its direct branch only when the mode is direct, otherwise it needs a session token; the module answered ComposioMode::default() and Ok(None), so backend mode failed and direct mode was unreachable. Note this could not be fixed by the ComposioHost seam alone — api_key is consulted inside the branch that was not taken. Mode and entity id now travel; the key still resolves through the seam per call, so no credential is stored module-side.

The module's client was not in the global slot. run_composio_connection_with_caps begins at global::client_if_ready(), which was None here. Calling global::init would have built a second MemoryClient over the same SQLite file — two ingestion workers, duplicate extraction and embedding. New global::bind registers the already-built client into both the slot and the per-workspace cache so all three resolution paths converge on one client.

Three decisions worth review

memory_sync_interval_secs defaults to None, not Some(0). The two candidates fail asymmetrically. Some(0) is manual-only: every source skipped, every tick, no error and nothing in the log — indistinguishable from a sync that ran and found nothing, which is the exact failure this field exists to remove. None means "the user chose nothing", which is true of a host that sent nothing, and lands on the same 24h fallback the host applies. Getting None wrong costs a "Manual only" user one background sync per day until their host learns the field: bounded, visible, and still gated by each source's own enabled toggle. Getting Some(0) wrong is invisible by construction.

Backend-mode Composio cannot run here, and now fails by name. session_token() returns Err(NO_BACKEND_SESSION) instead of Ok(None). The old path reached "backend bearer token is not configured", which reads as "signed out" and points a reader at a sign-in that cannot help; the cause is structural — there is no field for a bearer, and a load-time snapshot could not follow a token the host refreshes mid-session. The Composio loop is also gated off unless the mode resolves to direct, because starting it otherwise would list the user's connections every 20 minutes and fail every due one forever, appending a failed audit row each time. The workspace loop starts in every mode; it never touches Composio.

bind refuses a different client for the same workspace. The cache's usual "racing caller wins" rule is free for init, whose caller only wanted a client. A bind caller is already using the one it passed, so handing back someone else's would neither retire the caller's client nor stop its ingestion worker — two would exist and the API would have said fine. Same workspace and same Arc is idempotent; a different workspace rebinds, as init already does for an active-user switch.

What the host must do

Three optional ModuleConfig keys, all #[serde(default)] so an older host still loads a newer module: memory_sync_interval_secs, composio_mode, composio_entity_id.

And one thing it must stop doing. The cdylib carries its own copy of tinymemory-core, so each loop's OnceLock is a different static from the host's. A host that keeps its start_periodic_sync / start_workspace_periodic_sync calls while loading this module gets two pairs of loops over one store, and the in-process claim guard cannot see across that boundary. The host's call site has to go in the same change that deletes the engine it was calling against.

Known degradation

The module's scheduler-gate stub always answers Normal, so these loops do not honour periodic_pause_reason's "signed out" and "user disabled" pauses. Documented where a reader will find it rather than left to be discovered.

Validation

cargo check --workspace --all-targets clean in both workspaces; cargo test --workspace 1927 passing.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 233d8337-436c-4c8d-8731-b043da5a13ad

Warning

Your free Security trial is over. An organization admin can activate billing to continue.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[tinysweeper]

How this change flows

3 changed behaviours across 12 relationships. 4 surrounding behaviours are shown (60 graph nodes walked). 42 further behaviours left out to keep the diagram readable.

flowchart LR
  n0["client_if_ready<br/>changed"]:::changed
  n1["client_returns_a_handle_after_explicit_init<br/>changed"]:::changed
  n2["ModuleConfig<br/>changed"]:::changed
  n3["install"]:::impacted
  n4["test_config"]:::impacted
  n5["...ed_and_only_success_counts_toward_the_cap"]:::impacted
  n6["...e_cap_is_reached_through_successful_opens"]:::impacted
  n1 -->|calls| n0
  n1 -->|tests| n0
  n3 -->|uses| n2
  n4 -->|uses| n2
  n5 -->|calls| n3
  n5 -->|tests| n3
  n5 -->|calls| n4
  n5 -->|tests| n4
  n6 -->|calls| n3
  n6 -->|tests| n3
  n6 -->|calls| n4
  n6 -->|tests| n4
  classDef changed fill:#0d4429,stroke:#238636,color:#e6edf3
  classDef impacted fill:#161b22,stroke:#6e7681,color:#c9d1d9
  classDef flagged fill:#5a1e02,stroke:#d93f0b,color:#ffffff
  classDef blocking fill:#67060c,stroke:#f85149,color:#ffffff

Loading

_{Green: changed behaviour. Grey: surrounding behaviour. Arrows name the call, use, implementation, or test relationship. Orange: has findings. Red: has a finding that blocks the merge.}

[tinysweeper]

tinysweeper found nothing blocking. Approving.

$0.0000 · 0 in / 0 out