Search endpoint (/ws/2/artist?query=...) returning connection failures while MBID lookup endpoint works fine

MusicBrainz Development
1

Title: Search endpoint (/ws/2/artist?query=…) returning connection failures while MBID lookup endpoint works fine

Summary

I am building a Python desktop application (macOS, Python 3.13.12, OpenSSL 3.6.1) that uses the MusicBrainz Web Service API to enrich an orchestral music catalog. Over the past 24 hours I have been experiencing intermittent but severe failures on the search endpoint while the direct MBID lookup endpoint works reliably.

Environment

  • macOS (Mac Studio)

  • Python 3.13.12

  • OpenSSL 3.6.1 (27 Jan 2026)

  • urllib.request.urlopen with ssl.create_default_context() (no custom SSL options)

  • HTTP/1.1 enforced via curl --http1.1

  • Polite pacing: minimum 1.1 seconds between requests, fully serialized (one request at a time)

  • Valid descriptive User-Agent header per MusicBrainz policy

What works

Direct MBID artist lookup with inc=url-rels returns HTTP 200 reliably and quickly for all tested orchestras:

text

BBC Symphony: 200 time=0.657s
Berlin Philharmonic: 200 time=0.581s
Boston Symphony: 200 time=0.545s
Chicago Symphony: 200 time=0.574s
Budapest Festival: 200 time=0.579s
Academy St Martin: 200 time=0.528s
Bavarian State: 200 time=0.563s

Example URL that works:

text

https://musicbrainz.org/ws/2/artist/5b13c665-88eb-4e80-9a06-218a660fcf6b?fmt=json&inc=url-rels

What fails

Artist search by name consistently returns HTTP 000 (connection never established) or TLS/SSL EOF errors:

text

Search Berlin Philharmonic: 000 time=0.348s
Search BBC Symphony: 000 time=0.342s
Search Boston Symphony: 000 time=0.370s

Example URLs that fail:

text

https://musicbrainz.org/ws/2/artist?query=artist%3A%22Berlin+Philharmonic%22&limit=5&fmt=json
https://musicbrainz.org/ws/2/artist?query=artist%3A%22BBC+Symphony+Orchestra%22&limit=5&fmt=json

These fail from both curl and Python urllib simultaneously, confirming this is not a client-side SSL library issue.

Error signatures observed

From Python urllib:

text

SSLEOFError(8, '[SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1032)')
SSLZeroReturnError(6, 'TLS/SSL connection has been closed (EOF) (_ssl.c:1032)')

From curl:

text

curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to musicbrainz.org:443

Key observation

These two endpoints behave completely differently at the same moment in time:

Endpoint Status
/ws/2/artist/{mbid}?fmt=json&inc=url-rels :white_check_mark: 200, reliable
/ws/2/artist?query=...&fmt=json :cross_mark: 000 / TLS EOF

This pattern — the search endpoint failing while the lookup endpoint succeeds — suggests the search backend (Lucene/Solr) may be experiencing separate infrastructure issues from the main database/lookup service.

History

  • Yesterday (June 21): search endpoint worked for approximately 32 successful orchestra enrichments in the morning, then began failing intermittently in the afternoon.

  • Today (June 22): search endpoint appears to be completely unreachable as of approximately 09:00 MDT, while MBID lookup continues to work.

Question

Is there a known issue with the search endpoint infrastructure? Is there a status page or notification channel for search-specific outages? Any guidance appreciated.

2

Our sysadmin @Zas might have a better clue here (though he is traveling at the moment). To my knowledge there are no known issues with the search endpoint at this time, and I can’t reproduce your issue using curl 8.7.1 (x86_64-apple-darwin25.0) libcurl/8.7.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.68.0. (Edit: I had also tried to reproduce this at the same time you had made your post, not just today.)

1 Like
3

Hi @jons,

I’ve investigated this on the infrastructure side. Our search backend (Solr cluster, 8 nodes) was operating normally during the period you reported — all nodes were healthy, no errors related to artist search queries, and the HAProxy/OpenResty frontend logs show all ws/2/artist?query= requests being served successfully with HTTP 200 throughout June 21-22.

The issue was almost certainly caused by our Hetzner Cloud Load Balancer, which sits in front of our web frontends. Hetzner was performing Load Balancer maintenance during that exact period:

  • June 18–22: Urgent maintenance on Load Balancers (rolling across locations)
  • June 22: “Partial Cloud Resource Creation Delay” incident affecting Load Balancers and Networks
  • June 22–23: Load Balancers API maintenance

The LB passes TCP connections through to our servers where TLS is terminated. If the LB drops or resets a connection during the TLS handshake, you’d see exactly the symptoms you described — SSL_ERROR_SYSCALL, UNEXPECTED_EOF_WHILE_READING, HTTP 000 — while the underlying servers remain perfectly healthy.

The reason MBID lookups worked while search failed could be due to HTTP connection reuse: successful requests on an already-established connection would continue working, while new connections (which search queries might have required) would fail at the LB level.

This has since resolved itself as Hetzner completed their maintenance. If you experience this again, https://status.hetzner.com is worth checking.

Regarding a status page for us specifically: we have a Grafana dashboard for the status of our SOLR cluster at Grafana but it requires to create an account.

2 Likes