I don't have any additional configuration for semantic logger gem. I'm relying on this gem's initializer to callSidekiq.configure_servier { |cfg| cfg.logger = SemanticLogger[Sidekiq] }
Expected Behavior
When sidekiq writes a log - it adds additional context to each log(job id and job class). This context is stored in Sidekiq::Context.current. I was expecting rails_semantic_logger to be aware of this context and for it to be visible in the logs when default sidekiq logger is replaced.
Actual Behavior
The context is lost when default sidekiq logger is replaced.
Pull Request
I was able to put together a workaround using a monkey-patch:
Sidekiq.configure_server do |config|
module SemanticLoggerSidekiqContext
def log(log, *args)
log.assign_hash(Sidekiq::Context.current)
super
end
end
SemanticLogger::Logger.prepend(SemanticLoggerSidekiqContext)
end
I'm not really happy with this patch and I was wondering if there's a better way to deal with this. Or if you can see any pitfalls with this patch that I'm using. Any info on other ways to address this issue are welcome.
Environment
Provide at least:
I don't have any additional configuration for semantic logger gem. I'm relying on this gem's initializer to call
Sidekiq.configure_servier { |cfg| cfg.logger = SemanticLogger[Sidekiq] }
Expected Behavior
When sidekiq writes a log - it adds additional context to each log(job id and job class). This context is stored in
Sidekiq::Context.current
. I was expectingrails_semantic_logger
to be aware of this context and for it to be visible in the logs when default sidekiq logger is replaced.Actual Behavior
The context is lost when default sidekiq logger is replaced.
Pull Request
I was able to put together a workaround using a monkey-patch:
I'm not really happy with this patch and I was wondering if there's a better way to deal with this. Or if you can see any pitfalls with this patch that I'm using. Any info on other ways to address this issue are welcome.