After routing all commands through the warm server (#48), core/operations.js (44 ops) has several smells to audit and fix:
- Boilerplate duplication.
messagesGet and messagesContext repeat the same resolveSource + fetchLive + live/both/archive/live-fallback if-chain almost verbatim (likely messagesList/messagesSearch too). Consolidate the source-resolution + fallback pattern into one shared helper.
- Thin passthroughs. ~23 ops are one-line forwards to
ctx.telegramClient / ctx.messageSyncService. Don't hand-write a wrapper per method — expose the client methods generically (a passthrough mechanism, adjusting the client API if needed) and hand-write only the composite ops.
- API adaptation that shouldn't exist. CLI handlers build per-op
args objects mapping CLI options to op params (e.g. messagesSearch maps ~12 fields; same in runSendText). We control both sides — align the internal/CLI API so a command's params pass through as ONE object, no per-call adaptation. Collapsing these turns many ops into thin wrappers forwardable by one mechanism.
- Pre-invoke ping latency.
runOperation → ensureServer PINGs the server (1 round-trip) before invoke (another round-trip) on EVERY command — 2 loopback RTs on the warm path. Optimize: invoke directly; only start the server on a connection failure (ECONNREFUSED / missing control.json). Saves a RT per command.
- Minimize Telegram API calls. Audit each op's TG request count and reduce round-trips (e.g. repeated metadata lookups).
- Live/archive consistency. Within a single
messagesContext/messagesGet call, target + context come from one source (good). Audit the --source archive→live fallback (usedLiveFallback) and the cross-command risk: search hits from live then context from archive = inconsistent snapshot. Document/guard so results aren't silently mixed.
Refs: core/operations.js, core/command-context.js (runOperation), core/control-client.js (ensureServer). Related: #43 (thin handlers), #40 (bicycles).
After routing all commands through the warm server (#48),
core/operations.js(44 ops) has several smells to audit and fix:messagesGetandmessagesContextrepeat the sameresolveSource+fetchLive+ live/both/archive/live-fallback if-chain almost verbatim (likelymessagesList/messagesSearchtoo). Consolidate the source-resolution + fallback pattern into one shared helper.ctx.telegramClient/ctx.messageSyncService. Don't hand-write a wrapper per method — expose the client methods generically (a passthrough mechanism, adjusting the client API if needed) and hand-write only the composite ops.argsobjects mapping CLI options to op params (e.g.messagesSearchmaps ~12 fields; same inrunSendText). We control both sides — align the internal/CLI API so a command's params pass through as ONE object, no per-call adaptation. Collapsing these turns many ops into thin wrappers forwardable by one mechanism.runOperation→ensureServerPINGs the server (1 round-trip) beforeinvoke(another round-trip) on EVERY command — 2 loopback RTs on the warm path. Optimize:invokedirectly; only start the server on a connection failure (ECONNREFUSED / missingcontrol.json). Saves a RT per command.messagesContext/messagesGetcall, target + context come from one source (good). Audit the--source archive→live fallback (usedLiveFallback) and the cross-command risk: search hits from live then context from archive = inconsistent snapshot. Document/guard so results aren't silently mixed.Refs:
core/operations.js,core/command-context.js(runOperation),core/control-client.js(ensureServer). Related: #43 (thin handlers), #40 (bicycles).