You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge pull request #279 from shelefg/codable_signals
Make Metric and SpanData conform to Codable to support persisting them.
This submission is making Metric and SpanData conform to Codable in order to allow them to be persisted. Being able to persist signals' data is required to support use cases where signals may collected when there is no network connectivity, and so they have to be exported later - possibly after the process was terminated and relaunched - when network connectivity is back.
The core of the change is making Metric and SpanData conform to the Codable protocol. To that end all the types Metric and SpanData depend on were made Codable as well.
Most of the types could simply have the Codable protocol implementation synthesized. However there were several cases where an explicit implementation was required:
Metric - explicit encoding & decoding logic was required to deduce the concrete type of Metric.data by Metric.aggregationType
AttributeValue - enum with associated values
Status - enum with associated values
HistogramData - has a tuple type member
Conflict with existing Encodable implementation used specifically in StdoutExporter. In this case an explicit Encodable implementation was written for SpanExporterData.
Tests were added to cover the encoding & decoding code, and corresponding Equatable conformance for Metric that was required for tests verification was added.
AttributeValue and Status use synthesized Codable implementation for swift >= 5.5
0 commit comments