Heartbeats to decouple job runtime with RescueStuckJobsAfter?

オープン

#682 2024年11月18日に作成コメント 7 件リアクション 0 件担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度: 5/5
見積もり時間: 1週間以上
初心者へのやさしさ: 45/100

issue の種類: 機能追加
明瞭さ: おおむね明確
活発さ: 静か
技術スタック: go, kubernetes
領域: backend, distributed-systems

調査の方向性

Start by reading the RescueStuckJobsAfter behavior and the job lifecycle around running and graceful shutdown states. Define how a heartbeat would indicate that a long-running job is alive, then verify that active jobs are not rescued while abandoned jobs still are.

索引モデルが issue の本文から書いたものです。

説明

Hi there! I'm trying to build a production system leveraging River and I'm liking it so far.

My biggest issue has been that our jobs can take several hours to run, and we're often running into states where a job is "stuck" in a running state because of a Kubernetes job or something (even though we're attempting a graceful shutdown). I don't want to set RescueStuckJobsAfter to be too high, because that might unnecessarily slow down the system.

I don't fully understand why RescueStuckJobsAfter has to be an effective hard max on the runtime of a job. Would it be possible to expose some sort of "job heartbeat" that lets River know that a job is still alive and well, and use that to check whether a job needs to be rescued?

主要言語: Go
スター: 5.7k
フォーク: 179
平均マージ: 2日 19時間
マージ済み PR（30日）: 12

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
リポジトリをフォークし、ブランチを切って変更します。
issue 番号を参照したプルリクエストを送ります。

riverqueue/river のほかの issue

Remote JobCancel() can be silently lost while the notifier is reconnecting (no durable-poll fallback) オープン

難易度 5/5 1週間以上初心者へのやさしさ 45/100

riverqueue/river#1358 · コメント 1 件 · 2026年8月22日に作成
River job stuck at running オープン

難易度 4/5 3〜5日初心者へのやさしさ 35/100

riverqueue/river#1258 · コメント 7 件 · 2026年5月26日に作成
river stuck connected to read-only postgres instance オープン

難易度 4/5 3〜5日初心者へのやさしさ 45/100

riverqueue/river#1225 · コメント 14 件 · 2026年4月22日に作成
Workflow dep resolution leaves `scheduled_at` stale, breaking queue delay monitoring オープン

難易度 4/5 3〜5日初心者へのやさしさ 52/100

riverqueue/river#1185 · コメント 2 件 · 2026年3月25日に作成
Support UniqueOpts without JobStateRunning in ByState オープン

難易度 4/5 3〜5日初心者へのやさしさ 52/100

riverqueue/river#1183 · リアクション 2 件 · 2026年3月24日に作成

riverqueue/river の issue をすべて見る

似ている issue

[Bug]: Event executions make the originating request panic (nil JobInsertResult in queue log middleware) when the OTLP log exporter is enabled オープン

難易度 2/5 1〜3時間初心者へのやさしさ 65/100

zitadel/zitadel#12811 · 2026年9月23日に作成
A bare version number is refused with "not one this build knows. It knows 2.0" オープン

bug group: validation priority: low

難易度 2/5 1〜3時間初心者へのやさしさ 75/100

codecheckers/chekhov#51 · 2026年9月23日に作成
Creating worktree from an existing remote branch with a slash in it, has unexpected behaviour オープン

難易度 2/5 1〜3時間初心者へのやさしさ 70/100

k1LoW/git-wt#225 · 2026年9月23日に作成
`Dependency.String()` writes a substvar without its `${}` オープン

難易度 2/5 1〜3時間初心者へのやさしさ 75/100

paultag/go-debian#146 · 2026年9月23日に作成
hab backup config get returns the backup encryption password in plaintext オープン

難易度 2/5 1〜3時間初心者へのやさしさ 75/100

balloob/home-assistant-build-cli#88 · 2026年9月23日に作成

Go の issue をもっと見る