Jitter DecisionLogPlugin upload interval between min/max delay

[arimu1]

Problem

DecisionLogPlugin.start() scheduled decision-log flushes via scheduleAtFixedRate(...) using only min_delay_seconds as both the initial delay and the fixed period. Every instance in a fleet therefore uploads on the same cadence, and max_delay_seconds (already present on Config.DecisionLogsConfig, with a default of 600s) was never propagated to the scheduling logic at all. OPA Go jitters the decision log reporting interval between min_delay_seconds and max_delay_seconds to spread load across instances and match operator expectations.

Approach

Mirrors BundleDownloader's existing chained random-delay pattern (scheduleNextPoll), which this SDK already uses for bundle and discovery polling:

• DecisionLogPlugin.initialize() now also calls .setMaxDelaySeconds(logsConfig.getMaxDelaySeconds()) when building the DecisionLogs instance (previously only min_delay_seconds was wired through).
• Added a maxDelaySeconds field + getter/setter to the inner DecisionLogs class, mirroring the existing minDelaySeconds field.
• Replaced scheduler.scheduleAtFixedRate(...) with a new private scheduleNextFlush(minDelay, maxDelay) that re-schedules itself after each flush with a uniformly random delay in [minDelay, maxDelay] (ThreadLocalRandom), swallowing Exception from flush() (which already logs internally, same as downloadBundle()) so the chain keeps running, and stopping cleanly on RejectedExecutionException after shutdown — same structure as BundleDownloader.scheduleNextPoll.
• If max_delay_seconds is unset, it now defaults to 2 * min_delay_seconds (previously it was silently ignored entirely) instead of an unrelated hardcoded constant.
• Switched the plugin's scheduler construction to BundleDownloader.newPollScheduler("opa-decision-log-scheduler"), matching BundlePlugin and DiscoveryPlugin, so it uses daemon threads that drop pending delayed tasks on shutdown (consistent with the rest of the plugin's stop() handling).

validate() already checked min_delay_seconds <= max_delay_seconds for both the top-level config and the nested reporting config, so no changes were needed there.

Tests

Added two tests to DecisionLogPluginTest, following the timing-based style already used in DiscoveryPluginTest for its chained-scheduling tests:

• start_periodicFlush_usesJitteredChainedSchedule — sets min == max == 1s for a deterministic interval, logs an event before each tick, and verifies at least two "Flushed %d decision log events" debug logs occur ~1s apart, proving the schedule re-chains itself rather than firing once.
• start_onlyMinDelayConfigured_defaultsMaxToTwiceMin — sets only min_delay_seconds = 1 with max_delay_seconds explicitly null, and verifies a flush occurs within 2.5s, proving the fallback is 2 * min (2s here) rather than an unrelated default that would never fire in the test window.

Ran locally with JDK 17 / Gradle:

./gradlew :opa-services:test --tests "io.github.open_policy_agent.opa.plugins.DecisionLogPluginTest"

All 23 tests in the class pass (21 pre-existing + 2 new). Also ran the full :opa-services:test suite plus :opa-services:checkstyleMain/:opa-services:checkstyleTest — build succeeds; checkstyle produces only pre-existing warn-level MethodName warnings project-wide (same underscore-style test names used throughout the existing test suite, not introduced by this change) and no errors.

Fixes #78
Fixes #78

[sspaink]

The min/max defaulting here can produce an effective min > max that validate() won't catch, because validate() only compares the two when both are explicitly set — and the 300 default is injected here, after validation runs.

A user sets only max_delay_seconds: 120. validate() sees min = null and skips its check. Then this code defaults minDelaySeconds to 300, giving effective bounds 300 / 120. The minDelay >= maxDelay guard in scheduleNextFlush then silently falls back to a fixed 300s delay, quietly ignoring the ceiling the operator configured.

OPA Go handles this by validating the post-default values and rejecting the config when defaulted min > max. Could we do the same here?

[arimu1]

@sspaink Good catch — validate() now applies the same defaults as start() (min defaults to 300, max defaults to 2 * min) before comparing, so a lone max_delay_seconds: 120 is rejected instead of silently scheduling a fixed 300s flush. Added unit tests for max-only (error) and min-only (ok).