Handler receives the envelope instead of the message it was registered for
まだ誰も着手していません。
評価
調査の方向性
Read Worker.php, ConsumeFinalHandler.php, and the guide at docs/guide/en/messages-and-handlers.md:108; trace how IdEnvelope, DelayEnvelope, and FailureEnvelope move through the consume pipeline. First resolve the contract choice raised in the issue, especially alongside the #338 Worker and pipeline rework. Done means handlers receive the intended message or envelope contract consistently, with the guide and behavior agreeing.
索引モデルが issue の本文から書いたものです。
説明
Worker::process() passes the message into the consume pipeline exactly as it arrived, and ConsumeFinalHandler hands that to the handler. Nothing unwraps an envelope on the way, so a handler written the way the guide writes it breaks as soon as the message is wrapped.
The documented handler (docs/guide/en/messages-and-handlers.md:108):
public function handle(MessageInterface $message): void
{
assert($message instanceof SendEmailMessage);
$this->mailer->send($message->to, $message->subject, $message->body);
}
Called with an adapter-assigned id, which is the normal asynchronous path:
$worker->process(new IdEnvelope($message, 'id-42'), 'test');
With zend.assertions=1:
MessageFailureException: Processing of message #id-42 is stopped because of an exception:
assert($message instanceof SendEmailMessage).
With zend.assertions=-1, the production default:
Warning: Undefined property: Yiisoft\Queue\Message\IdEnvelope::$to
sending to: NULL
No error, and the work is done against empty values. DelayEnvelope and FailureEnvelope behave the same way. Call path: Worker.php:45 → ConsumeMiddlewareDispatcher → ConsumeFinalHandler.php:21.
Worth deciding which contract is meant:
- unwrap in
Workerbefore dispatching, so a handler always receives the message type it was registered for, and offer the envelope separately to handlers that want the metadata, or - keep passing the envelope and change every handler example in the guide to unwrap first (
$message instanceof Envelope ? $message->getMessage() : $message), sinceassert()is not a guard in production.
InMemoryAdapter happens not to trigger this because it stores the unwrapped message, but any adapter that stores what push() returned does.
#338 reworks Worker and the pipeline around it, so this probably wants deciding before that lands.
- 主要言語
- PHP
- スター
- 60
- フォーク
- 32
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
yiisoft/queue のほかの issue
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
-
難易度 4/5 1〜2日 初心者へのやさしさ 47/100
-
難易度 3/5 1〜2日 初心者へのやさしさ 54/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
似ている issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
grokability/snipe-it#19857 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 92/100
メンテナーはふだん 1 日以内に返信
-
Authentication / Authorization Feature: Volunteer
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 64/100
WordPress/mcp-adapter#399 ·
メンテナーはふだん 1 日以内に返信