Fix Setting Azure.DataApiBuilder to none bug

[RubenCerna2079]

Why make this change?

• Closes issue [Bug]: Startup class logger is not properly initialized #3262
  The logger for the Startup class is not initialized properly, since this logger is special due to the nature of the Startup class it needs to be continuously updated as DAB initializes. This causes two problems:

  • Some logs appear even when LogLevel is set to some value that would impede those logs to appear.
  • Some logs don't appear at all, even when LogLevel is set to a value that should allow them to be logged.

• Closes issue [Bug]: CLI logs being outputed even after LogLevel is set to none #3256 & [Bug]: log-level seems like it is not working when two in config. #3255
  The CLI logger still outputs some logs even when the LogLevel is set to none. It is expected that if the LogLevel set is none or some other level that shouldn't output the information level, the logs will not appear.

What is this change?

• Startup.cs: Correctly initialized the logger for startup by creating its own LogLevelInitializer and added the logs that are generated before the startup logger is initialized correctly to a log buffer, so they can be flushed out once the logger is completely initialized.
• Service/Program.cs: Fixed grammar mistake in isLogLevelOverriddenByCli
• DynamicLogLevelProvider.cs: Added summary comments
• LogBuffer.cs: Changed name from StartupLogBuffer.cs as it is now also used in the CLI. Also added the Exceptions parameter in order to allow for more types of logs to be saved in the buffer.
• FileSystemRuntimeConfigLoader.cs: Moved LogBuffer so that it always starts on its own, and the parameter doesn't need to be passed to it.
• StartOptions.cs: Add its own LogBuffer and add logs to buffer.
• ConfigGenerator.cs: Set LogBuffer and add all the logs that are generated into the buffer and flush them once the LogLevel is set.
• CustomLoggerProvider.cs: Allow the minimum LogLevel to be changed.
• ConfigMerger.cs: Add logs to buffer.

How was this tested?

• Integration Tests
• Unit Tests

Sample Request(s)

• dab start --LogLevel none
• dab start --LogLevel error

[RubenCerna2079]

/azp run

[RubenCerna2079]

/azp run

[RubenCerna2079]

/azp run

[Copilot]

Pull request overview

This PR addresses incorrect/early logging behavior in both the Service startup path and the CLI by introducing a shared buffering approach until the effective minimum log level is known, and by making the CLI logger provider honor a configurable minimum log level (including None).

Changes:

• Introduces a general LogBuffer (renamed from StartupLogBuffer) and wires it into Service startup and CLI flows to capture early logs and flush them after log level resolution.
• Updates Service startup to re-initialize the Startup logger with a dedicated LogLevelInitializer, and expands log filter registration.
• Updates CLI logging infrastructure to allow the minimum log level to be configured and routes multiple CLI logs through the buffer-or-logger helper.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/Service/Telemetry/DynamicLogLevelProvider.cs	Adds optional logger filter support and new XML doc blocks.
src/Service/Startup.cs	Buffers early Startup logs and reworks telemetry/logger initialization sequencing.
src/Service/Program.cs	Fixes spelling in isLogLevelOverriddenByCli naming.
src/Config/LogBuffer.cs	Renames/expands log buffer to include optional exceptions.
src/Config/FileSystemRuntimeConfigLoader.cs	Makes loader own its log buffer (no longer injected) and buffers until logger is set.
src/Cli/Utils.cs	Routes some config-selection logs through the buffer-or-logger helper; allows CLI logger factory to accept a minimum level.
src/Cli/CustomLoggerProvider.cs	Adds configurable minimum log level and enforces it (including disabling output for None).
src/Cli/ConfigMerger.cs	Routes merge logs through the buffer-or-logger helper.
src/Cli/ConfigGenerator.cs	Adds CLI buffer support, flushes buffered logs after log level is resolved, and adds helper for buffer-or-logger.
src/Cli/Commands/StartOptions.cs	Introduces a CLI buffer and attempts to route start logs through buffering.

Comments suppressed due to low confidence (1)

src/Config/LogBuffer.cs:16

• LogBuffer only stores a fully-rendered string message, which forces callers to use string interpolation and loses structured logging (message templates + args). That can break log analytics queries/telemetry correlation that rely on named properties. Consider storing the message template plus arguments (and optionally EventId) and using the ILogger.Log(logLevel, exception, template, args) overload when flushing.

[aaronburtle]

This function allows for null targetLogger, but doesn't seem to check if the targetLogger is null before dequeue. Doesn't that mean if the targetLogger is null, we just lose all the errors in the buffer? Should we skip flushing until targetLogger is not null, or maybe find another work around?

[RubenCerna2079]

I made it that way on purpose, but I will change it so that it throws a warning or an error that there is no logger and the logs cannot be flushed

[aaronburtle]

if the target logger is null and we are going to flush the buffer, should we instead print those logs to console? is there a case where we prefer those logs to be lost entirely?

[aaronburtle]

If there is an exception raised before we flush the logger here, then the buffer never flushes and any errors are skipped from being logged. similarly if TryGetConfig returns false I dont think we flush the logger for the late configured path.

I think we should use a try/finally block here to ensure that we always flush the logger.

[aaronburtle]

also, after this is fixed (or if you make it into a followup issue), there will be another issue which is we still have some usage of the console to account for this, for example, errors during deserialization. We will need to adjust console usage to rely on the logger buffer once we know it will flush properly even during a halted startup.

[aaronburtle]

This static method sets a static logbuffer globally, but StartOptions created a new log buffer each time it is invoked. This is probably going to work fine for now, but it creates a landmine where if we ever have parallel test execution or we invoke multiple StartOption instances for some reason we will have a race condition and logs from one test could flush to another, creating strange behavior.

[aaronburtle]

Looks like all the logging is now handled with SendLogToBufferOrLogger now, is the logger param here still used?