Export more utility functions

[jeengbe]

Problem Statement

Currently, in order not to go with sentry.gethub.getscope.getspan and the same for scope all over the application, we use a couple of utility methods:

export function setTransactionName(name: string): void {
  Sentry.getCurrentHub().getStack()[0]?.scope?.setTransactionName(name);
}

export function dropTransaction() {
  Sentry.getCurrentHub().getStack()[0]?.scope?.setTag('dropTransaction', true);
}

export function startSpan(
  name: string,
  spanContext?: Parameters<Sentry.Span['startChild']>[0],
  pushScope = true
): Sentry.Span | undefined {
  const span = Sentry.getCurrentHub()
    .getScope()
    ?.getSpan()
    ?.startChild({
      op: name,
      ...spanContext,
    });

  if (pushScope) {
    Sentry.getCurrentHub().pushScope().setSpan(span);
  }

  return span;
}

export function endSpan(span: Sentry.Span | undefined, popScope = true): void {
  if (!span) {
    return;
  }

  span.finish();
  if (popScope) {
    Sentry.getCurrentHub().popScope();
  }
}

especially the Sentry.getCurrentHub().getStack()[0]?.scope part is tricky.

Solution Brainstorm

Are those methods even correct? If they are, the sdk should export something similar itself

[lforst]

Good feedback! You're actually hitting a point that is very annoying to us internally. :D Our concurrency model is overcomplicated and flawed. Up until now, we didn't change it because we wanted to adhere to the Sentry Unified API, however, we have decided that it is pointless to follow this API if it doesn't make sense to the language so we will most likely adjust this in the medium far future. This is of course super breaking and needs a lot of considerations and discussions so don't expect anything to happen too quickly.

The reason we don't want to introduce something like getCurrentScope() right now is that with the current model, we would hand users a footgun, since everything around the SDK concurrency model is mutable atm. In the future, getCurrentScope() along with withScope() will probably be the only methods users will have to interact with.

Just some insight ☝️

Feel free to let us know your vision of an ideal API around this and we might consider it in our implementation!

[jeengbe]

I wasn't directly referring to the way hubs/scopes/spans are working, but merely on what convenience methods are available. There already is withScope (short for push, run, pop), and for other commonly used operations, such as what is essentially withScope + startSpan, endSpan, and transaction renaming, a few simplified methods would be nice (since the overhead is significant and error-prone).

[jeengbe]

Also - just to confirm - is the way I'm currently doing a production-safe way?

[lforst]

Also - just to confirm - is the way I'm currently doing a production-safe way?

Yes of course!

[jeengbe]

Yay, thanks for confirming!

[mydea]

Hey @jeengbe ,

You can use the new Sentry.trace() function we introduced here: #7556
we don't have docs for that yet, but I think it may do what you need, mostly? If you could give it a try and leave some feedback here, that would be great!

[jeengbe]

Hey @jeengbe ,

You can use the new Sentry.trace() function we introduced here: #7556 we don't have docs for that yet, but I think it may do what you need, mostly? If you could give it a try and leave some feedback here, that would be great!

Hi @mydea,

it does look pretty much what we need, thanks for the tip! We're in the course of moving to the OTel framework, so I can't really give any good feedback on how it's used, sorry!

[mydea]

OK, I see, no worries! I'll close this issue then, if you have any further problems/follow ups, feel free to open a new issue 👍