hive-forge: exit after HIVE_FORGE_DEADLINE instead of hanging on a stalled forge
forgejo-api 0.11.1's sync client builds its own reqwest client with no timeout and takes no caller-supplied client (sync.rs: new and with_user_agent are the only constructors), so a forge that accepts a connection and then stalls blocked every typed verb forever. A watchdog thread now starts before the client is built. After HIVE_FORGE_DEADLINE seconds (default 900, five minutes above DOWNLOAD_TIMEOUT) it prints a hive-forge: FAILED: line and exits 75. It bounds the whole command, not each request, and a write may already have landed when it fires; the help text and docs/tools/forge.md say so.
This commit is contained in:
parent
e7a46d9728
commit
ccc6993703
7 changed files with 192 additions and 2 deletions
|
|
@ -20,6 +20,12 @@ markdown-docs > docs/tools/forge-cli.md`.
|
|||
> the `origin` remote of the cwd's git checkout > `$HIVE_FORGE_REPO`
|
||||
(last-resort override, unset by default) > a hard error.
|
||||
`client::Client::from_env` assumes no single repo by default.
|
||||
- Deadline: one invocation runs for at most `$HIVE_FORGE_DEADLINE` seconds
|
||||
(default 900, five minutes above the largest per-request budget). Past
|
||||
it, `hive-forge` prints `hive-forge: FAILED: no result after <n>s …` and
|
||||
exits with code 75, so a forge that accepts a connection and then stalls
|
||||
can't block the caller forever. The command stops wherever it was: a write verb
|
||||
may already have reached the forge, so check its result before retrying.
|
||||
|
||||
## Verbs
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue