PrismLibrary / PrismLibrary/Prism

[Enhancement] Add awaitable Publish for async subscribers

Open
#3,396 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
C#
Stars
6.8k
Forks
1.6k
Avg merge
2d 1h
Merged PRs (30d)
1

Description

Summary

Propose adding a new event type, FanOutFanInEvent<TPayload> or AsyncPubSubEvent<TPayload>, to Prism.Events that supports asynchronous subscribers (Func<TPayload, Task>) and an awaitable Publish method.

Unlike PubSubEvent<TPayload>, this event would return a Task from Publish, allowing publishers await completion of all subscribed handlers or CancellationToken trigger. This would preserve the familiar publish/subscribe model from EventBase, while making event handling more natural in modern async/await-based applications.

API Changes

Example shape of the proposed API:

class FanOutFanInEvent<TPayload> : EventBase
{
    public SubscriptionToken Subscribe(Func<TPayload, Task> action)
    { 
        // ...
    }

    /// returns Task that completes when all handlers have completed processing
    /// or cancellationToken has been triggered
    /// cancellationToken is not used to cancel the handlers, it is only used to cancel
    /// waiting for the handlers to complete
    public async Task Publish(TPayload payload, CancellationToken cancellationToken = default)
    {
        List<Func<TPayload, Task>> executionStrategies = ...;

        await Task.WhenAll(executionStrategies.Select(x => x.Invoke(payload)))
            .WaitAsync(cancellationToken);
    }
}
  • Publish returns a Task that completes when all handlers complete or if the provided CancellationToken is cancelled, it cancels only the waiting operation, not the subscriber handlers themselves
  • Exceptions from handlers could be surfaced using Task.WhenAll behavior or can be manually Aggregated
  • Could support existing Prism threading semantics such as PublisherThread, BackgroundThread, and UIThread

Threading Model

One important aspect of this proposal is that it can support different threading models, similar to existing Prism event subscriptions:

  • PublisherThread: today, PubSubEvent.Publish completes only after all handlers have finished executing and propagates subscriber exceptions back to the caller. The proposed event would preserve similar semantics, while allowing handlers to be asynchronous and the publisher to await overall completion.
  • BackgroundThread: handlers can be scheduled onto background execution.
  • UIThread: handlers can be dispatched through the existing synchronization context model.

This would make the new event type feel consistent with the current Prism eventing model, rather than introducing a completely separate abstraction.

Intended Use Case

In modern .NET applications, almost all event subscribers perform asynchronous work such as:

  • HTTP requests
  • file I/O

Today, native support for Task-based subscribers would make Prism events feel much more natural in async/await workflows.

The proposed Publish behavior also has strong conceptual similarity to regular PubSubEvent.Publish: a publisher raises an event and all subscribers are invoked. The difference is that this new event type gives the publisher an awaitable completion point, making it possible to coordinate continuation logic after all handlers have finished.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the existing EventBase and PubSubEvent APIs in Prism.Events to understand current subscription and threading semantics. Define the new async event type and settle its Publish cancellation, exception, and PublisherThread, BackgroundThread, and UIThread behavior; done requires an agreed API and coverage for awaited subscriber completion.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
backend-api-design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.