kami d0ca479d4f fix: serialize the per-host throttle so MusicBrainz rate limiting holds
throttle() read lastRequestAt, awaited delay(), then wrote it back — a
TOCTOU race with no mutex or queue, under concurrency: 10. Ten jobs read the
same timestamp, slept the same duration and fired in the same tick, giving
up to ~10 req/s against MusicBrainz's 1 req/s policy and risking an IP
block.

Replaced the lastRequestAt map with a per-host { lastRequestAt, tail }
limiter; each call links onto that host's promise chain, so the
read-sleep-write critical section is serialized and N concurrent callers
space out by minIntervalMs. Chain rejections are swallowed so one failure
cannot poison the queue. Per-host rather than global, so other integrations
are not starved by MusicBrainz.

Measured: 5 concurrent same-host calls at 200ms -> 802ms (previously all in
one tick); 3 distinct hosts at 1000ms -> 0ms, confirming no cross-host
starvation.

musicbrainz.client caught HttpError and returned null at all 7 catch sites,
making a rate-limited MusicBrainz indistinguishable from "no data for your
library" while every job reported success. A shared logMbFailure() now logs
429 (and 503 whose body mentions a rate limit) at error, stating results are
INCOMPLETE. The error model is otherwise unchanged.

REVIEW-2026-07-30.md finding 8.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-30 23:50:08 +04:00

muzick

A high-performance, distributed music orchestration and recommendation platform.

Overview

muzick is designed to manage a local music library while providing an "infinite vibe" listening experience. It bridges the gap between a local filesystem and advanced discovery engines through a tiered recommendation architecture.

Tech Stack

Frontend

  • Framework: React
  • Routing: TanStack Router
  • Data Fetching: TanStack Query (with Look-ahead Buffering)
  • State Management: Zustand (for Session/Vibe state)
  • Styling: CSS Variables (Customizable Themes)

Backend

  • Runtime: Node.js / TypeScript
  • Framework: Fastify
  • Task Queue: BullMQ (via Redis)
  • Search: Typesense

Infrastructure & Data

  • Database: PostgreSQL (Source of truth for metadata, relationships, and session state)
  • Cache/Queue: Redis
  • Audio Analysis: Essentia (via Worker processes)
  • External Metadata: MusicBrainz, Discogs, LRCLib, Cover Art Archive

Core Concepts

  • The Rolling Vibe: A continuous, evolving stream of music that uses a "Rolling Window" of tracks. It interleaves owned library tracks with high-probability "probation" tracks (external discoveries).
  • The Dislike Lifecycle: A multi-stage state machine that protects users from accidental deletions while ensuring the library stays clean.
  • Tiered Similarity: Instant metadata-based matches, followed by deep audio-feature similarity.

Getting Started

Prerequisites

  • Docker & Docker Compose

Running Locally

docker-compose up -d
S
Description
No description provided
Readme 2.7 MiB
Languages
TypeScript 95.5%
PLpgSQL 2.4%
CSS 1.4%
JavaScript 0.4%
Dockerfile 0.2%