use zinit jobs & logs for all long running jobs #24
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
e.g. importing books

make sure it happens in async mode on server and all logs sent to zinit on right source
then show what that source is e.g. servicename.import.something
now go over all long running jobs
make sure nowhere we do logging in the component itself
each service needs to integrate with zinit sdk for logging, process management, job mgmt, ...
hero_books zinit integration issue
Created detailed tracking issue for hero_books: lhumina_code/hero_books#77
Covers 12 areas of improvement:
std::thread::spawn)OperationLoggerwith zinit logs APIhero_books.{op}.{target})development_kristofbranchRelated issues for the overall zinit lifecycle effort
ZinitLifecyclepattern)OServer::run_cli()/ZinitLifecyclestandardhero_embedder zinit integration issue
Created tracking issue: lhumina_code/hero_embedder#9
Already done: Server has full
ZinitLifecycle(Pattern B) withrun/start/stop/status/logssubcommands.Still needed (7 items):
OperationLogger(500-entry buffer) with zinitlogs.insert()ZinitLifecycleto hero_embedder_ui (currently standalone, no subcommands)run.shhero_voice zinit integration issue
Created tracking issue: lhumina_code/hero_voice#6
Current state: Zero zinit SDK integration — uses raw
zinitCLI calls from Makefile.10 items needed:
ZinitLifecycleto hero_voice_server (no subcommands today)ZinitLifecycleto hero_voice_ui (no subcommands today)logs.insert()with structured source nameszinitCLI)zinit_sdk+hero_rpc_serverdependenciesprocess::exit(0))hero_aibroker zinit integration issue
Created tracking issue: lhumina_code/hero_aibroker#24
Already done: OpenRPC server has full
ZinitLifecycle(Pattern B) with all subcommands.Still needed (7 items):
ZinitLifecycleto hero_aibroker_http (currently no lifecycle, direct TCP/socket bind)OperationLogger(500-entry buffer) with zinitlogs.insert()println!/eprintln!→tracing::"OK")Correction applied to all child issues
All 4 repo issues have been updated to correct the scope of zinit integration. In-process long-running operations stay in-process — they work with in-memory state (loaded models, Chrome sessions, vector indexes, streaming connections) and cannot be externalized to zinit subprocess jobs.
What zinit IS used for (across all repos)
ZinitLifecyclepattern — standardrun/start/stop/status/logs/servesubcommands for every binarylogs.insert()— structured source names likehero_books.pdf.mybook,hero_embedder.embed.docszinitCLI calls in Makefiles/scripts with binary subcommandsWhat zinit is NOT used for
In-process operations that depend on runtime memory state:
These stay as
tokio::spawn/std::thread::spawn/spawn_blockingbut log through zinit for centralized visibility.Updated child issues
Status update — 3 of 4 repos complete
All code verified compiling, committed, and pushed.
963f8ca— ZinitLifecycle for 3 binaries, removed custom logging642f88a— UI lifecycle, zinit logging, in-process job tracking, SDK fix972a2e7— lifecycle for 2 binaries, Makefile updatedKey architecture decision: In-process long-running operations (PDF generation, embedding, transcription, streaming chat, etc.) stay as in-process async tasks — NOT zinit subprocess jobs. They work with in-memory state that can't cross process boundaries. Zinit is used for service lifecycle (
ZinitLifecyclepattern), logging (logs.insert()), and health checks.hero_aibroker #24 now also closed
Crates were renamed (
_openrpc→_server,_http→_ui,_client→_sdk) and ZinitLifecycle was already added to the UI binary (commit aaebac1). Both binaries now have full lifecycle.All 4 repos complete: