decouple token data collection into independent spot/future/alpha checks
keep rendering behavior when any one source is available
add command-layer tests for spot-only reachability and future-failure-with-spot fallback
Test Plan
go test ./internal/services/tele/commands -run CollectRichTokenData -v -count=1
go test ./internal/services/tele/view -run RenderRichTokenMessage -v -count=1
go test ./... -count=1
## Summary
- decouple token data collection into independent spot/future/alpha checks
- keep rendering behavior when any one source is available
- add command-layer tests for spot-only reachability and future-failure-with-spot fallback
## Test Plan
- [x] go test ./internal/services/tele/commands -run CollectRichTokenData -v -count=1
- [x] go test ./internal/services/tele/view -run RenderRichTokenMessage -v -count=1
- [x] go test ./... -count=1
Collect token market data independently for spot, futures, and alpha so any available source can be rendered even if others fail.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Keep alpha token existence from list cache and fetch live alpha price via symbol ticker endpoint for richer token response accuracy.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
[High] collectRichTokenData regresses existing symbol resolution by hardcoding both lookups to token + "USDT" in internal/services/tele/commands/token.go:78 and :88.
That bypasses the existing resolver logic in internal/helper/binancex/symbol.go and the future-to-spot mapping in Future2SpotSymbol(...).
The repo already supports prefixed futures (1000, 1M), USDC shorthand (c), and mapped contracts like LUNA2USDT -> LUNAUSDT. Those cases can still enter the handler through binancex.IsToken(...), but the new collector now probes only <TOKEN>USDT, so supported aliases/mapped contracts can lose future data, spot data, or both.
env GOCACHE=/tmp/go-build-pr19 go test ./internal/services/tele/commands -run CollectRichTokenData -v -count=1
env GOCACHE=/tmp/go-build-pr19 go test ./internal/services/tele/view -run RenderRichTokenMessage -v -count=1
env GOCACHE=/tmp/go-build-pr19 go test ./... -count=1
env GOCACHE=/tmp/go-build-pr19 go vet ./...
Test gap:
the new tests cover straight ABCUSDT / ETHUSDT paths only; they do not cover the existing alias/prefix/mapping behavior that this change now bypasses.
Codex review results for PR #19.
FAIL
1. [High] `collectRichTokenData` regresses existing symbol resolution by hardcoding both lookups to `token + "USDT"` in `internal/services/tele/commands/token.go:78` and `:88`.
That bypasses the existing resolver logic in `internal/helper/binancex/symbol.go` and the future-to-spot mapping in `Future2SpotSymbol(...)`.
The repo already supports prefixed futures (`1000`, `1M`), `USDC` shorthand (`c`), and mapped contracts like `LUNA2USDT -> LUNAUSDT`. Those cases can still enter the handler through `binancex.IsToken(...)`, but the new collector now probes only `<TOKEN>USDT`, so supported aliases/mapped contracts can lose future data, spot data, or both.
Validation:
- `git fetch origin`
- `git worktree add ../.worktree/pr-19 origin/feat/token-message-rich`
- `env GOCACHE=/tmp/go-build-pr19 go test ./internal/services/tele/commands -run CollectRichTokenData -v -count=1`
- `env GOCACHE=/tmp/go-build-pr19 go test ./internal/services/tele/view -run RenderRichTokenMessage -v -count=1`
- `env GOCACHE=/tmp/go-build-pr19 go test ./... -count=1`
- `env GOCACHE=/tmp/go-build-pr19 go vet ./...`
Test gap:
- the new tests cover straight `ABCUSDT` / `ETHUSDT` paths only; they do not cover the existing alias/prefix/mapping behavior that this change now bypasses.
The concern from my previous review comment is about spot/future symbol resolution only. It is not about the new Alpha lookup itself.
More specifically, the follow-up concern is that the new independent collector now probes spot/future as <TOKEN>USDT directly, which can bypass the existing spot/future resolver rules for prefixes, aliases, and future->spot mappings.
I split that concern into a separate issue so it can be handled independently from Alpha lookup changes:
#21 Token collector bypasses existing spot/future symbol resolution rules
So to be explicit:
Alpha lookup direction in this PR is not the concern I am calling out here.
The extracted follow-up concern is only about spot/future resolution behavior.
[codex] scope clarification for PR #19.
The concern from my previous review comment is about spot/future symbol resolution only. It is not about the new Alpha lookup itself.
More specifically, the follow-up concern is that the new independent collector now probes spot/future as `<TOKEN>USDT` directly, which can bypass the existing spot/future resolver rules for prefixes, aliases, and future->spot mappings.
I split that concern into a separate issue so it can be handled independently from Alpha lookup changes:
- #21 Token collector bypasses existing spot/future symbol resolution rules
So to be explicit:
- Alpha lookup direction in this PR is not the concern I am calling out here.
- The extracted follow-up concern is only about spot/future resolution behavior.
thuanle
merged commit 1486681ef9 into main2026-04-26 18:51:18 +07:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
Test Plan
Codex review results for PR #19.
FAIL
collectRichTokenDataregresses existing symbol resolution by hardcoding both lookups totoken + "USDT"ininternal/services/tele/commands/token.go:78and:88.That bypasses the existing resolver logic in
internal/helper/binancex/symbol.goand the future-to-spot mapping inFuture2SpotSymbol(...).The repo already supports prefixed futures (
1000,1M),USDCshorthand (c), and mapped contracts likeLUNA2USDT -> LUNAUSDT. Those cases can still enter the handler throughbinancex.IsToken(...), but the new collector now probes only<TOKEN>USDT, so supported aliases/mapped contracts can lose future data, spot data, or both.Validation:
git fetch origingit worktree add ../.worktree/pr-19 origin/feat/token-message-richenv GOCACHE=/tmp/go-build-pr19 go test ./internal/services/tele/commands -run CollectRichTokenData -v -count=1env GOCACHE=/tmp/go-build-pr19 go test ./internal/services/tele/view -run RenderRichTokenMessage -v -count=1env GOCACHE=/tmp/go-build-pr19 go test ./... -count=1env GOCACHE=/tmp/go-build-pr19 go vet ./...Test gap:
ABCUSDT/ETHUSDTpaths only; they do not cover the existing alias/prefix/mapping behavior that this change now bypasses.[codex] scope clarification for PR #19.
The concern from my previous review comment is about spot/future symbol resolution only. It is not about the new Alpha lookup itself.
More specifically, the follow-up concern is that the new independent collector now probes spot/future as
<TOKEN>USDTdirectly, which can bypass the existing spot/future resolver rules for prefixes, aliases, and future->spot mappings.I split that concern into a separate issue so it can be handled independently from Alpha lookup changes:
So to be explicit: