Pass `dispatch_id` to actors

[shsms]

What's needed?

The Dispatcher.start_managing currently passes a DispatchInfo and a Receiver[DispatchInfo] to the actor factory.
But the DispatchInfo objects don't have the dispatch ID.

frequenz-dispatch-python/src/frequenz/dispatch/_dispatcher.py

Lines 270 to 272 in ecaca06

	actor_factory: Callable[
	[DispatchInfo, Receiver[DispatchInfo]], Awaitable[Actor]
	],

It should pass the dispatch ID to the actor factory. This would be useful for logging and matching the decision-making of actors with corresponding dispatches, especially when there are multiple active dispatches of the same type.

Proposed solution

No response

Use cases

No response

Alternatives and workarounds

No response

Additional context

No response

[shsms]

Oh but dispatch ids might change. Maybe better to provide a list of the merged dispach ids in DispatchInfo?

[llucax]

Yeah, the DispatchInfo is simplified because it represent merged dispatches. I guess it could provide a list of dispatch IDs that were merged.

Why do you need the dispatch ID though? For me it seems it should be transparent to dispatch consumers.

[shsms]

Why do you need the dispatch ID though? For me it seems it should be transparent to dispatch consumers.

It would be nice to be able to map an action on the edge to a dispatch ID by looking at the logs. This would help with debugging and tracing the causes of actions.

[llucax]

Yeah, good point. I was thinking that in many cases we'll only have one active dispatch, and DispatchInfo will have the data for that dispatch. In extreme cases we could even merge the data too, like using the union of all dispatch targets of all merged dispatches, but that would be more rare. So maybe we can report only the IDs that used by the current DispatchInfo, if it is only using the info from one dispatch ID, it should report only that ID, even if the dispatch was conceptually merged to extend the active time (and avoid a start/stop if there was some overlap), and if the DispatchInfo is really using data from multiple IDs, then include the IDs used to calculate this resulting DispatchInfo only. So basically not include IDs that only marge the duration of the dispatch.