Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds on_ending callback to allow processors to mutate spans before End operation #1713

Merged
merged 11 commits into from
Oct 1, 2024

Conversation

pantuza
Copy link
Contributor

@pantuza pantuza commented Sep 1, 2024

This Pull Request aims to solve the issue #1695 by adding the on_ending callback to SpanProcessor class.
It also make sure to call that method during the span End operation (finish() method), right after the end
timestamp has been set but while the span is still mutable.

Based on the spec, this implementation complies with:

  • The on_ending callback is optional within ANY SpanProcessor. Only called when exists.
  • called during the span End() operation
  • Span object is still mutable
  • MUST be called synchronously within the Span End operation
  • it should not block or throw an exception
  • MUST guarantee that the span can no longer be modified by any other thread before invoking on_ending
  • modifications are only allowed synchronously from within the invoked on_ending
  • SpanProcessor on_ending callbacks are executed before any SpanProcessor's on_end callback is invoked

…ssors

Signed-off-by: Gustavo Pantuza <gustavopantuza@gmail.com>
…ght after setting the end timestamp

Signed-off-by: Gustavo Pantuza <gustavopantuza@gmail.com>
Signed-off-by: Gustavo Pantuza <gustavopantuza@gmail.com>
#
# @param [Span] span the {Span} that just is ending (still mutable).
# @return [void]
def on_ending(span); end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an experimental feature and may have breaking changes. How about specifying that here ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the suggestion. I will update it.

… official spec

Signed-off-by: Gustavo Pantuza <gustavopantuza@gmail.com>
@pantuza pantuza marked this pull request as ready for review September 3, 2024 19:21
@pantuza pantuza changed the title [Draft] Adds on_ending callback to allow processors to mutate spans before End operation Adds on_ending callback to allow processors to mutate spans before End operation Sep 3, 2024
Copy link
Contributor

@kaylareopelle kaylareopelle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your PR, @pantuza! I want to think about this a little more, but I have some feedback on the documentation for now.

sdk/lib/opentelemetry/sdk/trace/span_processor.rb Outdated Show resolved Hide resolved
sdk/lib/opentelemetry/sdk/trace/span_processor.rb Outdated Show resolved Hide resolved
pantuza and others added 2 commits September 4, 2024 11:05
Co-authored-by: Kayla Reopelle <87386821+kaylareopelle@users.noreply.github.com>
Co-authored-by: Kayla Reopelle <87386821+kaylareopelle@users.noreply.github.com>
@pantuza
Copy link
Contributor Author

pantuza commented Sep 4, 2024

Thanks for your PR, @pantuza! I want to think about this a little more, but I have some feedback on the documentation for now.

Thank you for your feedback and documentation suggestions. I really appreciate it.
Take the necessary time to think about the PR and please, let me know in case you think there is anything left to be done in this PR.

To give you a little background context, have started this work because of the following discussion in this Pull Request #1713

@robbkidd
Copy link
Member

robbkidd commented Sep 4, 2024

… have started this work because of the following discussion in this Pull Request #1713 [👀]

1713 is this pull request. Is there a different discussion you meant to link to?

@pantuza
Copy link
Contributor Author

pantuza commented Sep 4, 2024

… have started this work because of the following discussion in this Pull Request #1713 [👀]

1713 is this pull request. Is there a different discussion you meant to link to?

You are right! Thank you for pointing it out. The correct discussion is in #1690

…za/opentelemetry-ruby into span-processor-on-ending-interface
Copy link
Member

@mwear mwear left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, this looks good to me. For reference, Java already has this: open-telemetry/opentelemetry-java#6367. We chose to rename the end method to finish since end is a Ruby keyword. One thought I had was whether or not we should considering calling this on_finishing, but I am ok with this as is. Curious if anyone else has any thoughts.

Copy link
Contributor

@kaylareopelle kaylareopelle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@kaylareopelle
Copy link
Contributor

One thought I had was whether or not we should considering calling this on_finishing, but I am ok with this as is. Curious if anyone else has any thoughts.

I do like the idea of using on_finishing here to keep the same term around, but don't feel strongly one way or the other. If we use on_finishing instead, we may want to add a link to the SDK documentation or "On Ending" to clear up any confusion that might exist connecting the on_finishing method to its specification.

@pantuza
Copy link
Contributor Author

pantuza commented Sep 17, 2024

I also like the idea of using on_finishing to keep names concise with the project decisions.
If you don't mind I will update the code that way and make sure to document it properly.

…th project name strategy

Signed-off-by: Gustavo Pantuza <gustavopantuza@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants