fix: catch potential overflow

[LorrensP-2158466]

Closes #25041

Describe your proposed changes here.
Do the multiplication with checked_mul and return Option<i64> instead of i64.
Also, 2 places use this function with Option::map, so I replaced those with Option::and_then

• I've read the contributing section of the project README.
• Signed CLA (if not already signed).

[hiltontj]

I think panicking on overflow is not as good as returning an error, but is better than what is being done with these changes. What will happen with these changes, in the event of an overflow, is the ingest time will be used as the timestamp for the written line. That is not likely the same as whatever timestamp was provided by the user, so the resulting writes would have unexpected timestamps.

If anything, the overflow should be checked in a previous validation step that is fallible, so an error can be returned to reject those lines, and provide an error message - indicating that there is likely a mismatch in the specified precision and the time value provided.

[LorrensP-2158466]

Yeah, when I pushed, I went over it again, and the changes didn't feel right to me, but I couldn't find a direct reason or how to solve it.
Thanks for the explanation! I'll try to find a better way of checking the overflow in the way that you mentioned.

Quick question with no urgency: the merge conflicts in Cargo.lock, how should I resolve them?

[hiltontj]

Quick question with no urgency: the merge conflicts in Cargo.lock, how should I resolve them?

If you can merge back the latest changes from the main branch on this repository, and resolve conflicts, that would probably do the trick. So, sync your fork, then locally you can git merge main from your current branch. Hopefully, the merge conflicts aren't a pain to deal with, but sometimes you have to go through and manually resolve them.