Implement total_x metrics - #417
Conversation
schottra
left a comment
schottra
left a comment
There was a problem hiding this comment.
Looks good. I know we're probably unlikely to hit 9,007,199,254,740,991-ish plays any time soon, so feel free to ignore my bigint comment. I just find it weird that it's not an error or something to attempt to serialize an int64 to JSON... :-)
| return err | ||
| } | ||
|
|
||
| return c.JSON(fiber.Map{"data": map[string]int64{"total": total}}) |
There was a problem hiding this comment.
I guess I'm on a bigint kick lately.
This feels slightly off, as JSON can't represent an int64. I wonder if it just lets it truncate if you exceed the limits.
Supposedly, it should serialize as a string if you want to represent an int64.
There was a problem hiding this comment.
JSON can represent it, it's JS that can't handle it w/o precision loss. I do agree that it should be a string, but i don't think that's worth the annoyance of translating it from a number everywhere we use it. we'll ever get anywhere near 2^53 for this
| func (app *ApiServer) v1MetricsTotalWallets(c *fiber.Ctx) error { | ||
| var total int64 | ||
| if err := app.pool.QueryRow(c.Context(), ` | ||
| SELECT COUNT(*)::bigint |
There was a problem hiding this comment.
So we're saying wallets == users?
There was a problem hiding this comment.
i guess we can do something crazy and count distinct across all wallet types but it feels a little ridiculous. wdyt?
There was a problem hiding this comment.
I was more curious what the metric is supposed to mean and why we are exposing it.
We could do something like sum this count with the count of the associated wallets table to just get total wallets that exist in the system.
But only if that's something we care about. This feels fine as it is.
There was a problem hiding this comment.
yeah fair enough, i think it's really just 'how many parking spots have we claimed on chain' which i think this is a reasonable proxy for.
that being said, im going to update this to
SELECT SUM(count) AS total_rows
FROM (
SELECT COUNT() AS count FROM users
UNION ALL
SELECT COUNT() AS count FROM sol_claimable_accounts
) AS combined;
because why not
* origin/main: Implement total_x metrics (#417)
…audio#421) (#996) Bumps both `github.com/OpenAudio/go-openaudio` and `.../pkg/etl` pins from `b4a5ebe` (2026-07-16) to `1d9f697` — the merge of **OpenAudio/go-openaudio#421**, same flow as #994 did for the #410 CID fix. ## What the new pin brings (ETL / entity manager) - Persist `orig_filename` on track create/update (never-clear, like the CIDs) — new stem rows no longer rely on the `/stems` endpoint's title fallback - Ignore explicit `"stem_of": null` on track updates so client edits can't unlink a stem from its parent (#410 failure class) - Upsert the `stems` join row when an update carries `stem_of` (on-chain repair path for lost links) Intervening upstream commits also included (library-only for api): mediorum transcode/retry fixes (#338, #417–#419) and core/logging spam guards (#420). Nothing release- or mainnet-config-related. ## Relation to #995 #995 is the unblocking change (endpoint tolerates NULLs already in the DB); this bump prevents recurrence at the write path. Both trace back to the July stems-invisible incident (Andrew Lux's "Alone" remix contest). Verified locally: `go build ./...`, stems endpoint tests, and `go test ./indexer/...` all pass on the new pin. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
2 participants
v1/metrics/total_plays
to reach parity with discovery
add
v1/metrics/total_artists
v1/metrics/total_wallets
to support new querying behavior