ics receives and returns second-precision timestamps

[jeffgrunewald]

per the iot-config service proto definitions comments, the expected input timestamps for rpc requests are in millisecond precision but the responses are in second precision. this pushes the two into alignment so responses are now also in millisecond second precision.

doesn't require helium/proto#383 as the data type from the perspective of the proto definitions is unchanged but should be aligned shortly to provide clarity for rpc consumers

[ccall48]

Sorry I missed this...

Just to clarify, second and millisecond precision will both be accepted or do I have to recode all the iot rpc's to be second precision now?

[jeffgrunewald]

Sorry I missed this...

Just to clarify, second and millisecond precision will both be accepted or do I have to recode all the iot rpc's to be second precision now?

@ccall48 at the moment there's no change necessary on your end as the iot-config service is not validating the timestamps it's receiving with incoming rpc requests. They're still just uint64s. The only rpc that is changing how it interprets that timestamp uint64 is one that is only available to HPR.

That being said, I would advise putting it in your backlog to recode your IoT rpcs to second-level precision as we have it planned (as yet unprioritized) to validate timestamps on incoming requests are "fresh" (received within a minimal number of seconds of generation) to prevent replays or stale data populating the config service. That will have much bigger/earlier communication publicly since it would require changes by consumers of the api like yourself. Fair?

[ccall48]

Ok thanks Jeff, i was already sending them with signed time as millisecond precision. if i can switch all these to be second precision before this is enforced on the iot side this should be fine.

Thank you for the clarification.