Documentation on persistent subscription to $all with gRPC

Clients .NET
1

Hi,
I was having a look at the “new” persistent subscription to $all stream and wanted to test it. As I understood, it’s possible to create it only through the gRPC client, not from the ADMIN.

The following article
https://developers.eventstore.com/clients/grpc/persistent-subscriptions.html#creating-a-subscription-group

does not seem to have any details on the $all stream. Is there any available sample that docs are not mentioning?

Also, is there any recommended strategy on how to avoid creating the same subscription group twice? Or it should handle the exception and carry on if already existing?

Finally, the documentation mentions

you should assume that the subscription already exists.

Where should the $all subscription be created then if not in the application code?

I suspect this documentation hasn’t been updated to include the new $all persistent subscription. Looking forward to getting some advice on recommended practices. My intention is to initialize persistent subscription on startup with an IHostedService but ensure, first, that the subscription group exists.

Thanks!

2

The client supporting persistent subscriptions to $all is not release yet and this is why it is not documented.

1 Like
3

@diego.martin, as Alexey mentioned, the docs and client releases are in progress, you can see some snippets in the.NET Client repository: https://github.com/EventStore/EventStore-Client-Dotnet/blob/master/samples/persistent-subscriptions/Program.cs#L59

Regarding questions about creating it twice, the second call will fail with the “already exists” status code. See more:

You could try to create a subscription each time and ignore failure if the status means that it already exists.

1 Like
4

Brilliant. Thanks a lot for the info.

1 Like
5

Unfortunately, the gRPC client lacks the List or Get operation, although it’s available in HTTP API.

Try-catch works, but you need to look at the error message and ensure that it contains AlreadyExists magic string to ensure the exception is indeed caused by the persistent projection being previously created.

IMO these operations should also be exposed via Ops tools like Terraform, but we don’t have an EventStoreDB provider, only ES Cloud provider.