Conversation
|
Thanks for the PR!
Unfortunately, that's why we've made that PR in the first place and gone away from the So, I'm unsure if we can accept this solution, @marandaneto thoughts? |
I think you misunderstood me. That message is not going to be sent with Sentry event. (as verification all previous tests are passing) Previously you ware using override fun log(
priority: Int,
tag: String?,
message: String,
t: Throwable?
) {
// no-op as we've overridden all the methods
}☝️ this Only downside of this PR is that Timber still creates this variable. But it is not logged in Sentry events. |
romtsn
left a comment
There was a problem hiding this comment.
Oh, indeed, I overlooked 🤦 LGTM, that's a clever solution.
|
"Changelog" CI Action is failing. Do I need to to something? |
|
Could you also add a changelog entry? |
Yeah, add a changelog entry mentioning PR id, something like: * Fix: bring back support for `Timber.tag` (#1974) |
Codecov Report
@@ Coverage Diff @@
## main #1974 +/- ##
=========================================
Coverage 75.60% 75.60%
Complexity 2270 2270
=========================================
Files 225 225
Lines 8072 8072
Branches 852 852
=========================================
Hits 6103 6103
Misses 1558 1558
Partials 411 411 Continue to review full report at Codecov.
|
|
@marandaneto yeah, had that in mind, will open up a PR. I think a new patch release would worth it here, wdyt? |

📜 Description
Brings back
TimberTag. Closes #1900💡 Motivation and Context
We are relying heavily on
TimberTagvalue. One of our dependencies is abusing Timber logging. We were using this tag to filter out these events. This is a blocker to upgrade Sentry for us.I decided not to use reflection, since retrieving value is not enough. We would also have to write
tagclearing logic via reflection.Pros:
Cons:
messagestring, which we don't use (performance)💚 How did you test it?
Unit test
📝 Checklist
🔮 Next steps