Skip to content

Read/fork handlers run blocking git subprocesses on the tokio runtime (no spawn_blocking, no timeout) #204

Description

@beardthelion

Surfaced during review of #196 (pre-existing; git/store.rs and the fork clone are untouched by that PR's diff, so splitting here rather than widening #196's scope).

fork_repocrates/gitlawb-node/src/api/repos.rs:1567 runs std::process::Command::new("git").args(["clone","--mirror",…]).output() inside the async handler. output() blocks the worker thread; a git clone --mirror of a non-trivial repo can take minutes and there is no timeout, unlike other git walks in this file that use tokio::task::spawn_blocking (repos.rs:67,110,661,1143) or tokio::process::Command.

Read handlerslist_commits/get_tree/get_blob call store::{resolve_head,log,ls_tree,read_file} (api/repos.rs:360-361,397,443,481), which are synchronous std::process::Command::output() calls (git/store.rs:92-231). A slow disk or large repo blocks a worker for seconds; with a finite worker pool a handful of concurrent /commits, /tree, /blob, or one /fork can starve the runtime, including /health and /ready.

Impact: availability/reliability regression; git_service_timeout_secs is bypassed on these paths.

Fix direction: wrap the blocking store calls (and the fork clone) in spawn_blocking bounded by tokio::time::timeout(git_service_timeout_secs, …), returning AppError::Timeout. Verified real by execution during the #196 review.

Metadata

Metadata

Assignees

No one assigned

    Labels

    crate:nodegitlawb-node — the serving node and REST APIkind:securityVulnerability fix or hardeningsev:highMajor break or real security/trust risk, no easy workaroundsubsystem:apiNode REST API request/response surfacesubsystem:storageBlob/object store, Arweave, IPFS, archives

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions