Improve console behavior in Rails applications

[roelbondoc]

Currently, the gem's behavior in rails console could use improvement, particularly around logging and automatic instrumentation. This affects both development and production environments.

Current Behavior

• Insights is disabled by default in the console via this code
• This default can be overridden by setting the HONEYBADGER_INSIGHTS_ENABLED environment variable
• When Insights is enabled (e.g., in 12-factor apps that set env vars in production), console users see potentially unwanted logging output
• Rate limit (429) responses and other Insights-related messages appear in the console output

Problems

1. 12-factor applications typically set environment variables at the application level, making it difficult to have different behavior for console sessions
2. Console logging can be noisy, potentially leading users to disable the gem entirely in development
3. No clear way to explicitly enable/disable features in console sessions

Current Workaround

Set HONEYBADGER_LOGGING_TTY_LEVEL=ERROR

Potential Solutions

1. New Console-Specific Configuration:

   • Add HONEYBADGER_INSIGHTS_CONSOLE_ENABLED (opt-in approach) — see the config-insights-console-enabled branch for a config example
   • Would replace the current automatic disable behavior

2. Disable All Features in Console:

   • Treat console sessions like development mode
   • Add a way to explicitly enable features when needed
   • Similar to the current Insights-only approach but more comprehensive

3. Improve Logging Control:

   • Allow routing different types of logs to separate files
   • Don't emit logs at all when attached to the console (this is the opposite of what Rails does by default, however — we should follow Rails conventions as closely as possible)

Questions to Consider

• Should we maintain different defaults for development vs production consoles?
• What features (if any) should be enabled by default in a console session?
• How can we make the behavior more intuitive for both standard and 12-factor deployments?

Related

• Current disabling code: https://github.com/honeybadger-io/honeybadger-ruby/blob/master/lib/honeybadger/init/rails.rb#L36-L38
• Events worker logging: https://github.com/honeybadger-io/honeybadger-ruby/blob/master/lib/honeybadger/events_worker.rb#L283

[joshuap]

@stympy @rabidpraxis @subzero10 thoughts on this?

[stympy]

Don't emit logs at all when attached to the console (this is the opposite of what Rails does by default, however — we should follow Rails conventions as closely as possible)

But the production Rails console doesn't log SQL queries, whereas the development console does, so if we want to follow Rails conventions, we could match that behavior for logging.

As for automatic instrumentation, I think we should disable that for all console sessions.

[joshuap]

Don't emit logs at all when attached to the console (this is the opposite of what Rails does by default, however — we should follow Rails conventions as closely as possible)

But the production Rails console doesn't log SQL queries, whereas the development console does, so if we want to follow Rails conventions, we could match that behavior for logging.

As for automatic instrumentation, I think we should disable that for all console sessions.

So if we just want to keep the current behavior (but fix the 12-factor issue), we could add the explicit insights.console_enabled option, default false (see Roel's branch).

That way, Honeybadger.notify and Honeybadger.event will still report in production, and you'll see those logs in the console if that's where you're sending logs, but the automatic instrumentation will be turned off in the console.

It sounds like that's what we're leaning towards?

[stympy]

So if we just want to keep the current behavior (but fix the 12-factor issue), we could add the explicit insights.console_enabled option, default false (see Roel's branch).

That way, Honeybadger.notify and Honeybadger.event will still report in production, and you'll see those logs in the console if that's where you're sending logs, but the automatic instrumentation will be turned off in the console.

It sounds like that's what we're leaning towards?

Sounds good to me!

[rabidpraxis]

👍🏻

[joshuap]

@roelbondoc go ahead and submit a PR for your branch when you get the chance!