Commit 065b0a2
fix(laboratory): make pairingReceiveSessionProposal canary metric reliably emit
The "AppKit Receive Session Proposal Timing > 7000ms" Grafana alerts (all 4
regions) were firing on No-Data, not on real latency. Their query targets
HappyPath.sign.timing.pairingReceiveSessionProposal, which the canary only
recorded when pairingCreatedTime was set — and that was captured by scraping a
WalletConnect "set core/pairing/pairing" console log that no longer fires. So
the metric was never published (0 datapoints in CloudWatch), while the
unconditional receiveSessionProposal metric stayed healthy (~1.8s).
Capture pairingCreatedTime deterministically when the wallet begins processing
the connection URI instead of depending on SDK console output, and push the
metric unconditionally. The metric name is unchanged, so the existing Grafana
alert starts receiving data with no dashboard change.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>1 parent 50c531a commit 065b0a2
1 file changed
Lines changed: 12 additions & 10 deletions
File tree
Lines changed: 12 additions & 10 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
15 | 15 | | |
16 | 16 | | |
17 | 17 | | |
18 | | - | |
19 | 18 | | |
20 | 19 | | |
21 | 20 | | |
22 | 21 | | |
23 | 22 | | |
24 | 23 | | |
25 | 24 | | |
26 | | - | |
27 | | - | |
28 | | - | |
29 | 25 | | |
30 | 26 | | |
31 | 27 | | |
| |||
51 | 47 | | |
52 | 48 | | |
53 | 49 | | |
| 50 | + | |
| 51 | + | |
| 52 | + | |
| 53 | + | |
| 54 | + | |
| 55 | + | |
| 56 | + | |
| 57 | + | |
54 | 58 | | |
55 | 59 | | |
56 | 60 | | |
| |||
69 | 73 | | |
70 | 74 | | |
71 | 75 | | |
72 | | - | |
73 | | - | |
74 | | - | |
75 | | - | |
76 | | - | |
77 | | - | |
| 76 | + | |
| 77 | + | |
| 78 | + | |
| 79 | + | |
78 | 80 | | |
79 | 81 | | |
80 | 82 | | |
| |||
0 commit comments