fix(core): Clear updateRunning when a refresh cannot be queued

updateRunning is cleared in exactly one place, the submitted callable's finally
block, so it is cleared if and only if the callable runs. Every failure from
Future.get() leaves the callable running, so it still clears the flag itself.
A failure from submit() does not: the callable was never queued, nothing clears
the flag, and the compareAndSet guard in getHostname() then fails forever, so
no refresh is ever attempted again.

Removing MainEventProcessor's close() took away the only reachable way to make
submit() throw, but the invariant was still wrong: a bounded queue, a shutdown
added later, or a failure to start a thread would silently resurrect the same
permanent freeze.

Splitting submit() out of the try means the two cases can be told apart.
Clearing the flag on a timeout or an interrupt as well would be wrong, since
the callable is still running there and refreshes would pile up behind a slow
lookup; MainEventProcessorTest's `sets servername to null if retrieving takes
longer time` covers that path.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: runningcode

sentry/src/main/java/io/sentry/HostnameCache.java

@@ -8,6 +8,7 @@
 import java.util.concurrent.ExecutorService;
 import java.util.concurrent.Future;
 import java.util.concurrent.LinkedBlockingQueue;
+import java.util.concurrent.RejectedExecutionException;
 import java.util.concurrent.ThreadFactory;
 import java.util.concurrent.ThreadPoolExecutor;
 import java.util.concurrent.TimeUnit;
@@ -136,8 +137,21 @@ private void updateCache() {
           return null;
         };
 
+    final Future<Void> futureTask;
+    try {
+      futureTask = executorService.submit(hostRetriever);
+    } catch (RejectedExecutionException e) {
+      // updateRunning is cleared by the callable's finally block, which never runs if the callable
+      // was never queued. Clearing it here keeps a failure to queue from latching the flag on and
+      // silencing every later refresh.
+      updateRunning.set(false);
+      handleCacheUpdateFailure();
+      return;
+    }
+
+    // A timeout or interrupt below leaves the callable running, so it still clears updateRunning
+    // itself; doing it here as well would let refreshes pile up behind a slow lookup.
     try {
-      final Future<Void> futureTask = executorService.submit(hostRetriever);
       futureTask.get(GET_HOSTNAME_TIMEOUT, TimeUnit.MILLISECONDS);
     } catch (InterruptedException e) {
       Thread.currentThread().interrupt();

sentry/src/test/java/io/sentry/HostnameCacheTest.kt

@@ -2,9 +2,11 @@ package io.sentry
 
 import com.google.common.truth.Truth.assertThat
 import io.sentry.test.getProperty
+import io.sentry.test.injectForField
 import java.net.InetAddress
 import java.util.concurrent.ThreadPoolExecutor
 import java.util.concurrent.TimeUnit
+import java.util.concurrent.atomic.AtomicBoolean
 import kotlin.test.Test
 import org.mockito.kotlin.mock
 import org.mockito.kotlin.whenever
@@ -23,6 +25,21 @@ class HostnameCacheTest {
     assertThat(cache.hostname).isEqualTo("myhost")
   }
 
+  @Test
+  fun `a refresh that cannot be queued does not stop later refreshes`() {
+    val cache = getSut()
+    // Reject the next submit the way an executor that could not start a thread would, and mark the
+    // cache stale so that reading the hostname attempts a refresh.
+    cache.getProperty<ThreadPoolExecutor>("executorService").shutdown()
+    cache.injectForField("expirationTimestamp", 0L)
+
+    assertThat(cache.hostname).isEqualTo("myhost")
+
+    // The callable never ran, so nothing else clears this flag; left set, it would fail the
+    // compareAndSet guard in getHostname() and no refresh would ever be attempted again.
+    assertThat(cache.getProperty<AtomicBoolean>("updateRunning").get()).isFalse()
+  }
+
   @Test
   fun `worker thread times out while idle instead of staying alive`() {
     val cache = getSut()