- How do I install and configure calliostro/discogs-bundle?
- Install it with composer require calliostro/discogs-bundle, then add your credentials to config/packages/calliostro_discogs.yaml. The simplest setup is a personal_access_token read from an environment variable such as DISCOGS_PERSONAL_ACCESS_TOKEN. You can also set optional user_agent and rate_limiter keys in the same file. Because the bundle relies on autowiring, no manual service registration is needed.
- Do I need a Discogs personal access token or OAuth consumer credentials?
- Either works, but a personal access token is the recommended path: generate one in your Discogs developer settings and you get access to account data plus higher rate limits. If you are building a multi-user OAuth application, configure consumer_key and consumer_secret instead. OAuth 1.0a handling has been built into the client since v4.0, so no external OAuth library is required.
- How does rate limiting work in calliostro/discogs-bundle?
- Set the rate_limiter config key to the ID of a configured Symfony RateLimiterFactory service, which requires symfony/rate-limiter to be installed. Discogs calls then pass through that limiter so you stay inside API quotas. Leave the key out and requests go straight to the API without throttling. If you already have custom throttling in place, benchmark Symfony's limiter against it before swapping.
- What do auto_retry and max_retries do in calliostro/discogs-bundle v4.1?
- These two new config keys move retry handling into the package boundary: auto_retry defaults to true and max_retries defaults to 3. Retries are triggered by Discogs 429 rate limit and 503 server overload responses. Backoff from those retries increases worst-case request time, so check the numbers against your queue job timeouts and HTTP client timeouts.
- Is calliostro/discogs-bundle 4.1 a breaking change from 4.0?
- No. v4.1.0 is additive only, with no deprecations and no method signature changes, so a composer update is enough, followed by an optional config publish or merge to pick up auto_retry and max_retries. One housekeeping detail: the php-cs-fixer config moved from .php-cs-fixer.php to .php-cs-fixer.dist.php, so repoint any custom configuration. Upgrading from v3.x is a different story and requires a full migration with no backward compatibility.
- Which PHP and Symfony versions does calliostro/discogs-bundle support?
- It requires PHP 8.1 or newer, and CI now covers PHP 8.1 through 8.6. v4.1 extends the Symfony support matrix to 7.x plus 8.0, 8.1, and 8.2, while remaining compatible with Symfony 6.4. Legacy PHP versions below 8.1 are not supported.
- Can I use calliostro/discogs-bundle in a Laravel application?
- The package is a Symfony bundle, so its autowiring, YAML configuration, and RateLimiterFactory integration are Symfony-specific and Laravel does not register bundles. In Laravel you would normally install the underlying calliostro/php-discogs-api client, bind it in a service provider, and use Laravel's own cache-based rate limiter and HTTP retry middleware. Laravel 9+ already ships the Symfony components the client depends on, so PHP 8.1 is the main requirement. Reach for the bundle itself when you are actually running Symfony.
- How do I avoid double retries when calling Discogs from Laravel queues?
- With auto_retry defaulting to true, package-level retries stack on top of queue tries and HTTP client middleware, multiplying attempts on a 429 or 503. Set max_retries deliberately, or disable auto_retry on job paths where an outer retry layer already exists. Before leaving resilience on globally, confirm which Discogs write endpoints, such as collection, wantlist, or order calls, are actually safe to retry.
- How do I test a Discogs integration without hitting the live API?
- Because the client is autowired, you can type-hint the client interface and swap in a mock or stub inside the container during tests. Keep tests off the network so rate limiting and retry behaviour never fires in CI. The package ships a root phpstan.neon.dist at level 8, which is a solid baseline to mirror in your own static analysis setup.
- Why use this bundle instead of the raw calliostro/php-discogs-api client?
- The bundle adds Symfony service wiring, YAML-based credential configuration, optional rate limiting through Symfony's Rate Limiter, and, from v4.1, built-in retry resilience for 429 and 503 responses. Using raw Guzzle or the bare client means writing all of that plumbing yourself and keeping it maintained. If you are on Laravel or another non-Symfony framework, the bare client is usually the better fit.