is "active" observer turned off for non-debug?

[jjb]

thanks for this project!

my tests locally show that "active" event fires even when log level is set to info

i have this in an initializer Rack::Timeout::Logger.level=Logger::INFO

and am logging env['rack-timeout.info']['state'] for each request, and i see active being logged

i don't see anything in the code which would disable it in non-debug mode

• https://github.com/sharpstone/rack-timeout/search?q=debug
• https://github.com/sharpstone/rack-timeout/blob/f4b14a534b37d425ec4dba10d9cacf29ba012f9f/lib/rack/timeout/core.rb#L125

i addition to fixing this, would be cool if this were also configurable so it could be turned off in debug mode

[schneems]

Going to be honest. I don't know much about observers. Is there something you would like to update or change via a PR? Either documenting the current state or changing it? Is this related to #146 ?

[wuputah]

I would not expect state changes to active to be logged at INFO.
https://github.com/zombocom/rack-timeout/blob/main/lib/rack/timeout/logging-observer.rb#L44-L45

I suspect the problem may be in the way the OP is setting the logging level, i.e. maybe the logging level is getting changed, reset, or lost after initialization. The docs suggest you create a new logger first, which should assure your logging level does not get inherited/reset by the default logger (i.e. Rails).
https://github.com/zombocom/rack-timeout/blob/main/doc/logging.md

However the docs do imply that Rack::Timeout::Logger.level = Logger::INFO would create a new logger which should be immune from this issue. That feature derives from this code:
https://github.com/zombocom/rack-timeout/blob/main/lib/rack/timeout/logger.rb#L13-L15

This can be a bit tricky to follow but I believe it does what is says. So, I can't find the bug, but that doesn't mean one doesn't exist.

[wuputah]

#104 seems possibly related.

[schneems]

To get on the same page it would help if we had an example app to reproduce the problem https://www.codetriage.com/example_app

…

On Thursday, June 9, 2022, Jonathan Dance (JD) ***@***.***> wrote: #104 <#104> seems possibly related. — Reply to this email directly, view it on GitHub <#178 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOSYD66FNR7PQX7CYMR6LVOJWM3ANCNFSM5IWF6MBQ> . You are receiving this because you commented.Message ID: ***@***.***>

-- Richard Schneeman https://www.schneems.com he/him

[wuputah]

closing as stale