chore: Update GaslessRelayer logging with processing time#3238
chore: Update GaslessRelayer logging with processing time#3238dijanin-brat wants to merge 9 commits into
Conversation
| const delta = (tEnd - tStart) / 1000; | ||
| log("info", `Processed ${origin} depositId ${depositId} in ${delta} seconds.`); | ||
| const submitToProcessedTime = (tEnd - new Date(depositMessage.submittedAt).getTime()) / 1000; | ||
| log("info", `Processed ${origin} depositId ${depositId} in ${delta} seconds.`, { submitToProcessedTime }); |
There was a problem hiding this comment.
Naming is hard, but I am wondering about tSubmitDelta or something?
Note also that we will emit this log when we are re-processing an existing deposit (i.e. if it was already deposited and/or filled), in which case the timestamp won't be reliable. That might reduce the utility of this.
There was a problem hiding this comment.
Yes, it will log even if the deposit is processed already, tho this can be the final trigger for us to refactor this and discard all deposits that have already been processed when new bot instance start?
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d6f8428819
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const tEnd = performance.now(); | ||
| const delta = (tEnd - tStart) / 1000; | ||
| log("info", `Processed ${origin} depositId ${depositId} in ${delta} seconds.`); | ||
| const tSubmitDelta = (tEnd - new Date(depositMessage.submittedAt).getTime()) / 1000; |
There was a problem hiding this comment.
Compute submit latency from wall-clock timestamp
tSubmitDelta is calculated by subtracting an epoch timestamp (new Date(depositMessage.submittedAt).getTime()) from performance.now(), but performance.now() is process-relative monotonic time, not wall-clock time. In this path the value will be a large negative number for every message, so the new latency log is always incorrect and can mislead any monitoring based on tSubmitDelta.
Useful? React with 👍 / 👎.
No description provided.