Ownership integration #1364
Merged
Ownership integration #1364
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
✔️ All good! |
unflxw
force-pushed
the
ownership-integration
branch
from
fc609cd to
64de16d
Compare
unflxw
requested review from
thijsc,
matsimitsu,
jeffkreeftmeijer,
tombruijn and
luismiramirez
|
@tombruijn I'm interested in any thoughts about the transaction |
unflxw
force-pushed
the
ownership-integration
branch
3 times, most recently
from
ce2844a to
c90e520
Compare
unflxw
force-pushed
the
ownership-integration
branch
from
c90e520 to
aa6f75e
Compare
Add a new `instrument_ownership` configuration option that can be used to toggle off instrumentation for the `ownership` gem.
tombruijn
reviewed
Jan 10, 2025
unflxw
force-pushed
the
ownership-integration
branch
from
aa6f75e to
2132859
Compare
unflxw
removed request for
thijsc,
matsimitsu,
jeffkreeftmeijer and
luismiramirez
unflxw
force-pushed
the
ownership-integration
branch
from
2132859 to
b2b50cb
Compare
Add a configuration option that toggles whether the Ownership gem integration sets namespaces, or only sets tags. It defaults to false, meaning it only sets tags.
Add a hook that allows for blocks of arbitrary code to be applied to modify a transaction after it has been created.
Add a `before_complete` transaction hook, which is executed right before a transaction is completed. Note that, for transactions containing multiple errors, this hook is called once for each of the duplicate transactions that is used to report each of the errors. This allows the context to be customised for each error.
unflxw
force-pushed
the
ownership-integration
branch
from
b2b50cb to
ed09e31
Compare
|
Hi @unflxw, We've found new issues for this Pull Request. Please see the main comment on this issue for a list of all current warnings. This comment will not be updated to reflect resolved warnings.
|
unflxw
force-pushed
the
ownership-integration
branch
from
ed09e31 to
b47ddd9
Compare
Add an instrumentation for the `ownership` gem. When a transaction is created, if an owner has been set in the gem, use the name of the owner as the owner tag for the transaction. Do the same when an owner is set during an active transaction. If more than one owner is set during a transaction, the owner tag will be that of the last owner that was set. When the `ownership_set_namespace` config option is enabled, set the namespace for the transaction to the owner as well.
unflxw
force-pushed
the
ownership-integration
branch
from
b47ddd9 to
865b348
Compare
This comment has been minimized.
This comment has been minimized.
tombruijn
approved these changes
Jan 14, 2025
This comment has been minimized.
This comment has been minimized.
luismiramirez
approved these changes
Jan 15, 2025
This comment has been minimized.
This comment has been minimized.
1 similar comment
This is a message from the daily scheduled checks. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implements an integration for the
ownershipgem, as discussed on Slack.Commits
Add instrument_ownership config option
Add a new
instrument_ownershipconfiguration option that can beused to toggle off instrumentation for the
ownershipgem.Add after_create transaction hook
Add a hook that allows for blocks of arbitrary code to be applied to
modify a transaction after it has been created.
Add before_complete transaction hook
Add a
before_completetransaction hook, which is executed rightbefore a transaction is completed. Note that, for transactions
containing multiple errors, this hook is called once for each of
the duplicate transactions that is used to report each of the
errors. This allows the context to be customised for each error.
Instrument ownership gem
Add an instrumentation for the
ownershipgem. When a transactionis created, if an owner has been set in the gem, use the name of
the owner as the namespace for the transaction. Do the same when an
owner is set during an active transaction.
If more than one owner is set during a transaction, the namespace
will be that of the last owner that was set.
Notes
@thijsc mentioned it would be nice to contribute this to the gem itself. I took a look at that, but I noticed we'd need something like the
after_createandbefore_completehooks in this PR to make it work. That said, now that those hooks exist, it should be possible to make them part of the public API, discard the instrumentation in this PR, and instead contribute an instrumentation as a PR to the gem.@matsimitsu suggested using the owner information to automatically assign errors (and performance issues?) to teams, instead of setting the owner as the namespace. At the moment, this PR uses namespaces, but we could use team assignments instead, or alongside it. Beyond this gem, customers might find it useful to be able to set metadata on their transactions and traces that causes them to automatically be assigned to a team or person. I'm unsure how much work that would be, though.
Regarding testing it, I attempted to use a mock to test it, like we do for several other dependencies. It is possible, but I found myself re-implementing the gem and doubting whether my implementation was an accurate representation of the original, so I decided to add a gemfile instead. I'm happy to reconsider this if we want to avoid the additional gemfile and its corresponding CI runs.