Add Config to Disable Sidecar Requests to /dapr/config and /dapr/subscribe

[tomflenner]

Create a new proposal that target to answer the need of dapr/dapr#8224

[WhitWaldo]

As the end result is seeing fewer logs, I would propose a few changes:

• Rather than putting a flag somewhere that can be easily forgotten about, if there are no configuration components loaded by the runtime, simply disable the configuration functionality altogether and don't log any of it

PubSub is a little more complicated because of the opportunity for programmatic endpoints, but:

• If there's no pubsub component loaded by the runtime, simply disable all pubsub functionality altogether and don't log any of it
• If there is a pubsub component loaded and the CLI flag/argument is specified, disable all pubsub programmatic functionality (e.g. the flag disables programmatic functionality necessitating the dapr/subscribe endpoint) and relevant logging. In other words, the CLI flag/argument disables the programmatic pubsub functionality, not necessarily the rest of PubSub, if a pubsub component is provided.

One more thought on the last bullet point though: Even if the CLI flag/argument is set to disable the programmatic endpoint, I think the runtime should attempt to load dapr/subscribe once after a reasonable delay (e.g. 10 seconds) because if there are endpoints programmatically represented in there, Dapr should surface that there might be a mistake here with a single clear message along the lines of /dapr/subscribe is populated with programmatic PubSub subscriptions - did you mean to disable programmatic PubSub subscriptions via the <whatever> flag? I'm thinking ahead to future questions in Discord of users not realizing the purpose of the CLI flags and just pasting them in from some example and not understanding why programmatic endpoints don't work. Here, this log makes it clear.

Otherwise, this looks great!

[tomflenner]

I agree on your extended proposal of a multistep consideration with some logging on potential pitfall e.g the flag is set by error and there is no more programmatic subscription when pubsub component is registered.

This would come with well written documentation for sure !

To be sure that I understand correctly the last bullet point - we are not hitting the /dapr/subscribe but we are displaying a log that will help to see that programmatic subscription is not registered on runtime side ? Or you really want to see that there are some potential subscriptions that can be hidden due to that flag in this particular setup

[WhitWaldo]

To be sure that I understand correctly the last bullet point - we are not hitting the /dapr/subscribe but we are displaying a log that will help to see that programmatic subscription is not registered on runtime side ? Or you really want to see that there are some potential subscriptions that can be hidden due to that flag in this particular setup

I envision a scenario where someone has launched one of the many examples or quickstarts which registers a number of programmatic endpoints to trial Dapr's PubSub capability. They google something like "Dapr CLI" and Gemini, bless it, yields a CLI prompt that contains your programmatic PubSub disable flag. They blindly copy and paste it into their command prompt and cannot figure out why the PubSub example isn't working - none of the programmatic endpoints appear to do anything. Reason being - they're disabled by the flag.

So this would serve as a backup - if the runtime is generally disabling programmatic PubSub despite the presence of a PubSub component, check to see if it appears that there are PubSub topic endpoints registered. If there aren't, don't mention anything about it in the logs - programmatic PubSub is disabled and that's the last of it. But if there are any such endpoints, put one warning in the logs that notes that while programmatic PubSub has been disabled because of the flag, this might be a mistake because there are programmatic endpoints that were registered on the application.

Otherwise, I envision this being another scenario that becomes difficult to troubleshoot - why aren't programmatic PubSub endpoints working? Don't know - the logs don't say anything about PubSub. Why not? Because you added a flag to disable the programmatic endpoints. Help future us - if it looks like disabling the endpoint was a mistake, log it.

[tomflenner]

if the runtime is generally disabling programmatic PubSub despite the presence of a PubSub component, check to see if it appears that there are PubSub topic endpoints registered.

This is by having the runtime call /dapr/subscribe of the app right ? So we still introduce a http request from the runtime to the app in this particular scenario where it's probable that we do want programmatic PubSub.

If it's the case - I try to figure out if there is any real world scenario where we want to disable this init request while using PubSub component with declarative subscription only for example. In that one, we might dont want any noise that maybe ?

[WhitWaldo]

If it's the case - I try to figure out if there is any real world scenario where we want to disable this init request while using PubSub component with declarative subscription only for example. In that one, we might dont want any noise that maybe ?

I think the only reason you wouldn't ping /dapr/subscribe is if no PubSub component was defined at all, meaning that it doesn't matter if that endpoint is there and populated as nothing would be routed in the first place.

Otherwise, it should be checked to see if there are otherwise valid endpoints on the app despite the disabling flag so the discrepancy can be warned about in logs and then disabled (because the flag is set).

[tomflenner]

What if you're working with a .NET minimal API and using declarative subscriptions? In that case, calling /dapr/subscribe doesn't really make sense.

However, you'll still receive an HTTP call to that endpoint, which could result in unnecessary log entries - both in your app and in the Dapr runtime - possibly including warnings about programmatic subscriptions being disabled.

Is this the desired behavior?

[WhitWaldo]

What if you're working with a .NET minimal API and using declarative subscriptions? In that case, calling /dapr/subscribe doesn't really make sense.

However, you'll still receive an HTTP call to that endpoint, which could result in unnecessary log entries - both in your app and in the Dapr runtime - possibly including warnings about programmatic subscriptions being disabled.

Is this the desired behavior?

Until the app has loaded, the runtime couldn't possibly know if there are any programmatic subscriptions set up or not and it would only know this by checking this endpoint.

Yes, your way of having the flag just disable checks against that endpoint altogether would remove all logging whatsoever, but I personally would rather know from the logs that I possibly misconfigured something over reduced verbosity around checking the endpoint at startup.

Put another way, I'd rather typically address something like this with a source analyzer, but the application doesn't know that which is only available to the runtime. So that leaves the runtime as the only entity with the full picture, which means I would favor it checking "just in case" and logging about the inconsistency over not.

[JoshVanL]

+1 binding

Looks great to me 😄

I would be hesitant to special case calling the subscribe endpoint based on the presence of a PubSub components loaded, since PubSub components are dynamic under hot reloading. This would complicate the logic a bit doing things this way I think.

[tomflenner]

Thanks for the feedback!

Would it make sense to start with a basic implementation using a simple circuit breaker? For now, if the annotation or argument is present, we just skip calling the endpoint.

We can see how that works in this first iteration - what do you think?

[olitomlinson]

I'd like to see info level logging stating that endpoints have been skipped

e.g.

Skipping programmatic subscription loading (see 'disable-init-endpoints' flag/annotation)

Skipping programmatic dapr configuration loading (see 'disable-init-endpoints' flag/annotation)

---

I also disagree that there should be a fall-back mechanism of checking if dapr/subscribe/ is there regardless of the disabled/enabled flag. The whole point of this (at least for me and other users) is that we want to stop 404s being logged in the applications observability platform for endpoints that don't exist. As I've explained in my previous linked issue, it causes anxiety for people new to dapr seeing error messages in observability platforms that dapr/subscribe and dapr/config endpoint does not exist -- it makes people feel like they've done something wrong or misconfigured dapr, which they absolutely havent.