Cool thanks for the heads up - looking a lot like one of the original attempts now :)

I don’t even want to see the number of exceptions that will happen only in production in some contests only because people don’t know they always need to check the presence of the object in the context.

That's a fair concern, but at least an error is loud and obvious.

On the other hand context[:foo].bar.baz if context[:foo] printing garbage in the logs is much harder to debug. I wish there was a way to handle both but I don't see how.

If we split the tagging hash per context and only run the tags for a context, when that context is not new we remove the need to check for nil and don’t show garbage.

I'm sorry, but I don't understand what you are suggesting, maybe a code snippet would help?

FWIW I'm +1 on avoiding the null object: swallowing all possibly-misguided method calls seems almost as bad as wrapping the whole thing in rescue StandardError to me.

But I had also wondered about a simplification along the lines of what (I think) @rafaelfranca is suggesting, e.g.:

ActiveRecord::QueryLogs.tags_for(:controller) do |controller_context|
  {
    controller: controller_context.controller_name,
    action: controller_context.action_name,
    namespaced_controller: controller_context.class.name,
  }
end

But I had also wondered about a simplification along the lines of what (I think) @rafaelfranca is suggesting, e.g.:

Ah! Yes, I think that would work. There might be some edge cases where you want to access two context values, but I haven't encountered one yet.

@matthewd got my suggestion. If you set two context values we should execute the tagging code for both contexts.

Are you going to implement that or should I?

I have a bunch on my plate already, so feel free to implement it. Otherwise I can probably get to it later this week.

Not sure if it is worth. Between the dynamic tags and direct context access adding per-context tagging code will just make the API and the implementation more confusing. I made peace with those occasional exceptions when tagging queries. I wish it didn't fail the entire request though. Maybe we can notify the exception when we had the error notification API and silent it.