Adapter delay support flag
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 56/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- php, rabbitmq, redis
調査の方向性
ExponentialDelayMiddleware、DelayEnvelope、および #272 の hasStatusSupport() 実装から始めます。Redis、インメモリ、AMQP アダプターが DelayEnvelope をどのように処理するかを確認し、その後、middleware が提案された capability flag を使用できる箇所を追跡します。アダプターが delay のサポート状況を一貫して報告し、サポートされていない delay が暗黙的に失敗しなくなれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Proposed new feature or change
ExponentialDelayMiddleware computes the backoff and pushes a DelayEnvelope, but the actual delaying is on the adapter (its docblock says so). Problem: no way to know whether an adapter honors it. Redis and the in-memory adapter just ignore DelayEnvelope, so the message comes back right away - no backoff, just instant retries. AMQP delays fine.
Same story as status() before #272. #191 listed both delay and status as adapter features; #272 did the status half, delay's still open.
Proposal: add hasDelaySupport(): bool, like hasStatusSupport(). Then the middleware can fall back / warn instead of silently dropping the delay.
Ok to go the same route as #272? Happy to PR it - core + redis/amqp.
- 主要言語
- PHP
- スター
- 61
- フォーク
- 31
- 平均マージ
- 1日 7時間
- マージ済み PR（30日）
- 9
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
yiisoft/queue のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
-
status:ready for adoption type:test
似ている issue
-
status/awaiting_triage
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
WordPress/plugin-check#1486 ·
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
az-digital/az_quickstart#6019 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
grokability/snipe-it#19688 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100