A webhook event can be accepted and never land, leaving newgit.dev behind GitHub

オープン
#353 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
rust
領域
backend, cli

調査の方向性

Start at POST /v1/webhooks/github and trace how queued pulls are handled during deploys and how failures are logged; the issue does not name source files or tests. Reproduce or inspect the lost pull path, then consider how newgit remote show could report a pull that is stuck or abandoned. Done means identifying when queued pulls stop progressing and making that state visible.

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

説明

On 2026-11-06 GitHub's push event for #350 got a 202 from POST /v1/webhooks/github, but the commit never reached main on newgit.dev. It sat behind GitHub for about 40 minutes. Redelivering the same event from GitHub landed it in 5:20 with the usual landed log.

Why the first one was lost is unknown; its log falls outside what was captured. It was queued while a deploy was on its way, so a deploy interrupting the pull is a suspect, not a finding.

It's silent, which is the real problem: nothing says newgit.dev is behind. It recovers with a redelivery or newgit pull --remote github.

What would help:

  • Find out what happens to a queued pull across a deploy, and when it gives up without landing.
  • Make a stuck or abandoned pull visible, for example in newgit remote show.
主要言語
Rust
スター
0
フォーク
0
平均マージ
7時間 27分
マージ済み PR(30日)
140

環境構築

このプロジェクトの環境構築ファイルはまだ確認していません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

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

Spheroman/newgit のほかの issue

Spheroman/newgit の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。