Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -319,6 +319,7 @@ static final class EventDispatcher {
private final AtomicInteger busyFlushWorkersCount;
private final AtomicLong lastKnownPastTime = new AtomicLong(0);
private final AtomicBoolean disabled = new AtomicBoolean(false);
private final DeliveryCooldownTracker cooldown;
private final AtomicBoolean didSendInitEvent = new AtomicBoolean(false);
final DiagnosticStore diagnosticStore; // visible for testing
private final EventContextDeduplicator contextDeduplicator;
Expand Down Expand Up @@ -346,6 +347,7 @@ private EventDispatcher(
this.diagnosticStore = eventsConfig.diagnosticStore;
this.busyFlushWorkersCount = new AtomicInteger(0);
this.logger = logger;
this.cooldown = new DeliveryCooldownTracker(eventsConfig.cooldownNanoTimeFn);

ThreadFactory threadFactory = new ThreadFactory() {
@Override
Expand Down Expand Up @@ -603,10 +605,21 @@ private boolean shouldDebugEvent(Event.FeatureRequest fe) {
}

private void triggerFlush(EventBuffer outbox, BlockingQueue<FlushPayload> payloadQueue) {
if (disabled.get() || outbox.isEmpty()) {
if (disabled.get()) {
return;
}
// The cooldown check and the token issue are one atomic step, so a window opening
// concurrently on a worker thread either diverts this flush to the discard path or makes
// the dispatched payload's token stale.
DeliveryCooldownTracker.WindowToken token = cooldown.beginDeliveryUnlessInCooldown();
if (token == null) {
discardPayloadInCooldown(outbox);
return;
}
if (outbox.isEmpty()) {
return;
}
FlushPayload payload = outbox.getPayload();
FlushPayload payload = outbox.getPayload(token);
if (diagnosticStore != null) {
int summaryCount = 0;
for (EventSummary summary : payload.summaries) {
Expand All @@ -632,12 +645,80 @@ private void triggerFlush(EventBuffer outbox, BlockingQueue<FlushPayload> payloa
}
}

private void handleResponse(EventSender.Result result) {
// While a window is open, a flush of any kind is a no-op that behaves exactly as if the batch
// had been sent and the service had refused it: the buffered events are disposed of, and any
// context introductions they carried are forgotten so a later payload can introduce those
// contexts again. Only the network attempt and the serialization work are skipped.
private void discardPayloadInCooldown(EventBuffer outbox) {
if (outbox.isEmpty()) {
return;
}
// No batch reached the service, so the diagnostic batch-size stat must not report one.
if (diagnosticStore != null) {
diagnosticStore.recordEventsInBatch(0);
}
FlushPayload payload = outbox.getPayload(null);
outbox.clear();
int eventCount = payload.events.length;
for (EventSummary summary : payload.summaries) {
if (!summary.isEmpty()) {
eventCount++;
}
}
boolean hadContextIntroductions = false;
for (Event e : payload.events) {
if (e instanceof Event.Index || e instanceof Event.Identify) {
hadContextIntroductions = true;
break;
}
}
if (hadContextIntroductions && contextDeduplicator != null) {
contextDeduplicator.flush();
}
long remainingSeconds = Math.max(1, (cooldown.remainingMillis() + 999) / 1000);
if (cooldown.takeDiscardWarning()) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI review: takeDiscardWarning() is atomic on its own, but not together with the cooldown check in triggerFlush, which takes the lock separately. A new window can open between them: the old window elapses, a diagnostic dispatched after that gets a 401, and the new window re-arms the Warn. This discard, gated by the old window, then takes the new window's Warn, and the new window's own discards log at Debug. In the Go PR, the check, the re-arm, and the check-and-set all run on the dispatcher goroutine, so this can't happen there. The impact is small, but returning the first-discard flag from the same tracker call as the cooldown check would close the gap.

logger.warn("Discarded {} events: event delivery is cooling down for another {} seconds",
eventCount, remainingSeconds);
} else {
logger.debug("Discarded {} events: event delivery is cooling down for another {} seconds",
eventCount, remainingSeconds);
}
}

private void handleResponse(EventSender.Result result, DeliveryCooldownTracker.WindowToken token) {
if (result.getTimeFromServer() != null) {
lastKnownPastTime.set(result.getTimeFromServer().getTime());
}
if (result.isMustShutDown()) {
disabled.set(true);
if (result.isUnexpectedFailure()) {
noteUnexpectedFailure(token);
} else if (result.isSuccess()) {
if (cooldown.recordSuccess(token)) {
logger.info("Event delivery resumed after cooldown");
}
} else {
cooldown.recordFailure(token);
}
}

// Diagnostic deliveries are not gated by the cooldown, and their outcomes drive it only the
// way they drove the old permanent disable: an unexpected failure opens a window, while a
// diagnostic success or ordinary failure has no effect on delivery state. In particular, a
// diagnostic success is not the probe and cannot count toward the reset threshold; only
// analytics deliveries prove the service is accepting analytics payloads again.
private void handleDiagnosticResponse(EventSender.Result result, DeliveryCooldownTracker.WindowToken token) {
if (result.getTimeFromServer() != null) {
lastKnownPastTime.set(result.getTimeFromServer().getTime());
}
if (result.isUnexpectedFailure()) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI review: A diagnostic failure can open a window, but a diagnostic success can never end one. Suppose a proxy or allowlist accepts /bulk but returns 403 or 404 for /diagnostic. Then every periodic diagnostic opens a new 5-minute window, and analytics that the service would accept are discarded in it. That's about a third of analytics at the default 15-minute diagnostic interval, and most of them at the 60-second minimum. The Go PR (launchdarkly/go-sdk-events#68) ignores diagnostic results, so it doesn't have this. Should a diagnostic failure open a window only while the analytics success streak is 0, or not at all?

noteUnexpectedFailure(token);
}
}

private void noteUnexpectedFailure(DeliveryCooldownTracker.WindowToken token) {
long windowMillis = cooldown.recordUnexpectedFailure(token);
if (windowMillis > 0) {
logger.error("Event delivery failed with an unexpected error;"
+ " event delivery will not be attempted for the next {} seconds", windowMillis / 1000);
}
}

Expand All @@ -650,9 +731,13 @@ public void run() {
Writer writer = new BufferedWriter(new OutputStreamWriter(buffer, Charset.forName("UTF-8")), INITIAL_OUTPUT_BUFFER_SIZE);
gson.toJson(diagnosticEvent.value, writer);
writer.flush();
// The send itself is not gated by the cooldown, but a diagnostic dispatched inside a
// window gets a null token, so its outcome cannot move delivery state even if it
// lands after the window has elapsed.
DeliveryCooldownTracker.WindowToken token = cooldown.beginDeliveryUnlessInCooldown();
EventSender.Result result = eventsConfig.eventSender.sendDiagnosticEvent(
buffer.toByteArray(), eventsConfig.eventsUri);
handleResponse(result);
handleDiagnosticResponse(result, token);
if (diagnosticEvent.initEvent) {
didSendInitEvent.set(true);
}
Expand Down Expand Up @@ -716,10 +801,10 @@ long getAndClearDroppedCount() {
return res;
}

FlushPayload getPayload() {
FlushPayload getPayload(DeliveryCooldownTracker.WindowToken token) {
Event[] eventsOut = events.toArray(new Event[events.size()]);
List<EventSummarizer.EventSummary> summaries = summarizer.getSummariesAndReset();
return new FlushPayload(eventsOut, summaries);
return new FlushPayload(eventsOut, summaries, token);
}

void clear() {
Expand All @@ -731,15 +816,17 @@ void clear() {
private static final class FlushPayload {
final Event[] events;
final List<EventSummary> summaries;
final DeliveryCooldownTracker.WindowToken token;

FlushPayload(Event[] events, List<EventSummary> summaries) {
FlushPayload(Event[] events, List<EventSummary> summaries, DeliveryCooldownTracker.WindowToken token) {
this.events = events;
this.summaries = summaries;
this.token = token;
}
}

private static interface EventResponseListener {
void handleResponse(EventSender.Result result);
void handleResponse(EventSender.Result result, DeliveryCooldownTracker.WindowToken token);
}

private static final class SendEventsTask implements Runnable {
Expand Down Expand Up @@ -780,20 +867,33 @@ public void run() {
} catch (InterruptedException e) {
continue;
}
EventSender.Result result;
try {
ByteArrayOutputStream buffer = new ByteArrayOutputStream(INITIAL_OUTPUT_BUFFER_SIZE);
Writer writer = new BufferedWriter(new OutputStreamWriter(buffer, Charset.forName("UTF-8")), INITIAL_OUTPUT_BUFFER_SIZE);
int outputEventCount = formatter.writeOutputEvents(payload.events, payload.summaries, writer);
writer.flush();
EventSender.Result result = eventsConfig.eventSender.sendAnalyticsEvents(
result = eventsConfig.eventSender.sendAnalyticsEvents(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI review: This sends without checking the cooldown. payloadQueue can hold a payload whose flush ran before the window opened, while every worker was busy. If a 401 opens the window before a worker takes that payload, the payload is still sent inside the window. Its outcome is stale, so cooldown state stays right, but the request goes out. EVTPROC 1.8.1 says no delivery attempt starts during a window. 1.8.5 is about flushes during the window, so it's unclear whether it covers a payload handed off before it. The Go PR does the same (launchdarkly/go-sdk-events#68). Is this intended?

buffer.toByteArray(),
outputEventCount,
eventsConfig.eventsUri
);
responseListener.handleResponse(result);
} catch (Exception e) {
logger.error("Unexpected error in event processor: {}", LogValues.exceptionSummary(e));
logger.debug(LogValues.exceptionTrace(e));
// The batch was not delivered, and the delivery schedule must know that: an exception
// here counts as an ordinary failure, which breaks the consecutive-success streak
// without opening a cooldown window.
result = EventSender.Result.failure();
}
try {
responseListener.handleResponse(result, payload.token);
} catch (Exception e) {
// An exception here (such as a null result from a custom EventSender) must not kill
// this worker thread: the busy-worker count would stay elevated forever and close()
// would never return.
logger.error("Unexpected error in event processor: {}", LogValues.exceptionSummary(e));
logger.debug(LogValues.exceptionTrace(e));

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Null sender result skips failure recording

Low Severity

A custom EventSender that returns null still only trips the outer catch around handleResponse. That catch keeps the worker alive but never calls recordFailure, so the consecutive-success streak is left intact. The PR contract treats a null result as an ordinary failure that should break the reset threshold the same way a thrown sender does.

Additional Locations (1)
Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit 8358410. Configure here.

}
synchronized (activeFlushWorkersCount) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI review: Both catches above take only Exception. If the sender or formatter throws an Error (such as AssertionError, NoClassDefFoundError, or StackOverflowError), the thread dies before it reaches this decrement. The count stays raised, and close() blocks forever in waitUntilAllFlushWorkersInactive. Main has the same problem, but the description says close() always returns. Moving the decrement into a finally would make that true.

activeFlushWorkersCount.decrementAndGet();
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,7 @@

import com.launchdarkly.logging.LDLogger;
import com.launchdarkly.logging.LogValues;
import com.launchdarkly.sdk.internal.http.FailureClass;
import com.launchdarkly.sdk.internal.http.HttpHelpers;
import com.launchdarkly.sdk.internal.http.HttpProperties;

Expand All @@ -16,7 +17,7 @@
import java.util.UUID;
import java.util.zip.GZIPOutputStream;

import static com.launchdarkly.sdk.internal.http.HttpErrors.checkIfErrorIsRecoverableAndLog;
import static com.launchdarkly.sdk.internal.http.HttpErrors.classifyHttpFailure;
import static com.launchdarkly.sdk.internal.http.HttpErrors.httpErrorDescription;

import okhttp3.Headers;
Expand Down Expand Up @@ -152,7 +153,7 @@ private CompressionResult<byte[]> compressData(byte[] data) {
private Result sendEventData(boolean isDiagnostic, byte[] data, int eventCount, URI eventsBaseUri) {
if (data == null || data.length == 0) {
// DefaultEventProcessor won't normally pass us an empty payload, but if it does, don't bother sending
return new Result(true, false, null);
return Result.success(null);
}

Headers.Builder headersBuilder = baseHeaders.newBuilder();
Expand All @@ -173,7 +174,7 @@ private Result sendEventData(boolean isDiagnostic, byte[] data, int eventCount,
URI uri = HttpHelpers.concatenateUriPath(eventsBaseUri, path);
CompressionResult<byte[]> compressionResult = compressData(data);
RequestBody body = RequestBody.create(compressionResult.data, JSON_CONTENT_TYPE);
boolean mustShutDown = false;
boolean unexpected = false;

if (compressionResult.wasCompressed) {
headersBuilder.add("Content-Encoding", "gzip");
Expand Down Expand Up @@ -207,27 +208,24 @@ private Result sendEventData(boolean isDiagnostic, byte[] data, int eventCount,
logger.debug("{} delivery took {} ms, response status {}", description, endTime - startTime, response.code());

if (response.isSuccessful()) {
return new Result(true, false, parseResponseDate(response));
return Result.success(parseResponseDate(response));
}

String errorDesc = httpErrorDescription(response.code());
boolean recoverable = checkIfErrorIsRecoverableAndLog(
logger,
errorDesc,
errorContext,
response.code(),
nextActionMessage
);
if (!recoverable) {
mustShutDown = true;
if (classifyHttpFailure(response.code()) == FailureClass.UNEXPECTED) {
logger.error("Error {} (the payload will not be retried): {}", errorContext, errorDesc);
unexpected = true;
break;
}
logger.warn("Error {} ({}): {}", errorContext, nextActionMessage, errorDesc);
} catch (IOException e) {
checkIfErrorIsRecoverableAndLog(logger, e.toString(), errorContext, 0, nextActionMessage);
// Transport-level failures are always worth one retry here, whatever their cause; the
// request may simply have hit a transient network problem.
logger.warn("Error {} ({}): {}", errorContext, nextActionMessage, e.toString());

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Transport errors log unsanitized exceptions

Medium Severity

The new IOException warn path logs e.toString(), so OkHttp transport failures can write hostnames, URLs, or other private request details into customer logs. Nearby cooldown handling already uses LogValues.exceptionSummary for Throwables, and classifyAndLogTransportFailure sanitizes the same class of errors.

Fix in Cursor Fix in Web

Triggered by learned rule: Log exceptions with LogValues.exceptionSummary, not toString/getMessage

Reviewed by Cursor Bugbot for commit 8358410. Configure here.

}
}

return new Result(false, mustShutDown, null);
return unexpected ? Result.unexpectedFailure() : Result.failure();
}

private final Date parseResponseDate(Response response) {
Expand Down
Loading
Loading