Missing component in components directory does NOT cause error message nor exception in a gRPC service

In what area(s)?

/area runtime

/area operator /area placement /area docs /area test-and-release

What version of Dapr?

1.0.0

Output of git describe --dirty

Expected Behavior

With a gRPC service, when a pubsub component is missing from the .dapr/components directory and that missing pubsub component is used by a service subscribing to events and specifying that the missing component be used, an error message should show up on the console or log that clearly states the pubsub component is MISSING.

In other words, when my service software subscribes to a pubsub component that is not present, Dapr needs to generate an error message at least.

Even better would be a way to throw an exception in the service software stating that the component subscribed to is not present. An exception would immediately bring attention to the issue, while a mere console error message may not be so visible.

Note that at least when using the .NET SDK with gRPC services, that attempting to publish an event to a missing pubsub component does cause an exception in the service code. For example: Dapr.DaprException: Publish operation failed: the Dapr endpoint indicated a failure. See InnerException for details. ---> Grpc.Core.RpcException: Status(StatusCode="InvalidArgument", Detail="pubsub svs-pubsub-asbtopic not found")

Actual Behavior

When a pubsub component is missing and is subscribed to by a gRPC service, Dapr says nothing to indicate anything is wrong. This means a subscribing service can be happily running for days with the operators thinking all is OK, yet it is not receiving messages and there is no indication anything is wrong.

Here is the output when I had previously removed 2 of the 3 pubsub components from the components directory, but kept the subscription registrations to all 3 in the service code. There is no indication of anything wrong:

You're up and running! Dapr logs will appear here.

time="2021-03-06T14:16:38.2572424-05:00" level=info msg="app is subscribed to the following topics: [svcADemoEvents1] through pubsub=pubsub" app_id=serviceB instance=A-GeorgeXPS1 scope=dapr.runtime type=log ver=1.0.0 time="2021-03-06T14:16:38.2582381-05:00" level=info msg="app is subscribed to the following topics: [svcADemoEvents1] through pubsub=svs-pubsub-asbtopic" app_id=serviceB instance=A-GeorgeXPS1 scope=dapr.runtime type=log ver=1.0.0 time="2021-03-06T14:16:38.2582381-05:00" level=info msg="app is subscribed to the following topics: [svcADemoEvents1] through pubsub=svs-pubsub-envvarsecrets-asbtopic" app_id=serviceB instance=A-GeorgeXPS1 scope=dapr.runtime type=log ver=1.0.0

The latter 2 pubsub components had been removed from components directory, even though the subscription code remained in the service as shown below:

   public override Task<ListTopicSubscriptionsResponse> ListTopicSubscriptions(Empty request, ServerCallContext context)
    {
        var result = new ListTopicSubscriptionsResponse();
        try
        {
            result.Subscriptions.Add(new TopicSubscription
            {
                // Used with supplied default Redis pubsub component.
                PubsubName = NamesOfQueuesNPubSubs.PubSubDefaultDaprComponent,
                Topic = NamesOfQueuesNPubSubs.ServiceADemoEvents1Topic
            });
            result.Subscriptions.Add(new TopicSubscription
            {
                PubsubName = NamesOfQueuesNPubSubs.PubSubAzServiceBusComponent,
                Topic = NamesOfQueuesNPubSubs.ServiceADemoEvents1Topic
            });
            result.Subscriptions.Add(new TopicSubscription
            {
                PubsubName = NamesOfQueuesNPubSubs.PubSubAzServiceBusEnvVarSecretsComponent,
                Topic = NamesOfQueuesNPubSubs.ServiceADemoEvents1Topic
            });
        }
        catch (Exception ex)
        {
            m_Logger.LogError($"** ServiceB.ListTopicSubscriptions() threw exception ex={ex}");
            throw;
        }
        return Task.FromResult(result);
    }

Note that the above code did not cause an exception.

Steps to Reproduce the Problem

With a gRPC service in the AppCallback interface implementation, subscribe to one or more topics using the default pubsub component. Then test it to make sure the subscription actually receives and processes published events. Then stop the gRPC service. Next remove the pubsub.yaml component from the .dapr/components directory. Restart the gRPC service and you will see that it successfully subscribes to the topic, and says so, even though the component implementing the subscription is gone and will not work.

Release Note

RELEASE NOTE: