Allow fluent use of Transaction::setName() method

[mfb]

For better developer experience, I'd say Transaction::setName() should also be a fluent method

[cleptric]

Any use case in mind? You normally set the name via the context.

[mfb]

I set the name via the context, and then later in the request life cycle, set it to the route name; Sentry Laravel SDK also calls Transaction::setName() in the same way.

[cleptric]

Yep, but do you have any code example in mind where the fluent API matters?

[mfb]

I don't think the fluent API matters per se, it's just to make the methods consistent for better developer experience.

The other set* methods (inherited from the Span class) return $this, so a developer might reasonably expect this method to also return $this (until they execute the code or run phpstan and notice it doesn't work of course :)

[mfb]

The goal would be for something like this to work

$transaction->setTags(['bar' => 'baz'])
  ->setName('foo')
  ->finish();

Currently something like this is required:

$transaction->setTags(['bar' => 'baz'])
  ->setName('foo');
$transaction->finish();

[cleptric]

I think this won't work. setTags returns a Span and calling setName on it throws :/

[mfb]

I think this won't work. setTags returns a Span and calling setName on it throws :/

This code works fine in my testing; setTags() returns the Transaction and nothing was thrown. What is thrown for you?

[cleptric]

hmm, then maybe I misremembered, we had a similar issue before. Anyways, a test please and this is good to go.

[stayallive]

We had a self return type hint on span methods which didn't work (because it returned the Span instead of Transaction). Should work fine in the transaction methods though 👍

[mfb]

I'm unclear what wouldn't work with return types on Span. If a Transaction method is supposed to return a Span, I thought it works fine because a Transaction is a Span.

But in any case yeah that issue isn't relevant for this issue.