public/crypto-price-bot
6
0
Fork 0
Code Issues 1 Pull Requests 2 Actions Packages Projects Releases Wiki Activity

Rich token message handler cannot reach spot-only fallback #18

New Issue
Closed
opened 2026-04-26 18:00:00 +07:00 by thuanle · 1 comment
thuanle commented 2026-04-26 18:00:00 +07:00
Owner
Copy Link
Copy Source

The new rich token message flow models spot-only in the renderer and spec, but the command handler cannot currently reach that state end-to-end.

Problem

  • Token2Symbols only resolves symbols through the futures pair cache (internal/helper/binancex/symbol.go:31-32).
  • OnTokenInfoByToken only fetches spot inside the successful futures branch (internal/services/tele/commands/token.go:86-100).

Impact

  1. Tokens that exist on spot but not futures can never render the documented spot-only message path.
  2. Even for tokens that have both markets, a transient futures lookup failure prevents spot from being fetched, so the handler can return no reply unless Alpha data exists.

Why this matters

The design/spec explicitly documents spot-only as a supported fallback case, but the current data-collection logic only makes that state reachable inside renderer tests, not from the Telegram command flow.

Test gap

Current tests cover RenderRichTokenMessage(...) and buildRichTokenMessageInput(...), but they do not exercise the handler logic that collects spot/future/alpha data.

Suggested direction

  • Decouple spot lookup from future lookup success.
  • Add a spot-aware symbol resolution path (or use spot pair cache) so spot-only can be reached from OnTokenInfoByToken.
  • Add handler-level tests for the fallback matrix, especially spot-only and future lookup fails but spot exists.

Context

This is a follow-up logic issue discovered while reviewing PR #17. It is separate from the display-format review comments on that PR.

The new rich token message flow models `spot-only` in the renderer and spec, but the command handler cannot currently reach that state end-to-end. Problem - `Token2Symbols` only resolves symbols through the futures pair cache (`internal/helper/binancex/symbol.go:31-32`). - `OnTokenInfoByToken` only fetches spot inside the successful futures branch (`internal/services/tele/commands/token.go:86-100`). Impact 1. Tokens that exist on spot but not futures can never render the documented `spot-only` message path. 2. Even for tokens that have both markets, a transient futures lookup failure prevents spot from being fetched, so the handler can return no reply unless Alpha data exists. Why this matters The design/spec explicitly documents `spot-only` as a supported fallback case, but the current data-collection logic only makes that state reachable inside renderer tests, not from the Telegram command flow. Test gap Current tests cover `RenderRichTokenMessage(...)` and `buildRichTokenMessageInput(...)`, but they do not exercise the handler logic that collects spot/future/alpha data. Suggested direction - Decouple spot lookup from future lookup success. - Add a spot-aware symbol resolution path (or use spot pair cache) so `spot-only` can be reached from `OnTokenInfoByToken`. - Add handler-level tests for the fallback matrix, especially `spot-only` and `future lookup fails but spot exists`. Context This is a follow-up logic issue discovered while reviewing PR #17. It is separate from the display-format review comments on that PR.
thuanle commented 2026-04-26 19:17:26 +07:00
Author
Owner
Copy Link
Copy Source

[claudecode gpt-5.3-codex]

Summary

Issue này đã được xử lý qua các PR đã merge.

Changes mapped to issue

  • PR #19: tách độc lập các lookup spot/future/alpha trong command handler, nên nhánh spot-only giờ reachable end-to-end.
  • PR #19: không còn phụ thuộc thành công futures để mới fetch spot, nên case "future lookup fail nhưng spot tồn tại" vẫn trả message.
  • PR #19: bổ sung test handler-level cho đúng fallback matrix.
  • PR #20: tối ưu hiệu năng bằng chạy lookup song song, không đổi behavior logic đã fix ở #19.

Verification references

  • internal/services/tele/commands/token.go
  • internal/services/tele/commands/token_test.go

Đề xuất: close issue #18.

[claudecode gpt-5.3-codex] ## Summary Issue này đã được xử lý qua các PR đã merge. ## Changes mapped to issue - PR #19: tách độc lập các lookup spot/future/alpha trong command handler, nên nhánh `spot-only` giờ reachable end-to-end. - PR #19: không còn phụ thuộc thành công futures để mới fetch spot, nên case "future lookup fail nhưng spot tồn tại" vẫn trả message. - PR #19: bổ sung test handler-level cho đúng fallback matrix. - PR #20: tối ưu hiệu năng bằng chạy lookup song song, không đổi behavior logic đã fix ở #19. ## Verification references - `internal/services/tele/commands/token.go` - `internal/services/tele/commands/token_test.go` Đề xuất: close issue #18.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
antigravity claudecode codex devops renovatebot thuanle
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: public/crypto-price-bot#18
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?