Implement total_x metrics by raymondjacobson · Pull Request #417 · AudiusProject/api

raymondjacobson · 2025-09-24T06:21:22Z

v1/metrics/total_plays
to reach parity with discovery

add
v1/metrics/total_artists
v1/metrics/total_wallets
to support new querying behavior

schottra

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... :-)

schottra · 2025-09-24T14:36:51Z

+ return err
+	}
+
+	return c.JSON(fiber.Map{"data": map[string]int64{"total": total}})


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.

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

schottra · 2025-09-24T14:40:37Z

+func (app *ApiServer) v1MetricsTotalWallets(c *fiber.Ctx) error {
+	var total int64
+	if err := app.pool.QueryRow(c.Context(), `
+ SELECT COUNT(*)::bigint


So we're saying wallets == users?

i guess we can do something crazy and count distinct across all wallet types but it feels a little ridiculous. wdyt?

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.

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>

raymondjacobson · 2025-09-24T06:21:22Z

v1/metrics/total_plays
to reach parity with discovery

add
v1/metrics/total_artists
v1/metrics/total_wallets
to support new querying behavior

schottra

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... :-)

schottra · 2025-09-24T14:36:51Z

+ return err
+	}
+
+	return c.JSON(fiber.Map{"data": map[string]int64{"total": total}})


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.

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

schottra · 2025-09-24T14:40:37Z

+func (app *ApiServer) v1MetricsTotalWallets(c *fiber.Ctx) error {
+	var total int64
+	if err := app.pool.QueryRow(c.Context(), `
+ SELECT COUNT(*)::bigint


So we're saying wallets == users?

i guess we can do something crazy and count distinct across all wallet types but it feels a little ridiculous. wdyt?

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.

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>

raymondjacobson · 2025-09-24T06:21:22Z

v1/metrics/total_plays
to reach parity with discovery

add
v1/metrics/total_artists
v1/metrics/total_wallets
to support new querying behavior

schottra

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... :-)

schottra · 2025-09-24T14:36:51Z

+ return err
+	}
+
+	return c.JSON(fiber.Map{"data": map[string]int64{"total": total}})


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.

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

schottra · 2025-09-24T14:40:37Z

+func (app *ApiServer) v1MetricsTotalWallets(c *fiber.Ctx) error {
+	var total int64
+	if err := app.pool.QueryRow(c.Context(), `
+ SELECT COUNT(*)::bigint


So we're saying wallets == users?

i guess we can do something crazy and count distinct across all wallet types but it feels a little ridiculous. wdyt?

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.

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>

raymondjacobson · 2025-09-24T06:21:22Z

v1/metrics/total_plays
to reach parity with discovery

add
v1/metrics/total_artists
v1/metrics/total_wallets
to support new querying behavior

schottra

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... :-)

schottra · 2025-09-24T14:36:51Z

+ return err
+	}
+
+	return c.JSON(fiber.Map{"data": map[string]int64{"total": total}})


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.

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

schottra · 2025-09-24T14:40:37Z

+func (app *ApiServer) v1MetricsTotalWallets(c *fiber.Ctx) error {
+	var total int64
+	if err := app.pool.QueryRow(c.Context(), `
+ SELECT COUNT(*)::bigint


So we're saying wallets == users?

i guess we can do something crazy and count distinct across all wallet types but it feels a little ridiculous. wdyt?

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.

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>

raymondjacobson · 2025-09-24T06:21:22Z

v1/metrics/total_plays
to reach parity with discovery

add
v1/metrics/total_artists
v1/metrics/total_wallets
to support new querying behavior

schottra

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... :-)

schottra · 2025-09-24T14:36:51Z

+ return err
+	}
+
+	return c.JSON(fiber.Map{"data": map[string]int64{"total": total}})


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.

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

schottra · 2025-09-24T14:40:37Z

+func (app *ApiServer) v1MetricsTotalWallets(c *fiber.Ctx) error {
+	var total int64
+	if err := app.pool.QueryRow(c.Context(), `
+ SELECT COUNT(*)::bigint


So we're saying wallets == users?

i guess we can do something crazy and count distinct across all wallet types but it feels a little ridiculous. wdyt?

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.

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>

raymondjacobson · 2025-09-24T06:21:22Z

v1/metrics/total_plays
to reach parity with discovery

add
v1/metrics/total_artists
v1/metrics/total_wallets
to support new querying behavior

schottra

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... :-)

schottra · 2025-09-24T14:36:51Z

+ return err
+	}
+
+	return c.JSON(fiber.Map{"data": map[string]int64{"total": total}})


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.

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

schottra · 2025-09-24T14:40:37Z

+func (app *ApiServer) v1MetricsTotalWallets(c *fiber.Ctx) error {
+	var total int64
+	if err := app.pool.QueryRow(c.Context(), `
+ SELECT COUNT(*)::bigint


So we're saying wallets == users?

i guess we can do something crazy and count distinct across all wallet types but it feels a little ridiculous. wdyt?

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.

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>

raymondjacobson · 2025-09-24T06:21:22Z

v1/metrics/total_plays
to reach parity with discovery

add
v1/metrics/total_artists
v1/metrics/total_wallets
to support new querying behavior

schottra

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... :-)

schottra · 2025-09-24T14:36:51Z

+ return err
+	}
+
+	return c.JSON(fiber.Map{"data": map[string]int64{"total": total}})


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.

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

schottra · 2025-09-24T14:40:37Z

+func (app *ApiServer) v1MetricsTotalWallets(c *fiber.Ctx) error {
+	var total int64
+	if err := app.pool.QueryRow(c.Context(), `
+ SELECT COUNT(*)::bigint


So we're saying wallets == users?

i guess we can do something crazy and count distinct across all wallet types but it feels a little ridiculous. wdyt?

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.

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>

raymondjacobson · 2025-09-24T06:21:22Z

v1/metrics/total_plays
to reach parity with discovery

add
v1/metrics/total_artists
v1/metrics/total_wallets
to support new querying behavior

schottra

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... :-)

schottra · 2025-09-24T14:36:51Z

+ return err
+	}
+
+	return c.JSON(fiber.Map{"data": map[string]int64{"total": total}})


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.

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

schottra · 2025-09-24T14:40:37Z

+func (app *ApiServer) v1MetricsTotalWallets(c *fiber.Ctx) error {
+	var total int64
+	if err := app.pool.QueryRow(c.Context(), `
+ SELECT COUNT(*)::bigint


So we're saying wallets == users?

i guess we can do something crazy and count distinct across all wallet types but it feels a little ridiculous. wdyt?

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.

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>

Implement total_x metrics
3e4306e

raymondjacobson requested a review from schottra September 24, 2025 06:21

schottra approved these changes Sep 24, 2025
View reviewed changes

Better total wallets
5c1f6fe

raymondjacobson merged commit 5e00c8d into mainSep 24, 2025
4 of 5 checks passed

raymondjacobson deleted the rj-totals branch September 24, 2025 17:33

schottra added a commit that referenced this pull request Sep 24, 2025
Merge remote-tracking branch 'origin/main' into fix-test-schema
9b8bf48
* origin/main: Implement total_x metrics (#417)

dylanjeffers mentioned this pull request Jul 27, 2026
chore: bump go-openaudio to pick up ETL stem fixes (OpenAudio/go-openaudio#421) #996
Merged

Implement total_x metrics
3e4306e

raymondjacobson requested a review from schottra September 24, 2025 06:21

schottra approved these changes Sep 24, 2025
View reviewed changes

Better total wallets
5c1f6fe

raymondjacobson merged commit 5e00c8d into mainSep 24, 2025
4 of 5 checks passed

raymondjacobson deleted the rj-totals branch September 24, 2025 17:33

schottra added a commit that referenced this pull request Sep 24, 2025
Merge remote-tracking branch 'origin/main' into fix-test-schema
9b8bf48
* origin/main: Implement total_x metrics (#417)

dylanjeffers mentioned this pull request Jul 27, 2026
chore: bump go-openaudio to pick up ETL stem fixes (OpenAudio/go-openaudio#421) #996
Merged

Implement total_x metrics
3e4306e

raymondjacobson requested a review from schottra September 24, 2025 06:21

schottra approved these changes Sep 24, 2025
View reviewed changes

Better total wallets
5c1f6fe

raymondjacobson merged commit 5e00c8d into mainSep 24, 2025
4 of 5 checks passed

raymondjacobson deleted the rj-totals branch September 24, 2025 17:33

schottra added a commit that referenced this pull request Sep 24, 2025
Merge remote-tracking branch 'origin/main' into fix-test-schema
9b8bf48
* origin/main: Implement total_x metrics (#417)

dylanjeffers mentioned this pull request Jul 27, 2026
chore: bump go-openaudio to pick up ETL stem fixes (OpenAudio/go-openaudio#421) #996
Merged

Implement total_x metrics
3e4306e

raymondjacobson requested a review from schottra September 24, 2025 06:21

schottra approved these changes Sep 24, 2025
View reviewed changes

Better total wallets
5c1f6fe

raymondjacobson merged commit 5e00c8d into mainSep 24, 2025
4 of 5 checks passed

raymondjacobson deleted the rj-totals branch September 24, 2025 17:33

schottra added a commit that referenced this pull request Sep 24, 2025
Merge remote-tracking branch 'origin/main' into fix-test-schema
9b8bf48
* origin/main: Implement total_x metrics (#417)

dylanjeffers mentioned this pull request Jul 27, 2026
chore: bump go-openaudio to pick up ETL stem fixes (OpenAudio/go-openaudio#421) #996
Merged

Implement total_x metrics
3e4306e

raymondjacobson requested a review from schottra September 24, 2025 06:21

schottra approved these changes Sep 24, 2025
View reviewed changes

Better total wallets
5c1f6fe

raymondjacobson merged commit 5e00c8d into mainSep 24, 2025
4 of 5 checks passed

raymondjacobson deleted the rj-totals branch September 24, 2025 17:33

schottra added a commit that referenced this pull request Sep 24, 2025
Merge remote-tracking branch 'origin/main' into fix-test-schema
9b8bf48
* origin/main: Implement total_x metrics (#417)

dylanjeffers mentioned this pull request Jul 27, 2026
chore: bump go-openaudio to pick up ETL stem fixes (OpenAudio/go-openaudio#421) #996
Merged

Implement total_x metrics
3e4306e

raymondjacobson requested a review from schottra September 24, 2025 06:21

schottra approved these changes Sep 24, 2025
View reviewed changes

Better total wallets
5c1f6fe

raymondjacobson merged commit 5e00c8d into mainSep 24, 2025
4 of 5 checks passed

raymondjacobson deleted the rj-totals branch September 24, 2025 17:33

schottra added a commit that referenced this pull request Sep 24, 2025
Merge remote-tracking branch 'origin/main' into fix-test-schema
9b8bf48
* origin/main: Implement total_x metrics (#417)

dylanjeffers mentioned this pull request Jul 27, 2026
chore: bump go-openaudio to pick up ETL stem fixes (OpenAudio/go-openaudio#421) #996
Merged

Implement total_x metrics
3e4306e

raymondjacobson requested a review from schottra September 24, 2025 06:21

schottra approved these changes Sep 24, 2025
View reviewed changes

Better total wallets
5c1f6fe

raymondjacobson merged commit 5e00c8d into mainSep 24, 2025
4 of 5 checks passed

raymondjacobson deleted the rj-totals branch September 24, 2025 17:33

schottra added a commit that referenced this pull request Sep 24, 2025
Merge remote-tracking branch 'origin/main' into fix-test-schema
9b8bf48
* origin/main: Implement total_x metrics (#417)

dylanjeffers mentioned this pull request Jul 27, 2026
chore: bump go-openaudio to pick up ETL stem fixes (OpenAudio/go-openaudio#421) #996
Merged

Implement total_x metrics
3e4306e

raymondjacobson requested a review from schottra September 24, 2025 06:21

schottra approved these changes Sep 24, 2025
View reviewed changes

Better total wallets
5c1f6fe

raymondjacobson merged commit 5e00c8d into mainSep 24, 2025
4 of 5 checks passed

raymondjacobson deleted the rj-totals branch September 24, 2025 17:33

schottra added a commit that referenced this pull request Sep 24, 2025
Merge remote-tracking branch 'origin/main' into fix-test-schema
9b8bf48
* origin/main: Implement total_x metrics (#417)

dylanjeffers mentioned this pull request Jul 27, 2026
chore: bump go-openaudio to pick up ETL stem fixes (OpenAudio/go-openaudio#421) #996
Merged

Uh oh!

Conversation

raymondjacobson commented Sep 24, 2025

Uh oh!

schottra left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

raymondjacobson commented Sep 24, 2025

Uh oh!

schottra left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

raymondjacobson commented Sep 24, 2025

Uh oh!

schottra left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects