While implementing the *traceGetContent endpoints in ultralight, I discovered that there are a couple of places in the traceResultObject where what trin returns doesn't match the current spec but that seem to be required for glados to support tracing of audits.
targetId - the spec calls for ^0x([1-9a-f][0-9a-f]{0,63}|0$) but trin returns an array of integers (presumably just converting byte array representation of the contentId directly to a JSON array).
@KolbyML confirmed this would be updated so trin and glados would accept the 0x prefixed string version of the contentID.
startedAtMs - the spec calls for an integer but trin returns an object of the form
I'm not certain how the nanos_since_epoch is calculated here since it seems to be a rust struct (from looking at the glados errors I was getting when I didn't populate this field in the Ultralight response) but assuming it makes sense to update the spec to match this (with clear definition of what the two properties are and how to compute them)
metadata - the spec calls for a map that looks like below. Trin adds a radius field to that always seems to be populated with null (not sure if this is needed for glados or not)
Since the radius always seems to be null, I'm not sure if this is a helpful additional element or not (though notionally get why it would be useful). Also, not sure if glados needs this value or not for audits
One other thing I noticed is that the playground representation of the spec doesn't currently expose all of the lower level traceResult types (notably traceResultMetadata and traceResultResponses) and you have to actually open the raw spec to see them. We should fix this so they are clickable from the playground interface. I'll figure out how to make these clickable so we can see them.
While implementing the
*traceGetContentendpoints inultralight, I discovered that there are a couple of places in thetraceResultObjectwhere whattrinreturns doesn't match the current spec but that seem to be required forgladosto support tracing of audits.targetId- the spec calls for^0x([1-9a-f][0-9a-f]{0,63}|0$)buttrinreturns an array of integers (presumably just converting byte array representation of the contentId directly to a JSON array).trinandgladoswould accept the0xprefixed string version of the contentID.startedAtMs- the spec calls for an integer buttrinreturns an object of the formnanos_since_epochis calculated here since it seems to be a rust struct (from looking at the glados errors I was getting when I didn't populate this field in the Ultralight response) but assuming it makes sense to update the spec to match this (with clear definition of what the two properties are and how to compute them)metadata- the spec calls for a map that looks like below. Trin adds a radius field to that always seems to be populated with null (not sure if this is needed for glados or not)null, I'm not sure if this is a helpful additional element or not (though notionally get why it would be useful). Also, not sure ifgladosneeds this value or not for auditsOne other thing I noticed is that the playground representation of the spec doesn't currently expose all of the lower level
traceResulttypes (notablytraceResultMetadataandtraceResultResponses) and you have to actually open the raw spec to see them. We should fix this so they are clickable from the playground interface. I'll figure out how to make these clickable so we can see them.