Track Google Cloud Pub/Sub operations in your test diagrams using the Kronikol.Extensions.PubSub NuGet package. This extension wraps PublisherClient and SubscriberClient to capture publish/subscribe operations.

Using a shared library or abstraction layer? If your code doesn't use the Pub/Sub SDK directly — e.g. it goes through a shared messaging library, wrapper, or custom abstraction — this extension won't be able to intercept the underlying calls. See Tracking Custom Dependencies for alternative approaches including MessageTracker and TrackingProxy<T>.

dotnet add package Kronikol.Extensions.PubSub

using Kronikol.Extensions.PubSub;

var publisher = await PublisherClient.CreateAsync(topicName);
var trackingPublisher = new TrackingPublisherClient(publisher, new PubSubTrackingOptions
{
    ServiceName = "PubSub",
    CallerName = "OrdersApi",
    CurrentTestInfoFetcher = () => (TestContext.CurrentTestName, TestContext.CurrentTestId)
});

await trackingPublisher.PublishAsync("Hello, Pub/Sub!");

var subscriber = await SubscriberClient.CreateAsync(subscriptionName);
var trackingSubscriber = new TrackingSubscriberClient(subscriber, new PubSubTrackingOptions
{
    ServiceName = "PubSub",
    CallerName = "WorkerService",
    CurrentTestInfoFetcher = () => (TestContext.CurrentTestName, TestContext.CurrentTestId)
});

await trackingSubscriber.StartAsync(async (msg, ct) =>
{
    // Process message
    return SubscriberClient.Reply.Ack;
});

Google Cloud Pub/Sub uses gRPC internally, so DelegatingHandler interception is not viable. Instead, this extension uses a wrapper/decorator pattern:

• TrackingPublisherClient wraps PublisherClient and logs publish operations
• TrackingSubscriberClient wraps SubscriberClient and intercepts the message handler callback

Both wrappers use PubSubTracker as a central logging helper. It implements ITrackingComponent and handles request/response logging with RequestResponseMetaType.Event for messaging semantics.

GCP Pub/Sub uses full resource paths like projects/my-project/topics/my-topic. At Detailed verbosity, short names are extracted:

• projects/my-project/topics/my-topic → my-topic
• projects/my-project/subscriptions/my-sub → my-sub

• Label: Operation name (e.g. Publish)
• Content: Omitted
• URI: pubsub:///my-topic

• Label: Operation with target (e.g. Publish → my-topic, Receive ← my-sub)
• Content: Message data (UTF-8 text)
• URI: pubsub:///my-topic

• Label: Full info including resource paths
• Content: Message data + response details
• URI: pubsub:///projects/p/topics/my-topic

Recommended. Decorates all existing PublisherClient and SubscriberClient registrations with tracking wrappers, and registers a singleton PubSubTracker. IHttpContextAccessor is automatically resolved from DI.

// In your test's ConfigureTestServices:
services.AddPubSubTestTracking(options =>
{
    options.ServiceName = "PubSub";
    options.CallerName = "OrdersApi";
    options.CurrentTestInfoFetcher = CurrentTestInfo.Fetcher;
});

This uses DecorateAll<PublisherClient> and DecorateAll<SubscriberClient> internally — production code that resolves PublisherClient or SubscriberClient from DI will receive the tracking subclass transparently. No changes to production code required.

v2.27.14 Breaking Change: TrackingPublisherClient now inherits from PublisherClient (previously a composition wrapper). TrackingSubscriberClient now inherits from SubscriberClient. The Inner property and existing API remain available.

new PubSubTrackingOptions
{
    ServiceName = "PubSub",
    CallerName = "OrdersApi",
    Verbosity = PubSubTrackingVerbosity.Detailed,
    CurrentTestInfoFetcher = () => (testName, testId)
}

v2.23.0+ Dual-Resolution: PubSubTracker accepts an optional IHttpContextAccessor? httpContextAccessor constructor parameter for resolving test identity from HTTP request headers when running inside the SUT's request pipeline. See HTTP Tracking Setup#Dual-Resolution Test Identity (v2.23.0+) for details. The AddPubSubTestTracking() DI helper (v2.23.11+) resolves this automatically.

PubSubTracker implements ITrackingComponent and auto-registers:

• ComponentName: "PubSubTracker ({ServiceName})"
• WasInvoked: true after first operation
• InvocationCount: Total operations logged

When your application processes Pub/Sub messages on background threads (e.g. inside a pull subscriber or push endpoint), the test framework's TestContext is unavailable. The extension solves this automatically via message attribute propagation.

1. Publisher side: TrackingPublisherClient injects kronikol-test-name and kronikol-test-id into each message's Attributes dictionary before publishing.
2. Subscriber side: TrackingSubscriberClient reads these attributes from each received message and calls TestIdentityScope.SetFromMessage().
3. All subsequent tracking within the message handler resolves to the originating test.

var options = new PubSubTrackingOptions
{
    PropagateTestIdentity = false,
    // ...
};

See Background Thread Correlation#Solution 1b: Automatic Message Header Propagation (v2.34.0+) for the full architecture overview.

• Integration: SQS Extension
• Integration: Amazon DynamoDB Extension
• Integration: Azure Service Bus Extension