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

RUMM-961 DDError.title is used in RUMEvents.error.type #393

Merged
merged 4 commits into from
Feb 2, 2021

Conversation

buranmert
Copy link
Contributor

@buranmert buranmert commented Jan 29, 2021

What and why?

As part of error tracking, type: String? is introduced to RUMErrorEvent.Error
This value is expected to be the same with error.kind in Logger
Logger uses DDError.title as error.kind

How?

DDError.title was already used in RUMErrorEvent.Error.message property
Now we basically use the same value in message and type properties of the same instance

Review checklist

  • Feature or bugfix MUST have appropriate tests (unit, integration)
  • Make sure each commit and the PR mention the Issue number or JIRA reference

@buranmert buranmert self-assigned this Jan 29, 2021
@buranmert buranmert force-pushed the buranmert/RUMM-961-error-type branch from ac3b0c1 to 4e8cbba Compare January 29, 2021 17:24
@buranmert buranmert added this to the next-version milestone Jan 29, 2021
@buranmert buranmert marked this pull request as ready for review January 29, 2021 17:27
@buranmert buranmert requested a review from a team as a code owner January 29, 2021 17:27
@buranmert buranmert force-pushed the buranmert/RUMM-961-error-type branch from 4e8cbba to 0e41097 Compare January 29, 2021 17:38
Copy link
Contributor

@acgh acgh left a comment

Choose a reason for hiding this comment

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

For context this is a first step we decided to take before thinking about/implementing a better structure for the input of DDErrors, which ideally would avoid repeating information like in that case title and message.
This PR looks good to me 🚀

Copy link
Member

@ncreated ncreated left a comment

Choose a reason for hiding this comment

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

Few comments left. Also, this PR musts be rebased onto recent master, so it generated @objc interop code too.

Comment on lines 213 to 215
/// User custom timings of the view
public struct CustomTimings: Codable {
}
Copy link
Member

Choose a reason for hiding this comment

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

We don't yet know how to support DataDog/rum-events-format#25 in rum-models-generator, but struct CustomTimigns doesn't seem to be the right way. We will probably need:

public let customTimings: [String: Int64]

Also, this is very puzzling for the user to see an empty struct in the public API.
→ as we don't support it yet, it should not change the public interface until it gets added in RUMM-1000.

@@ -203,10 +203,11 @@ internal class RUMResourceScope: RUMScope {
url: resourceURL
),
source: command.errorSource.toRUMDataFormat,
stack: command.stack
stack: command.stack,
type: command.errorMessage
Copy link
Member

Choose a reason for hiding this comment

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

Have you considered introducing command.errorType and setting it to dderror.title at the higher level?

// In RUMCommand

// TODO: RUMM-1042 The way of setting error.type must unified with Logging and Tracing 
self.errorType = dderror.title

This might be safer as a temporary solution, as the work of passing the value down to the scopes will be already done. Also, it limits the refactoring to single file (RUMCommands.swift).

Copy link
Contributor Author

@buranmert buranmert Feb 1, 2021

Choose a reason for hiding this comment

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

yes i thought about that but it makes more sense to make those changes in 1042

Comment on lines 91 to 94
// TODO: RUMM-1000 should remove this early return clause
if properties.isEmpty {
return
}
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 not the right place for this patch. rum-models-generator's architecture is build around the stream:

let rumModels = [*.json]  JSONSchema  JSONType  SwiftType -> RUM SwiftType

rumModels are then passed to SwiftPrinter() and ObjcInteropPrinter() for code generation. Instead of patching the printer(s), we should dismiss unsupported types as early as possible in the stream, so that it is not processed further causing unexpected behaviours.

Ideally, we should cut it off in JSONSchemaReader by explicitly deleting schemas which use unsupported additionalProperties modifier.

As this is temporary and short-living patch, fixing it in RUMSwiftTypeTransformer by filtering out the SwiftStruct named "CustomTimings" might be easier.

In any way, this should not reach the code generation, as it generates potentially wrong API (we may need to support additionalProperties in other way than a struct).

RUMModelsGenerator is patched: empty CodingKeys is not generated anymore
DDError.title is passed as error.kind in Logger
Now the same value is used as error.type in RUMEvents
@buranmert buranmert force-pushed the buranmert/RUMM-961-error-type branch 2 times, most recently from 629a21a to bb6e53f Compare February 1, 2021 13:53
@@ -94,7 +94,7 @@ internal class RUMSwiftTypeTransformer: TypeTransformer<SwiftType> {

var `struct` = `struct`
`struct`.name = format(structName: `struct`.name)
`struct`.properties = try `struct`.properties.map { try transform(structProperty: $0) }
`struct`.properties = try `struct`.properties.map { try transform(structProperty: $0) }.filter { property in property.name != "customTimings" }
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe add back the TODO: RUMM-1000 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.

oh yes definitely, thanks 🙏

DDError.title is passed as error.kind in Logger Now the same value is used as error.type in RUMEvents
@buranmert buranmert force-pushed the buranmert/RUMM-961-error-type branch from bb6e53f to 463e3b2 Compare February 1, 2021 14:16
@buranmert buranmert requested a review from ncreated February 1, 2021 14:43
Copy link
Member

@ncreated ncreated left a comment

Choose a reason for hiding this comment

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

LGT 👌

@buranmert buranmert merged commit 8b35eb7 into master Feb 2, 2021
@buranmert buranmert deleted the buranmert/RUMM-961-error-type branch February 2, 2021 09:08
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.

3 participants