ExceptionlessLoggerProvider(Action<ExceptionlessConfiguration>) configures and disposes the shared ExceptionlessClient.Default
Mantenedores costumam responder em até 6 dias
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 2/5
- Tempo estimado
- 1-3 horas
- Facilidade para iniciantes
- 35/100
Direção de pesquisa
Read src/Platforms/Exceptionless.Extensions.Logging/ExceptionlessLoggerProvider.cs, especially the Action<ExceptionlessConfiguration> constructor and Dispose method, then check the overloads in ExceptionlessLoggerExtensions.cs. Confirm how the constructor creates and owns its client, and run the logging provider tests if available. Done means these overloads use an independent client and disposing the provider leaves ExceptionlessClient.Default usable; the issue notes draft PR #368 already proposes this change.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
In Exceptionless.Extensions.Logging 6.2.0, AddExceptionless(apiKey) and AddExceptionless(Action<ExceptionlessConfiguration>) are documented as using "a new client", but the ExceptionlessLoggerProvider(Action<ExceptionlessConfiguration>) constructor they call uses the process-wide ExceptionlessClient.Default and marks it as owned (_shouldDispose = true). Disposing the provider disposes Default, which the rest of the app is still using.
Where
- https://github.com/exceptionless/Exceptionless.Net/blob/5792f00d175f94a35fe0559c8e9999234a8163be/src/Platforms/Exceptionless.Extensions.Logging/ExceptionlessLoggerProvider.cs#L23-L31 (uses
ExceptionlessClient.Defaultand sets_shouldDispose = true) - https://github.com/exceptionless/Exceptionless.Net/blob/5792f00d175f94a35fe0559c8e9999234a8163be/src/Platforms/Exceptionless.Extensions.Logging/ExceptionlessLoggerProvider.cs#L43-L47 (disposes the client)
- https://github.com/exceptionless/Exceptionless.Net/blob/5792f00d175f94a35fe0559c8e9999234a8163be/src/Platforms/Exceptionless.Extensions.Logging/ExceptionlessLoggerExtensions.cs#L52-L84 (the overloads that call this constructor, documented as "using a new client")
What happens
- When the provider is disposed,
ExceptionlessClient.Defaultis disposed: its settings-update timer is stopped, its configuration and queue event handlers are detached, and its dependency resolver is disposed.Defaultis aLazysingleton, so it is never recreated, and everything else that uses it (ExceptionlessClient.Default.Submit*,services.AddExceptionless(),app.UseExceptionless(), the NLog and log4net integrations) keeps using the disposed instance. This happens when the provider is added to aLoggerFactorywithfactory.AddProvider(...)and the factory is disposed, or when the caller disposes the provider. (ThroughILoggingBuilder.AddExceptionless(...)the provider is registered as a pre-built instance, so the container does not dispose it.) - In every path, the configuration passed to these overloads is applied to
Defaultrather than a separate client.AddExceptionless(apiKey)also callsUseInMemoryStorage()andSetDefaultMinLogLevel(Trace)onDefault, which changes the behavior of every other integration that uses it.
Expected
The provider creates and owns its own ExceptionlessClient, as the XML docs say, and only disposes a client it created.
Steps to reproduce
using (var factory = new LoggerFactory())
factory.AddProvider(new ExceptionlessLoggerProvider(c => c.ApiKey = "API_KEY"));
// ExceptionlessClient.Default has now been disposed by the logger provider;
// for example, its internal settings timer is disposed.
ExceptionlessClient.Default.SubmitLog("after logger factory disposed");
Verified against the 6.2.0 NuGet packages: after the using block, ExceptionlessClient.Default is in its disposed state.
Suggested fix
Create a new client in the Action<ExceptionlessConfiguration> constructor (_client = new ExceptionlessClient();). The open draft PR #368 includes this change.
- Linguagem predominante
- C#
- Estrelas
- 573
- Forks
- 143
- Merge médio
- 5d 9h
- PRs com merge (30d)
- 1
Preparar o ambiente
Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de exceptionless/Exceptionless.Net
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 86/100
exceptionless/Exceptionless.Net#391 ·
Mantenedores costumam responder em até 6 dias
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
exceptionless/Exceptionless.Net#390 ·
Mantenedores costumam responder em até 6 dias
-
bug
Dificuldade 1/5 1-3 horas Facilidade para iniciantes 88/100
exceptionless/Exceptionless.Net#387 ·
Mantenedores costumam responder em até 6 dias
-
AWS Lambda detection never matches because the environment variable name has a trailing spaceAbertabug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100
exceptionless/Exceptionless.Net#386 ·
Mantenedores costumam responder em até 6 dias
-
bug
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 72/100
exceptionless/Exceptionless.Net#388 ·
Mantenedores costumam responder em até 6 dias
Todas as issues de exceptionless/Exceptionless.Net
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
-
Dificuldade 1/5 1-3 horas Facilidade para iniciantes 89/100
getsentry/sentry-dotnet#5833 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
area: core priority: low type: bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
RicoSuter/Namotion.Interceptor#863 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100
bitfoundation/bitplatform#14428 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
area-cli
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
Mantenedores costumam responder em até 1 dia