If a message type is never sent or never received, this leads to From<$ty> implementations being missing.

The implementation here adds a check and throws and error pointint to the messages.

Closes #13

Hey @drahnr :wave:

could you please

cargo owner --add parity-crate-owner --add github:paritytech:core-devs

for orchestra, orchestra-proc-macro and prioritized-metered-channel? :pray:

Thank you in advance :)

Currently the graph feature is not exposed as part of crate orchestra.

Proposed changeset:

Rename the feature graph of orchestra-proc-macro to dotgraph and expose it via feature dotgraph in the public facing crate orchestra as well.

#[orchestra(gen=AllMessages, ..)]
struct X {
#[subsystem(MsgA, sends: [Unconsumed])
foo: Foo,
#[subsystem(MsgB, sends: [Unconsumed])
bar: Bar,
}

will raise an error about missing enum variant AllMessages::Unconsumed which is non-obvious how to resolve.

Will be obsoleted once #11 is implemented, would possibly make sense to add a sense check to the proc-macro for the time being. CC @MathisWellmann

If a subsystem is having a hard time and it's signal queue becomes full, all the subsequent subsystems will receive the signal much later on. We could have a timeout for completion of all futures, but this would still back pressure on the source of the signal. We could instead track individual timeouts for each send with a FuturesUnordered.

For example, if in the below snippet of generated code sub2 blocks (up to timeout - 10s), then updates to sub3..6 will also be deleayed, leading to a general slowdown, as well as missing on some messages sent between unaffected systems and sub2 which can only be received after the signals are processed.

    /// Broadcast a signal to all subsystems.
    pub async fn broadcast_signal(
        &mut self,
        signal: OverseerSignal,
    ) -> ::std::result::Result<(), SubsystemError> {
        self.sub1.send_signal(signal.clone()).await?;
        self.sub2.send_signal(signal.clone()).await?;
        self.sub3.send_signal(signal.clone()).await?;
        self.sub4.send_signal(signal.clone()).await?;
        self.sub5.send_signal(signal.clone()).await?;
        self.sub6.send_signal(signal.clone()).await?;

        let _ = signal;
        Ok(())
    }

The generated code strongly relies on the consumed message type, which complicates the generated code significantly. Using a marker type and additional trait to annotate sent and consumed types, would likely be advantageous to reduce complexity and have one defining information anchor.

since it's required to have the Context: SubsystemContext around to spawn a task, #[overseer::contextbounds(..)] was introduced. This could be avoided by allowing every Sender: ${Subsystem}SenderTrait to also implement a new trait SpawnTask or even trait SpawnNamed, since all that is required is sending a future to the overseer. Common practice for i.e. the job based subsystems and some subsystems. This could alleviate the need for that second proc-macro entirely and simplify the code based and improve compilation speed (hypothesis).

Unify the sender API and only provide one API async fn send_message(msg: ..). bounded or unbounded is an impl detail that should be provided at the subsystem declaration, i.e.#[subsystem(DisputeDistributionMessage, sends: [ RuntimeApiMessage, DisputeCoordinatorMessage as unbounded, NetworkBridgeMessage,])] and thesend_messageimpl will take care of using the correct channels.ChannelsOutwill also contain less entries.

   #[subsystem(DisputeDistributionMessage, sends: [
              RuntimeApiMessage,
              DisputeCoordinatorMessage as unbounded,
              NetworkBridgeMessage,
])]

and the send_message impl will take care of using the correct channels. ChannelsOut will also contain less entries.

Quoting from Polkadot issue https://github.com/paritytech/polkadot/issues/5517:

Extend the metered::* types to have send::<Priority = Standard> generic argument which can either be Droppable, Low, Standard, High (not an enum!, all marker types).

Pros:

• allow a more nuanced handling of messages
• keep the semantics simple

Cons:

• Complexity:
  • Will require more logic around sending
  • Requires multiple channels per subsystem