Skip to content

apache/master->master: b5d840447214309ca0882242e8ae9aa1945faa64#1306

Open
kgyrtkirk wants to merge 46 commits into
masterfrom
sync/apache-b5d840447214309ca0882242e8ae9aa1945faa64
Open

apache/master->master: b5d840447214309ca0882242e8ae9aa1945faa64#1306
kgyrtkirk wants to merge 46 commits into
masterfrom
sync/apache-b5d840447214309ca0882242e8ae9aa1945faa64

Conversation

@kgyrtkirk

Copy link
Copy Markdown
Owner

No description provided.

capistrant and others added 30 commits May 22, 2026 10:13
* fix unit tests, bump actions-timeline

CI is failing to startup to run unit tests, complaining about actions-timeline version not being allowed, switched to latest per https://github.com/apache/infrastructure-actions/blob/main/actions.yml

* fix S3InputSourceTest
changes:
* add `PartialSegmentMetadataCacheEntry` a `CacheEntry` that range-reads the V10 header on mount, constructs `PartialSegmentFileMapperV10`, and shrinks its reservation to actual on-disk size
* add `PartialSegmentBundleCacheEntry` and `PartialSegmentBundleCacheEntryIdentifier` are `CacheEntry` associated with each file bundle of a v10 segment that sparse-allocates and evicts its containers as a unit; places holds metadata and transitive parent bundle entries holds via the `StorageLocation` methods (weak reference holds on the parent cache entries) and reference-counted usage references
* add `PartialSegmentCacheBootstrap` a helper that restores partial-format entries from on-disk layout on historical startup (not wired up yet); cleans orphaned bundles
* add `ResizableCacheEntry` interface and `StorageLocation.adjustReservation` (shrink-only) so the metadata entry can tighten its reservation post-mount
* rename `SegmentFileBuilder.startFileGroup` → `startFileBundle`; introduce `ROOT_BUNDLE_NAME` as the default bundle for containers written without an explicit declaration                                                              * rename json field `SegmentFileContainerMetadata.fileGroup` → `bundle`; now non-null via getter, normalizes to `ROOT_BUNDLE_NAME` in the constructor, default value omitted from JSON using a custom `JsonInclude` filter
* Extract shared `DirectoryBackedRangeReader` and `CountingRangeReader` test helpers; consolidate duplicates across processing + server tests
…#19491) (apache#19497)

OrcInputFormat.initialize() — which swaps Thread.currentThread().setContextClassLoader() and calls FileSystem.get(conf) — was invoked on every createReader() call. When a ParallelIndexTask runs multiple ORC subtasks concurrently in the same JVM (as in embedded tests)
* Add default value for thread enabling

* Peon disable thread renaming

* Add benchmark query types

* Add groupby benchmark

* Specify query type

* Docs for thread
* Bump jackson to 2.21.3

Jackson 2.21 (issue apache#1381) changed the default resolution of
@JacksonInject when combined with @JsonProperty on the same parameter:
the injected value now wins over the JSON value, where 2.20 treated
the inject as a fallback used only when JSON did not supply one.

DruidNode's serviceName, port, and tlsPort parameters carry both
annotations, with JSON expected to win when supplied — this is how
DruidNode JSON config files have always worked. Add the explicit
useInput = OptBoolean.TRUE to restore that contract.

A repo-wide audit confirmed DruidNode's three parameters are the only
sites in Druid where @JacksonInject and @JsonProperty annotate the
same parameter; everywhere else the annotations are on distinct
parameters and are unaffected.

Also adds the previously-missing license entry for org.jspecify:jspecify
1.0.0 in extensions-core/kubernetes-extensions, which the
check-licenses dependency report flagged.

* Preserve @JacksonInject metadata in GuiceAnnotationIntrospector

findInjectableValue was returning JacksonInject.Value.forId(id), which
strips useInput and optional from the original annotation. Production
deserialization happens to remain correct under jackson 2.21 because
AnnotationIntrospectorPair.findInjectableValue falls back to the
secondary (default Jackson) introspector and merges the recovered
useInput onto the primary's Value via withUseInput.

That fallback is undocumented as part of the introspector contract and
would silently regress if the pair semantics change, or if this
introspector were ever installed standalone for a special-purpose
mapper. Construct the Value via JacksonInject.Value.from(annotation)
.withId(id) so the introspector returns a complete Value on its own
and no longer relies on the pair to fix it up.

The annotation lookup is hoisted to the top of findInjectableValue so
the non-null contract between it and findGuiceInjectId is explicit —
findGuiceInjectId now documents the precondition and trusts the caller
to verify, eliminating the duplicate getAnnotation call.

Defensive cleanup motivated by FasterXML/jackson-databind#1381; no
observable behavior change.
…#19477)

* resetOffsetsAndBackfill using bounded stream supervisor

* Reject non-positive backfillTaskCount

* Reset supervisor after backfill Supervisor has already been started

* Add helper method specHasConcurrentLocks

* Fix doc reference

* Move validations into helper function

* Add embedded-test for resetSupervisorAndBackfill

* Remove flaky waitUntilPublishedRecordsAreIngested

* Update KafkaBoundedSupervisorTest.java

* Wait for supervisor to be RUNNING

* Use checkpointed offset if > requested reset offset to prevent duplicate ingestion

* Update KafkaBoundedSupervisorTest.java

* Revert "Use checkpointed offset if > requested reset offset to prevent duplicate ingestion"

resetOffsetsForwardOnly does not fully close the race it targets (the write is
still unconditional) and the duplicate scenario it addresses is narrower than
the overlap case, which cannot be solved without suspending the main supervisor.
Accepting the limitation and documenting it is preferable to the added complexity.

This reverts commit 89b5fec.

* Doc update - duplication notice and Kinesis callout

* Rename endpoint from resetOffsetsAndBackfill to resetToLatestAndBackfill

* Update test name to reflect new endpoint

* Address clean up from review comments

* Log out start/end offsets

* Add abstract createBackfillSpec

* Unit test createBackfillSpec

* Fix deprecation notices

* Rename functions to align with new endpoint name

* Add null check and rename for consistency
Caffeine 3 raised the Java baseline to 11, tightened the AsyncCache
surface, and replaced size-LRU eviction with W-TinyLFU with explicit
admission control. The Caffeine APIs Druid uses (Cache, Caffeine
builder, Weigher, CacheStats) are stable across the transition.

Errorprone 2.49.0 is required because caffeine 3.2.4 pulls
error_prone_annotations 2.49.0 transitively, which violates the
requireUpperBoundDeps enforcer rule without the bump.

CaffeineCacheTest.testSizeEviction is rewritten for W-TinyLFU: the old
test pre-read key1 multiple times before putting key2, biasing the
admission policy to keep key1 and reject val2, so the assertion that
key1 was evicted no longer holds. The rewrite avoids the pre-reads
and asserts only that eviction happened and the cache stayed under
bound, mirroring caffeine's own EvictionTest patterns.

Also adds the previously-missing license entry for org.jspecify:jspecify
1.0.0 in extensions-core/kubernetes-extensions, which the
check-licenses dependency report flags. This was missing pre-bump and
is unrelated to caffeine/errorprone, but the CI license check fails
without it, so it is included here to keep the PR green.
* Web console support for resetToLatestAndBackfill

* Make pretty

* Update supervisor-reset-to-latest-dialog.tsx
…with disk utilization (apache#19422)

The existing linear penalization factor is still ineffective in large skew scenarios where the CostBalancerStrategy's cost forces a move/load (even with the utilization-based penalty). This switches the penalty to scale exponentially with the disk utilization, ensuring that near-full historicals are penalized. This is also particularly helpful when the size of segments on the cluster vary wildly.

This also marks the diskNormalized strategy as ready for production use.
…ocessors (apache#19536)

changes:
* `AWSClientConfig` now defaults `maxConnections` to scale with available processors `(max(50, 4 * cores))` to be in sync with virtual storage mode historical download thread pool size
* tests with artificial `RuntimeInfo` to cover the config scaling
Fixes a typo in the error message "python interpreter not found" when running bin/start-druid with no installed python interpreter. The error message previously read "python interepreter not found".
This patch updates KafkaConsumerMonitor to accept the task's
metric builder, which includes supervisorId as well as other dimensions
from IndexTaskUtils.setTaskDimensions.
This patch adds the setting "backgroundFetchExternalFiles". When set,
cloud storage files referenced by ExternalSegment (EXTERN) are fetched
asynchronously into the task's storage locations. The setting defaults
to true.

To support this, new infrastructure is added:

1) VirtualStorageManager, a layer on top of StorageLocation that
   provides a simple "fetch and cache a file" API.

2) StorageLoadingThreadPool, an extraction of the thread pool from
   SegmentLocalCacheManager so it can be shared with
   VirtualStorageManager.

3) AsyncResource, a Future-like utility that provides better tools for
   managing Closeable resources. It is used by VirtualStorageManager to
   provide the asynchronously-fetched file handles.
…#19553)

In some cases, cancellation is triggered by an exception (rather than a
non-exceptional reason, like timeout or user request). This patch
retains the exception and includes it in the query report.
…pache#19555)

Most metrics are tracked by the StorageLocation itself, but it needs
help from the higher level layer to track load completion.
…asks (apache#19540)

Streaming ingestion tasks were incorrectly reporting thrown-away reason as null for filtered rows.
S3 segment pushes that use the AWS SDK v2 transfer manager can resolve credentials on the async upload path. If a file-session credential refresh, container credential lookup, or IMDS lookup is temporarily unavailable, the SDK reports an SdkClientException such as 'Unable to load credentials from any of the providers in the chain'.

Druid's S3 push path already wraps uploads in retryS3Operation, but these credential-provider failures were not classified as recoverable after the SDK v2 migration. That made an intermittent credential miss fail the task immediately instead of using the existing retry budget.
… level in addition to context (apache#19559)

* Make segmentLoadAheadCount able to be configured at worker task level in addition to context

* fixups based on review
changes:                                                                                                                                                                                                                                 * adds new `S3SegmentRangeReader` that wraps `ServerSideEncryptingAmazonS3` + bucket + key prefix and issues closed-range `GetObjectRequests` against `keyPrefix + filename`. Returned stream is wrapped in a `RetryingInputStream` with the `S3Utils.S3RETRY` predicate (the same retry policy `S3DataSegmentPuller` uses for full-segment downloads) so a transient mid-stream error reopens at the byte offset where it failed and resumes with a fresh range request for the remaining bytes, rather than restarting the whole read.
* New `rangeable` boolean on `S3LoadSpec` stamped by the pusher at write time. `S3LoadSpec.openRangeReader()` returns a reader iff the flag is true and the key isn't .zip
* `S3DataSegmentPusher.pushNoZip` stamps rangeable=true when binaryVersion is `V10_VERSION`, false otherwise. `pushZip` omits the field
Fixes apache#19563.

Description
This PR hardens the Consul-backed embedded tests against startup races where the Consul container has started but the host-mapped Consul API is not yet reliably accepting requests.
…pache#19565)

* fix: empty loads for asymmetric cluster-group partial-load matchers

* fix test

* ensure that rule is compatible with clustering before doing empty loads

* broken javadoc link
amaechler and others added 14 commits June 15, 2026 10:22
test_runKafkaSupervisor produced 10 records, waited only for the broker to
discover the datasource (the first matching metric event), then immediately
asserted SELECT COUNT(*) == 10. Under a loaded CI runner the query raced
ingestion and saw fewer than 10 rows (expected:<10> but was:<8/7/9>).

Wait for ingest/events/processed to reach the expected count before querying,
matching the sibling test_runSupervisor_withEmptyDimension, and derive the
expected count from expectedSegments instead of a hardcoded literal.
…o reduce flakiness (apache#19580)

KafkaIndexFaultToleranceTest inherited the 60s LatchableEmitter default from
StreamIndexTestBase and intermittently timed out ("Timed out waiting for event
after [60,000]ms") when the shared CI runner was under load. KinesisFaultToleranceTest
already worked around this with a 120s override; move that override into the shared
StreamIndexFaultToleranceTest base so both stream fault-tolerance suites inherit it,
and drop the now-redundant per-subclass overrides.
* Raise start-druid middleManager memory floor to 256m

The auto memory split in start-druid gives the middleManager the lowest
weight, so on a moderately sized machine it can be awarded a very small
heap: at `-m 16g` it gets only ~68m. The middleManager does not just fork
peons, it also runs an embedded HTTP server that proxies task reports and
logs back to callers (for example the web console polling a running query).
Under that proxying load a ~68m heap is exhausted, the middleManager exits
with an OutOfMemoryError, and the task it owns is reported as having
"disappeared on the worker".

Raise the middleManager minimum from 64m to 256m. 256m matches the heap
already shipped for the medium/large/xlarge single-server example configs.
The floor only affects deployments small enough that the proportional split
would fall below it (roughly under 60g total); larger deployments are
unchanged.

* Drop the explanatory comment on the middleManager floor
Added extensions-contrib/openlineage-emitter as a contrib extension that uses the RequestLogger to transform and send lineage information to any OpenLineage-compatible API.

For SQL queries, the SQL text is parsed with the Calcite parser to extract input datasources (FROM clauses, JOINs, CTEs) and output datasources (INSERT INTO). For native queries, table names are read from DataSource.getTableNames(). Native sub-queries spawned by a SQL execution are deduplicated against the SQL-level event.

Each event includes standard OpenLineage facets (processing_engine, jobType, sql,errorMessage) and custom Druid facets (druid_query_context with user identity and query metadata, druid_query_statistics with duration and bytes).
A few actions in the workflows lag the rest of the tree:

- actions/stale v9 -> v10
- amannn/action-semantic-pull-request v5 -> v6
- actions/upload-artifact v4 -> v7 in docker-tests.yml (the other two
  upload steps in the same job already use v7)
* feat: clustered segments pt.2 (write side support)

changes:
* adds `BaseTableProjectionSpec` interface to capture the operator facing shape of V10 base table schemas
* adds `ClusteredValueGroupsBaseTableSchema` implementation for ingesting clustered segments
* adds `DataSchema.baseTable`, a `BaseTableProjectionSpec` which when set puts the DataSchema into a new mode where the majority of the schema is defined via the baseTable, rejecting other top level fields
* adds `DataSchema.segmentGranularity` to use when `baseTable` is set, which captures the segment granularity and intervals (query granularity is defined by the baseTable)
* adds `AdaptedBaseTableProjectionSpec` implementation for converting classic `DataSchema` fields to a `BaseTableProjectionSpec`
* adds `OnHeapClusteredBaseTable`, `OnHeapClusterGroup` used by `OnHeapIncrementalIndex` to build clustered segments
* adds `IndexMergerV10.makeClusteredIndexFiles` which merges and builds clustered v10 segments
* `Sink`/`BatchAppenderator`/`StreamAppenderator` wiring for clustered segments so that the cluster group tuples appear on the `DataSegment`
* known issues: unbounded, no aggregate projections, no compaction support, no time ordered cursor support
…pache#19535)

changes:
* adds `acquirePartialSegment` / `acquireCachedPartialSegment` to `SegmentCacheManager` and `SegmentManager` to allow callers to opt-in to async partial segments; MSQ `RegularLoadableSegment` uses the new partial path
* `PartialSegmentMetadataCacheEntry`, `PartialSegmentBundleCacheEntry` are now wired into `SegmentLocalCacheManager`, along with added `PartialBundleAcquirer` helper to pass things like download thread pool and the ability to acquire reference holds on cache entrie
* adds `PartialQueryableIndexSegment`, `PartialQueryableIndexCursorFactory`, `V10TimeBoundaryInspector` for references acquired from the now wired up metadata cache entry, implementing the async cursor holder contract
* moved `DirectoryBackedRangeReader` out of tests to use as the implementation for `LocalLoadSpec` range reader.
* add `FilteredCursorFactory`/`RestrictedCursorFactory` async cursor implementations
* adds config `druid.segmentCache.virtualStoragePartialDownloadsEnabled to enable feature, of by default
…or (apache#19592)

* fix(delta): drain all batches per scan file in DeltaInputSourceIterator

Fixes apache#18606 — only 1024 rows ingested per Parquet file when using the
Delta Lake input source.

Root cause: filteredBatchIterator was a local variable inside hasNext().
When the method returned true after the first non-empty batch of a file,
the iterator went out of scope. The next hasNext() call advanced to the
next file, skipping all remaining batches of the current file.

With Delta kernel's default batch size of 1024 rows, this caused exactly
1024 rows × N files to be ingested regardless of actual file size.

Fix: promote filteredBatchIterator to a field (currentFileIterator) so
it survives across hasNext() calls and all batches of a file are drained
before advancing to the next file.

Also fixed close() to properly close currentFileIterator and drain all
remaining file iterators.

* test(delta): add regression test for apacheGH-18606 batch drain fix

Adds a Delta table with 2 Parquet files × 2000 rows (total 4000) where
each file exceeds the Delta kernel's default batch size of 1024 rows.

Without the fix: DeltaInputSourceIterator returns 1024 × 2 = 2048 rows.
With the fix:    all 4000 rows are returned correctly.

Test: DeltaInputSourceBatchDrainTest.testAllRowsReturnedWhenFilesExceedOneBatch

* test(delta): add BatchDrainRegressionTests to DeltaInputSourceTest for apacheGH-18606

Adds LargeRowGroupDeltaTable (2 files × 2000 rows = 4000 total) and a
BatchDrainRegressionTests inner class inside DeltaInputSourceTest following
the same pattern as existing test classes.

The regression test fails with the bug (returns 1024 × 2 = 2048 rows)
and passes with the fix (returns all 4000 rows).

* style: add missing newline at end of LargeRowGroupDeltaTable.java

* fix(delta): close drained file iterator before advancing

Each per-file iterator from Scan.transformPhysicalData() owns an
underlying Parquet reader/file handle. hasNext() overwrote
currentFileIterator with the next file without closing the exhausted
one, leaking a handle per completed file on multi-file tables (close()
only closed the last and the never-started iterators). Now close the
drained iterator before advancing.

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

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The description for `druid.broker.balancer.type` was truncated mid-sentence
("...the fewest number of active connections to"). Complete the sentence and
fix the "random choose" -> "random chooses" grammar.

Co-authored-by: Cursor <cursoragent@cursor.com>
changes:
* `CompactionTask` now can specify `baseTable` spec to create clustered segments
* `DataSourceMSQDestination` can now specify a `baseTable` so MSQ can generate clustered segments (or any other future baseTable spec)
* adds `baseTable` to 'inline' and reindexing template compaction configs to feed to compaction task for auto-compaction
* adds `baseTable`, `segmentGranularitySpec` to `CompactionState`, `CompactionStatus` is `baseTable` aware for checks
* guards to prevent `baseTable` from working with 'native' compaction and direct towards MSQ compaction
Changes:
- Add `LatchableEmitter.waitForEventAggregate` which waits for a specific timeout
- Add `StreamIndexTestBase.waitUntilPublishedRecordsAreIngested` which waits for a specific timeout
…e#19596)

This change adds maxValuesPerDimension, an optional safety cap on distinct values recorded per dimension per segment in the dim_value_set shard spec.
@kgyrtkirk kgyrtkirk enabled auto-merge June 19, 2026 09:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.