fix(sdk-logs): stop Logger.emit() doing work after LoggerProvider shutdown

[anneheartrecord]

Which problem is this PR solving?

Fixes #6823

Logger.emit() only guards on this.enabled(), which covers severity / trace-based / per-processor filtering but not provider lifecycle. Once the owning LoggerProvider has been shut down, an already-obtained Logger still builds a LogRecordImpl, reports logger metrics and calls activeProcessor.onEmit() — exactly the side work raised in the SIG review. The shutdown state lived only in LoggerProvider._shutdownOnce, which the Logger (holding only LoggerProviderSharedState) could not see.

Short description of the changes

• Track shutdown on LoggerProviderSharedState (hasShutdown) and set it in LoggerProvider shutdown, so it also covers emits that race with the in-flight processor shutdown.
• Short-circuit Logger.emit() when shut down — no record construction, no metrics, no onEmit.
• Make Logger.enabled() return false after shutdown as well, so callers that use enabled() to gate expensive log construction don't waste that work (the API documents enabled() for exactly this purpose).

This mirrors the loggerSharedState.hasBeenShutdown() guard in the OpenTelemetry Java SDK referenced in the issue.

How Has This Been Tested?

Added a regression test in Logger.test.ts: after await loggerProvider.shutdown(), logger.enabled() returns false and logger.emit() neither calls the processor's onEmit nor constructs a LogRecord. The full sdk-logs suite passes (200 passing).

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.56%. Comparing base (f755008) to head (d062077).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6826   +/-   ##
=======================================
  Coverage   95.56%   95.56%           
=======================================
  Files         386      386           
  Lines       13084    13088    +4     
  Branches     2997     2998    +1     
=======================================
+ Hits        12504    12508    +4     
  Misses        580      580           

Files with missing lines	Coverage Δ
experimental/packages/sdk-logs/src/Logger.ts	100.00% <100.00%> (ø)
...perimental/packages/sdk-logs/src/LoggerProvider.ts	100.00% <100.00%> (ø)
...sdk-logs/src/internal/LoggerProviderSharedState.ts	97.36% <100.00%> (+0.07%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[trentm]

Thanks! LGTM.
I have a few nits, mostly on personal preferences on comment verbosity.

[anneheartrecord]

Thanks @trentm — fair points.

On the redundant hasShutdown guard in emit(): you're right that enabled() already short-circuits on shutdown, so the early return is redundant and can come out. Only tradeoff is a bare field access vs a function call on the now-cold path, but that's negligible in practice.

For the comment verbosity: happy to trim the guards-with-explanation style if the preference is to let the guards speak for themselves.

I'll hold off on pushing the cleanup until a core team member weighs in — don't want to churn the commit unnecessarily if the preference is to land as-is. But if you'd like me to update, just say the word.

[pichlermarc]

@anneheartrecord - Trent is the core team member (he's a maintainer) 😄

I also agree that we should reduce the verbosity of the comments a bit. I think the code is very readable as-is :)

[anneheartrecord]

Done — pushed the cleanup:

• Removed the redundant hasShutdown early return from emit(); the enabled() call a few lines below already gates on shutdown, so the guard was doing double work
• Trimmed the two-line explanatory comments in Logger.ts, LoggerProvider.ts, and LoggerProviderSharedState.ts so the guards speak for themselves

Tests still pass, lint clean.

[otelbot]

Thank you for your contribution @anneheartrecord! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out this survey.