[bridges:otelzap] zapcore.Core does not Sync (flush)

[Gjergj]

Description

When using the otelzap bridge in a short lived cli application zapcore.Core does not flush on application exit even when calling Sync method.

Environment

• OS: [macos, linux]
• Architecture: [ x86, arm64]
• Go Version: [ go1.24.3]
• go.opentelemetry.io/contrib/bridges/otelzap v0.11.0

Steps To Reproduce

1. Using this code ...

 exporter, err = otlploggrpc.New(ctx, opts...)
  processor := sdklog.NewBatchProcessor(exporter)
   res, _ := resource.New(ctx,
   	resource.WithProcess(),
   	resource.WithContainer(),
   	resource.WithProcessExecutableName(),
   	resource.WithHost())
   provider := sdklog.NewLoggerProvider(sdklog.WithResource(res), sdklog.WithProcessor(processor))

   core := otelzap.NewCore("siren", otelzap.WithLoggerProvider(provider))

2. Run the code (I can provide full main method if needed)
3. I notice that after application exit the last couple of logs are missing

Expected behavior

Logs to flush/sync

From a quick glance at the code

opentelemetry-go-contrib/bridges/otelzap/core.go

Line 187 in 48f6936

func (o *Core) Sync() error {

it seems that Sync is not implemented

I can follow up with a PR with possible fix but wanted an opinion or some context why Sync implementation is the way it is

[dmathieu]

cc @pellared @khushijain21 as codeowners.

[pellared]

This is most likely not caused by lack of Sync implementation, but lack of provider.Shutdown invocation which should flush the batched logs. Can you please double-check?

[Gjergj]

This is most likely not caused by lack of Sync implementation, but lack of provider.Shutdown invocation which should flush the batched logs. Can you please double-check?

By your comment my understanding is that it's not the otelzap.Core that should make sure logs are flushed but rather the provider (calling Shutdown or ForceFlush) passed to it, is that correct?

[pellared]

This is most likely not caused by lack of Sync implementation, but lack of provider.Shutdown invocation which should flush the batched logs. Can you please double-check?

By your comment my understanding is that it's not the otelzap.Core that should make sure logs are flushed but rather the provider (calling Shutdown or ForceFlush) passed to it, is that correct?

Yes.

[Gjergj]

This is most likely not caused by lack of Sync implementation, but lack of provider.Shutdown invocation which should flush the batched logs. Can you please double-check?

By your comment my understanding is that it's not the otelzap.Core that should make sure logs are flushed but rather the provider (calling Shutdown or ForceFlush) passed to it, is that correct?

Yes.

Thank you. Closing the issue.

If anyone comes across this in the future my solution is to create a wrapper of otelzap.Core by embedding it and implement Sync where provider.ForceFlush is called.

[pellared]

implement Sync where provider.ForceFlush is called.

This will affect also other log producers (e.g. code directly using go.opentelemetry.io/otel/log to emit logs). However maybe this is something we should do?

Reopening, as I think it may be a good and acceptable solution. However, I would like to have other opinions.

@khushijain21, @dmathieu, what is your opinion on this?

[khushijain21]

Implement Sync where provider.ForceFlush is called.

If we do this - then provider.ForceFlush from one logger instance would cause force flushing in all the loggers provided by LoggerProvider.

One solution would be that LoggerProvider accepts a context, which if is cancelled - it calls ForceFlush().

[pellared]

If we do this - then provider.ForceFlush from one logger instance would cause force flushing in all the loggers provided by LoggerProvider.

Yes. However, would such behavior cause any problems?

One solution would be that LoggerProvider accepts a context, which if is cancelled - it calls ForceFlush().

I do not understand this proposal.