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

[geneva] Nullable annotations for TLDExporter folder #2085

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

CodeBlanch
Copy link
Member

Changes

  • Adds nullable annotations for the TLDExporter folder inside the GenevaExporter project

Merge requirement checklist

  • CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)

@CodeBlanch CodeBlanch requested a review from a team as a code owner September 20, 2024 06:11
@github-actions github-actions bot added the comp:exporter.geneva Things related to OpenTelemetry.Exporter.Geneva label Sep 20, 2024
Copy link

codecov bot commented Sep 20, 2024

Codecov Report

Attention: Patch coverage is 12.65823% with 69 lines in your changes missing coverage. Please review.

Project coverage is 64.65%. Comparing base (71655ce) to head (931ee00).
Report is 439 commits behind head on main.

Files with missing lines Patch % Lines
...ry.Exporter.Geneva/TLDExporter/TldTraceExporter.cs 12.50% 35 Missing ⚠️
...etry.Exporter.Geneva/TLDExporter/TldLogExporter.cs 11.11% 32 Missing ⚠️
...lemetry.Exporter.Geneva/TLDExporter/TldExporter.cs 0.00% 2 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #2085      +/-   ##
==========================================
- Coverage   73.91%   64.65%   -9.27%     
==========================================
  Files         267       35     -232     
  Lines        9615     3596    -6019     
==========================================
- Hits         7107     2325    -4782     
+ Misses       2508     1271    -1237     
Flag Coverage Δ
unittests-Exporter.Geneva 64.65% <12.65%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
...etry.Exporter.Geneva/TLDExporter/JsonSerializer.cs 36.84% <100.00%> (-1.74%) ⬇️
...orter.Geneva/TLDExporter/UncheckedASCIIEncoding.cs 17.30% <ø> (+1.30%) ⬆️
...lemetry.Exporter.Geneva/TLDExporter/TldExporter.cs 27.84% <0.00%> (ø)
...etry.Exporter.Geneva/TLDExporter/TldLogExporter.cs 20.29% <11.11%> (-16.83%) ⬇️
...ry.Exporter.Geneva/TLDExporter/TldTraceExporter.cs 32.31% <12.50%> (ø)

... and 250 files with indirect coverage changes

}
catch
{
repr = $"ERROR: type {value.GetType().FullName} is not supported";
repr = $"ERROR: type {value!.GetType().FullName} is not supported";
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this can throw an exception if value = null!

Copy link
Member Author

Choose a reason for hiding this comment

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

We could but we would have to pay for a null check for every field serialized. I went and checked, seems like none of the upstream code actually will ever pass a null (also added the assert to validate) so this at the end of the day is just being defensive. Even with a null check users could do something silly like this...

activity.SetTag("MyTag", new MyType());

class MyType
{
   public override string? ToString() => null;
}

...which would cause the Convert.ToString call there to return null even though value itself was something real! Spooky 👻

Copy link
Contributor

Choose a reason for hiding this comment

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

okay, if you checked the upstream code then I'm fine continuing as is. :)

Comment on lines +243 to +248
var fullName = logRecord.Exception.GetType().FullName;
if (!string.IsNullOrEmpty(fullName))
{
eb.AddCountedAnsiString("ext_ex_type", fullName, Encoding.UTF8);
}

Copy link
Contributor

Choose a reason for hiding this comment

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

for my learning, when would the Exception Type be null or empty?

Copy link
Member Author

Choose a reason for hiding this comment

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

Exception.Type shouldn't be null but Type.FullName may be null. Why would FullName be null? Who knows! Probably some edge case thing not often seen like a Type dynmaically constructed at runtime? This change here makes it defensive should we ever run into it 🤷

}

return result;
return ExportResult.Failure;
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like we may have been incorrectly returning Success when the eventProvider was not enabled.
Does this need a bug fix line in the Changelog?

Copy link
Member Author

Choose a reason for hiding this comment

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

I think it was fine before just kind of awkwardly written. All I did here was switch it around to hopefully make it more readable.

Comment on lines +256 to +259
if (entry.Key.StartsWith("otel.status_", StringComparison.Ordinal))
{
if (string.Equals(Convert.ToString(entry.Value, CultureInfo.InvariantCulture), "ERROR", StringComparison.Ordinal))
var keyPart = entry.Key.AsSpan().Slice(12);
if (keyPart is "code")
Copy link
Contributor

Choose a reason for hiding this comment

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

this is cool. I had to do some reading but this should be a allocation-free way of working with substrings. learned something new today :)

Copy link
Member Author

Choose a reason for hiding this comment

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

Spans are magic 🤣 But this isn't so much about avoiding allocations as it is just speeding up the logic. If you look at the before it checked if the key was "otel.status_code" and then it checked if the key was "otel.status_description". What I did was switch it to see if the key starts with "otel.status_" if it doesn't, we know it isn't going to match and we can skip further processing. Only if the key starts with "otel.status_" then do we check for "code" or "description" essentially so we don't do any repeat work.

Copy link
Contributor

@TimothyMothra TimothyMothra left a comment

Choose a reason for hiding this comment

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

LGTM. I left some minor comments

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comp:exporter.geneva Things related to OpenTelemetry.Exporter.Geneva
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants