Feature request: Add Activity.Current.Id to ErrorMessage (and maybe Events) about identityserver

[JustusGreiberORGADATA]

@AndersAbel Yeah I agree, the ID should be null, if Activity.Current was null at the time of creation. It should not magically appear later after deserialization.

But if custom code creates an ErrorMessage it now needs to be updated to include setting the ActivityId.

I don't have any code like that. I doubt it is a common use case.

[AndersAbel]

It makes perfect sense to include Activity.Current?.Id in ErrorMessage.

The Events are being phased out in favour of the new open telemetry compatible activities/logs/metrics.

[AndersAbel]

@JustusGreiberORGADATA I've now implemented this and submitted a PR. I first tried using your suggestion:

public string? ActivtityId { get; set; } = Activity.Current?.Id;

However, this had one problem if there is no Current activity in the ErrorMessage that is serialized. Then the deserializer will not write the property at all (because it's null in the payload). That will leave the default value in the object created to receive the values of the deserializer. The end result was that if there was no current activity when the error message was created, the activity Id of when the error was displayed/used would be used on the ErrorMessage. I would expect that if a null activity was passed in to serialization, then a null activity would be read back too.

The more straight forward solution is to let the creator of the ErrorMessage initialize the ActivityId. In IdentityServer that is only done in one place in the AuthorizeHttpWriter. But if custom code creates an ErrorMessage it now needs to be updated to include setting the ActivityId.