Closed Nana-EC closed 4 years ago
Seems to be a result of a user using a data time outside what we expected
Feb 1 19:32:03 mirrornode-testnet-grpc-1 java[816]: 2020-02-01 19:32:03,897 INFO [grpc-default-executor-724] c.h.m.g.s.TopicMessageServiceImpl Subscribing to topic: TopicMessageFilter(endTime=null, limit=0, realmNum=0, startTime=0001-01-01T00:00:00Z, topicNum=159463)
Though the overflow is expected it disturbs the flows and produces unnecessary unhandled exceptions.
2 solutions were considered 1) Scope it in so any overflows for startTime are set to EPOCH, and any overflows for endTime result in no endTime getting set. Documentation would need to be updated to reflect this expectation. 2) Return an empty stream, or a single terminating element in the stream to the client with the error noting there was an issue with the startTime or endTime. It should be an error that doesn't trigger alerts on single occurences though.
After some deliberation and noting that most developers might prescribe the following, we decided to go with #1 MirrorConsensusTopicQuery.setStartTime(Instant.MIN).setEndTime(Instant.MAX) -> would cause overflow everytime
Over the weekend during normal and non-peak operations of the tesnet the GRPC module triggered an alert that was caused by an ArithmeticException: long overflow.
This occurred about 3 times https://hedera.pagerduty.com/incidents/P0VGW2Z
The error seems to come from the InstantToLongConverter.convert() which takes an Instant and converts it to a Long. This happens when the startTime and endTime of a TopicMessageFilter object are converted to longs when creation the DB whereClause Criteria object in TopicMessageRepositoryCustomImpl.findByFilter()
The code base has tests that confirm this logic and as such it's by design. Will confirm that no action needs to be taken and there's no unintended impact.
At the least if this is expected we shouldn't alert on it.
error encountered