-
Notifications
You must be signed in to change notification settings - Fork 134
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
Conversation
ac3b0c1
to
4e8cbba
Compare
4e8cbba
to
0e41097
Compare
There was a problem hiding this 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 DDError
s, which ideally would avoid repeating information like in that case title
and message
.
This PR looks good to me 🚀
There was a problem hiding this 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.
/// User custom timings of the view | ||
public struct CustomTimings: Codable { | ||
} |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
).
There was a problem hiding this comment.
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
// TODO: RUMM-1000 should remove this early return clause | ||
if properties.isEmpty { | ||
return | ||
} |
There was a problem hiding this comment.
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
629a21a
to
bb6e53f
Compare
@@ -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" } |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
bb6e53f
to
463e3b2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGT 👌
What and why?
As part of error tracking,
type: String?
is introduced toRUMErrorEvent.Error
This value is expected to be the same with
error.kind
inLogger
Logger
usesDDError.title
aserror.kind
How?
DDError.title
was already used inRUMErrorEvent.Error.message
propertyNow we basically use the same value in
message
andtype
properties of the same instanceReview checklist