@kbond On the one hand, it simplifies adding features. On the other hand, I'm afraid of lacking incapsulation and spreading internal details, which complicate future extension.

Ok, I understand your concern, what about the following ideas:

1. Add events: before the MessageGenerator yeilds a message, it dispatches an event that has the context and listeners can manipulate the message (turn it into an envelope with stamps). I'm thinking this doesn't fully address your concern though.
2. Extract most of the logic from MessageGenerator into an abstract BaseMessageGenerator (or another object entirely). We then can create a MessengerMessageGenerator that takes this data (object, time, next time, trigger) and wraps in an envelope. In this case we choose to make this internal data available in a stamp. This would allow removing the hard-dependency on messenger.

I'm very open to other ideas!

I might have something by mixing your approach and the one in #50085: we could imagine an intermediary class, not bound to Messenger, yield from the generator.
Then we attach it to the stamp in the SchedulerTransport. Direct users of the MessageGenerator can decide whether to use or not the provided context, or extend it, and as such we don't introduce any hard dependencies on Messenger.

See a draft here: https://github.com/symfony/symfony/compare/6.3...tucksaun:symfony:scheduler/generator-context?expand=1

Nice (simple) approach! You chose not to add the next run timestamp? (I don't have a strong opinion on this as it can be retrieved from the trigger).

What do you think about including the schedule name? This is important context for me. Should it be added to the MessageContext, done like in #49864, or something else?

You chose not to add the next run timestamp.

I didn't think about it tbh, I just wanted to draft quickly if this could be a way to do things or not.
But I like it, so I could easily add it if we say that I should open a PR with this approach.

What do you think about including the schedule name

In fact, I started to pick your change but then I was confused: should it go into the schedule or the generator? 🤔
So I went back to the same "draft" approach and left it aside for now.
Also, I was wondering, isn't it kind of available within the ReceivedStamp (in the context of Messenger only though)?

I didn't think about it tbh, I just wanted to draft quickly if this could be a way to do things or not.

I think it can't hurt to add. This will provide the expected next run time which may or may not match TriggerInterface::getNextRunDate().

But I like it, so I could easily add it if we say that I should open a PR with this approach.

I say open a PR - I like your approach better than this one. @upyx, what do you think?

In fact, I started to pick your change but then I was confused: should it go into the schedule or the generator?

I've struggled with this myself. The Schedule object itself doesn't have access to it's name. This is configured with the AsSchedule service attribute so it's only currently available in SchedulerTransportFactory as a service alias. I think it makes sense as an optional argument for MessageGenerator - then could be added to your MessageContext object.

Since MessageGenerator::__construct() takes the $checkpoint as a string|CheckpointInterface, if it's a string and no $name is passed, we could use that.

Also, I was wondering, isn't it kind of available within the ReceivedStamp (in the context of Messenger only though)?

It is, and marked with the schedule transport name (schedule_<name>). This is how I'm accessing it now (by removing schedule_). So, if we don't add, I'll continue to use this.

For some context, I'm working on a generic messenger-monitor bundle that has scheduler support. This is why I want all this context. In this bundle, a "monitored message" has queued_at, received_at and handled_at timestamps. This allows for some nice reporting. Currently, for messages that are from a scheduler transport, the queued_at and received_at are identical (because scheduled messages aren't async). My plan, once this triggeredAt value is available, is to set this as the queued_at value for these monitored messages. This will allow reporting on how far off the expected run time and the actual run time are. I think this is what you were looking to do in #50085.

I think this is what you were looking to do in #50085.

This is not the same reason but this requires the same data indeed 😃

I say open a PR - I like your approach better than this one

Done. See #50130

Close in favor of #49792