feat: sparse vector index + hybrid fusion + group-by (#4065, #4066, #4067)

[lvca]

Summary

Closes the three feature requests opened from discussion #4044 (Qdrant migration):

• feat: LSM_SPARSE_VECTOR index for sparse embedding retrieval #4065 native LSM_SPARSE_VECTOR index
• feat: server-side hybrid retrieval fusion (vector.fuse with RRF/DBSF/LINEAR) #4066 server-side hybrid retrieval fusion (vector.fuse)
• feat: groupBy/groupSize options on vector.neighbors for diversified retrieval #4067 groupBy / groupSize on vector.neighbors and vector.sparseNeighbors

The original Qdrant query_points_groups call from #4044 is now a single SQL statement:

SELECT expand(`vector.fuse`(
    `vector.neighbors`('Doc[dense]', :denseVec, 50),
    `vector.sparseNeighbors`('Doc[tokens,weights]', :qIdx, :qVal, 50),
    { fusion: 'RRF', groupBy: 'source_file', groupSize: 1 }
))

What's in this PR

Sparse vector index (#4065)

• Schema.INDEX_TYPE.LSM_SPARSE_VECTOR enum, withSparseVectorType() Java builder, CREATE INDEX ... LSM_SPARSE_VECTOR METADATA { dimensions, modifier } SQL syntax.
• Posting-list inverted index on the LSM-Tree backbone with composite key (int dim_id, RID rid, float weight). Inherits ACID, WAL, replication, compaction.
• Document-at-a-time WAND scoring with per-dim max_weight upper bounds (lazy-populated, monotone). Tighter per-page bounds (BlockMax-WAND), weight quantization, and parallel per-segment scoring tracked in feat: WAND/BlockMax-WAND dynamic pruning for LSM_SPARSE_VECTOR (scale to 100M+) #4068.
• IDF modifier (Robertson-Sparck-Jones formula).
• vector.sparseNeighbors(indexSpec, indices, values, K, options) SQL function with filter, groupBy, groupSize options.
• Studio "Add Index" dialog updated with LSM_SPARSE_VECTOR option, parallel-array property pickers (indices / weights), dimensions, modifier.

Server-side hybrid fusion (#4066)

• vector.fuse(source1, source2, ..., sourceN [, options]) SQL function.
• Three strategies: RRF (default, with k and per-source weights), DBSF (Qdrant 1.11+ mean ± 3σ normalization), LINEAR (per-source min-max normalization).
• Composes with vector.neighbors, vector.sparseNeighbors, SEARCH_INDEX, and any plain SELECT ... ORDER BY ... LIMIT N.
• Auto-flips distance to similarity at extract time so dense and sparse sources fuse without manual rescaling.
• groupBy + groupSize applied post-fusion (mirroring Qdrant's query_points_groups).

Group-by on vector neighbors (#4067)

• groupBy + groupSize options on both vector.neighbors and vector.sparseNeighbors.
• groupSize defaults to 1; the third positional k becomes max distinct groups when groupBy is set.
• MVP uses post-traversal grouping with adaptive over-fetch (k * groupSize * 5); integration into the HNSW traversal proper is a follow-up.
• Composes with the existing filter option.

Tests

• 6 sparse-index tests covering persistence, deletion, IDF, and large-corpus correctness vs a brute-force vector.sparseDot baseline.
• Concurrency test (@Tag("slow")) with 4 writers and 4 readers in parallel.
• 100k benchmark (@Tag("benchmark")) comparing the index vs brute-force.
• 9 fusion tests covering RRF, weighted RRF, DBSF, LINEAR, three-way fusion, score-less sources, post-fusion groupBy.
• 5 groupBy tests across 100 docs / 10 source files at groupSize=1 and groupSize=2.
• End-to-end test (Discussion4044HybridSearchE2ETest) replicating astarso's exact use case in a single SQL statement (Russian sparse-disambiguation: «процентов» vs «баллов»).

Totals: 21 new tests, 224 vector-related tests passing, 1469 SQL parser/executor tests passing, no regressions.

Test plan

• mvn -pl engine test -Dtest='com.arcadedb.index.sparsevector.*Test,com.arcadedb.function.sql.vector.*Test' green
• mvn -pl engine test -Dtest='Discussion4044HybridSearchE2ETest' green
• mvn -pl engine test -Dtest='LSMSparseVectorIndexConcurrencyTest' -DexcludedGroups= green (slow tag)
• Studio "Add Index" dialog can create an LSM_SPARSE_VECTOR index end-to-end

Out of scope (follow-ups)

• BlockMax-WAND with per-page bounds, weight quantization, parallel per-segment scoring for the sparse index (feat: WAND/BlockMax-WAND dynamic pruning for LSM_SPARSE_VECTOR (scale to 100M+) #4068).
• Doc page with worked examples for vector.fuse (last open acceptance criterion on feat: server-side hybrid retrieval fusion (vector.fuse with RRF/DBSF/LINEAR) #4066).
• HNSW-traversal-integrated grouping (vs the MVP post-filter): feat: traversal-integrated groupBy for vector search (follow-up to #4067) #4071.
• Dotted nested-field syntax for groupBy (e.g. metadata.author): feat: dotted nested-field groupBy for vector search (follow-up to #4067) #4072.

[codacy-production]

Not up to standards ⛔

🔴 Issues 1 medium · 1 minor

Alerts:
⚠ 2 issues (≤ 0 issues of at least minor severity)

Results:
2 new issues

Category	Results
ErrorProne	1 medium
CodeStyle	1 minor

View in Codacy

🟢 Metrics 320 complexity

Metric	Results
Complexity	320

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[gemini-code-assist]

Code Review

This pull request introduces sparse vector indexing and hybrid retrieval fusion capabilities to ArcadeDB. It adds the LSM_SPARSE_VECTOR index type, which utilizes an LSM-Tree-backed posting list and the WAND algorithm for efficient top-K retrieval. New SQL functions vector.sparseNeighbors and vector.fuse (supporting RRF, DBSF, and LINEAR strategies) are implemented, along with groupBy and groupSize options for vector search results. Feedback focuses on several performance optimization opportunities, specifically addressing lock contention in the sparse index, reducing redundant database lookups in the fusion logic, and optimizing loop conditions and sorting within the search algorithms.

[gemini-code-assist]

Using a synchronized block on a plain HashMap for every posting insertion creates a significant contention point during data ingestion. Since put is called for every non-zero dimension of every document, this global lock will bottleneck the DocumentIndexer on multi-core systems. Consider using a ConcurrentHashMap and its merge method to allow for higher concurrency.

[gemini-code-assist]

The countPostings method performs a full range scan of the posting list for a given dimension to calculate the Document Frequency (DF). Calling this for every non-zero dimension in the query vector within the topK method introduces a significant performance bottleneck ($O(\sum df_i)$). While the PR description mentions this will be optimized in a follow-up, the current implementation makes the IDF modifier extremely expensive for large indexes.

[gemini-code-assist]

The initializeMaxWeightsLocked method performs a full scan of the entire index while holding a lock on dimMaxWeight. This will cause a massive latency spike on the first query after the index is opened and will block all writer threads (which also synchronize on dimMaxWeight during put) for the duration of the scan. Consider performing this initialization in the background or persisting the max weights.

[gemini-code-assist]

This loop performs redundant db.lookupByRID calls for results that were already loaded during the applyGroupBy phase (line 338). Additionally, manually iterating over property names and calling record.get(prop) is inefficient. Consider refactoring applyGroupBy to return the loaded Document objects and using record.toMap() to construct the result entry.

[gemini-code-assist]

The condition perGroup.values().stream().allMatch(c -> c >= groupSize) is evaluated in every iteration of the results loop once the number of groups reaches the limit. This is an $O(limit)$ operation inside the main loop. For the common case where groupSize is 1, this check is redundant as perGroup.size() >= limit is sufficient. For groupSize > 1, it is more efficient to maintain a counter of 'completed' groups.

[gemini-code-assist]

The condition perGroup.values().stream().allMatch(c -> c >= groupSize) is evaluated in every iteration of the results loop once the number of groups reaches the k limit. This is an $O(k)$ operation inside the main loop. For the common case where groupSize is 1, this check is redundant as perGroup.size() >= k is sufficient. For groupSize > 1, it is more efficient to maintain a counter of 'completed' groups.

[gemini-code-assist]

Sorting the cursors array in every iteration of the WAND loop is inefficient ($O(L \log L)$ where $L$ is the number of query terms). Since only the cursors that were advanced in the previous iteration need to be re-positioned, using a small PriorityQueue or a tournament tree to maintain the cursors sorted by their current RID would be more performant for high-dimensional queries.

[claude]

Code Review: feat - sparse vector index + hybrid fusion + group-by (#4065, #4066, #4067)

This is a substantial and well-executed set of features. Overall the implementation is clean and the design choices are sound. Below are observations grouped by concern.

---

Correctness / Bugs

dimMaxWeight synchronization is coarse-grained and creates a lock contention hot spot
LSMSparseVectorIndex serializes every put() call through synchronized (dimMaxWeight). Under the concurrent-write test (4 writers, 4 readers) this becomes a shared monitor on every indexed dimension. The HashMap is only mutated via merge(dim, w, Math::max), so a ConcurrentHashMap with merge is lock-free in practice and removes the bottleneck:

// instead of HashMap + synchronized blocks
private final ConcurrentHashMap<Integer, Float> dimMaxWeight = new ConcurrentHashMap<>();
// then in put():
dimMaxWeight.merge(dim, w, Math::max);     // no synchronized needed
// and in getMaxWeight:
if (!dimMaxWeightInitialized) { ... }      // still needs a lightweight guard - see next point

Lazy init of dimMaxWeight has a TOCTOU window
getMaxWeight checks !dimMaxWeightInitialized, then calls initializeMaxWeightsLocked() while holding the lock. But since the lock is on dimMaxWeight (the HashMap), and with a ConcurrentHashMap the monitor changes, this needs a proper double-checked guard or a volatile boolean + AtomicBoolean.compareAndSet. With the current code, if two WAND queries race on a fresh index, both can enter initializeMaxWeightsLocked() concurrently (one holds the lock, the other is blocked - so this is actually safe with the current synchronized approach). This is fine as-is, but worth a comment explaining why.

remove(Object[]) silently no-ops
The no-argument-RID remove overload logs nothing and returns without error. If DocumentIndexer calls this path (e.g., during a type drop), silent data loss occurs. At minimum, a log warning would help diagnose issues.

WAND seekTo creates a new cursor starting from (dim, target) but the range upper bound is (dim)

cursor = underlying.range(true, new Object[] { dim, target }, true, new Object[] { dim }, true);

The upper bound { dim } is a prefix and may not include the full upper end of the posting list for that dimension. Verify that the LSMTreeIndex.range implementation treats a shorter upper-bound key as "end of prefix" (i.e., dim + 1 exclusive). If it does strict key comparison, postings after the target in the same dimension may be silently dropped. This depends on the LSMTreeIndexAbstract key comparator behavior - worth a unit test that calls seekTo and then checks postings after the seek point are still returned.

applyGroupBy in SQLFunctionVectorFuse does a second round of lookupByRID calls on the same records that execute will look up again
The ranked list is traversed twice: once in applyGroupBy (to read the groupBy field) and once in execute (to serialize the record into the result map). For large result sets this doubles the I/O. Consider carrying the Document alongside the RidScore, or merging the two loops.

---

Performance

perGroup.values().stream().allMatch(c -> c >= groupSize) inside a tight loop
Both SQLFunctionVectorNeighbors and SQLFunctionVectorSparseNeighbors evaluate this predicate for the early-exit check on every iteration:

} else if (perGroup.size() >= limit
    && perGroup.values().stream().allMatch(c -> c >= groupSize)) {

This creates a stream allocation and a full traversal of the group map each time. Maintain a simple counter filledGroups that increments each time a group reaches groupSize, and compare filledGroups >= limit instead.

Arrays.sort(cursors, 0, liveCount, byCurrentRid) on every WAND iteration
Sorting the full live-cursor array by RID on each iteration is O(n log n) in the number of query dimensions. With large sparse queries (many non-zero dims) this dominates. Classic WAND uses an insertion-sort or partial-sort since most cursors do not move between iterations. Consider a simple insertion sort on the small array, or at least note this as a known limitation with a TODO for the #4068 follow-up.

countPostings(qDim) is O(df) per query dimension under IDF mode
The javadoc already calls this out as an MVP limitation, but for queries over high-frequency dimensions (e.g., common tokens in a large corpus) this can be very slow. The scan happens once per non-zero query dimension before the WAND loop. At minimum, cache the result per dimension within a single topK call since the df of a given dimension does not change mid-query.

---

Design / Style

isOriginalCall heuristic is fragile
The method distinguishes "raw DocumentIndexer call with parallel arrays" from "replay call with scalar postings" by inspecting the shape of keys[]. If a caller ever passes a List<Integer> for an index key that happens to be a single-element list, it could be misclassified. The replay path in TransactionIndexContext should ideally pass a typed marker or use a different code path rather than shape-sniffing. This is an architectural concern for a follow-up rather than a blocker.

Duplicate parseFilter / sparseToIntArray / sparseToFloatArray between SQLFunctionVectorSparseNeighbors and SQLFunctionVectorFuse
SQLFunctionVectorFuse.materializeSource duplicates the RID/score extraction logic that could live on a shared utility class. Similarly, parseFilter is copy-pasted between SQLFunctionVectorSparseNeighbors and the existing SQLFunctionVectorNeighbors. Consider moving the shared helpers to SQLFunctionVectorAbstract.

FunctionOptions is a project convention - good use here. The validation of known option keys is clean.

LSMSparseVectorIndexMetadata.dimensions is not validated at put-time
The dimensions field is stored in metadata but put does not check that dimension ids are within [0, dimensions). This means a misconfigured index silently accepts out-of-range dimensions, which could cause confusing results. Either validate in put (when dimensions > 0) or document that it is informational only.

Unused import java.util.Map in LSMSparseVectorIndex - minor, but keep the file clean.

---

Security

No resource exhaustion guard on the k * groupSize * 5 over-fetch multiplier
If a user passes groupSize=1000 and k=1000, the index is asked to return up to 5,000,000 candidates before the group filter runs. The fetchPerIndex value is unbounded. A reasonable cap (e.g., Math.min(fetchPerIndex, MAX_FETCH)) with a clear error message would prevent accidental memory exhaustion.

---

Test Coverage

The test suite is thorough. A few gaps worth noting:

• No test for seekTo correctness - a regression test that inserts postings for a dimension with a gap (e.g., RIDs 1, 2, 10, 11), calls seekTo(RID 5), and asserts that posting 10 is still returned would protect against the range-bound issue above.
• No test for remove followed by topK - the deletion path (remove(Object[], Identifiable)) has an iteration guard Math.min(indices.length, values.length) that silently truncates when arrays differ in length; a test for unequal-length deletion arrays would catch this.
• @Tag("benchmark") / @Tag("slow") are applied correctly - good.
• The concurrency test does not assert ordering correctness - it only asserts no exceptions. Consider adding a lightweight correctness check (e.g., results are non-empty and scores are non-negative) to catch data-race corruption.

---

Summary

This is solid, feature-complete work with good javadoc, correct algorithm implementations (WAND, RRF/DBSF/LINEAR), and broad test coverage. The main actionable items before merge are:

1. Replace HashMap + synchronized with ConcurrentHashMap for dimMaxWeight to reduce contention.
2. Replace the stream-based group-fill predicate with a counter to avoid per-iteration allocations.
3. Add a cap on the over-fetch multiplier to prevent memory exhaustion on large k * groupSize.
4. Verify (or add a test for) seekTo range correctness against the underlying LSM range API.

[claude]

test

[claude]

Code Review

Overview

This PR adds three tightly coupled features: a native LSM_SPARSE_VECTOR inverted index, server-side hybrid fusion via vector.fuse, and groupBy/groupSize options on vector neighbor functions. The motivation (Qdrant migration path from discussion #4044) is well-documented and the end-to-end test clearly validates the target use case.

Strengths

• WAND pruning is implemented correctly with monotone per-dim upper bounds and proper pivot-finding.
• The IDF formula (Robertson-Sparck-Jones BM25 variant) is correct.
• Test coverage is thorough: persistence, deletion, IDF, correctness vs brute-force, concurrency, benchmark, and an E2E test matching the original discussion scenario.
• @tag("benchmark") and @tag("slow") are applied correctly per project conventions.
• AssertJ assertThat syntax is used throughout - matches project style.
• Studio UI correctly uses escapeHtml for user-supplied values.

Issues

High - Potential resource leak in DimCursor

DimCursor wraps IndexCursor objects created via underlyingIndex.range(). Neither wandTopK nor seekTo closes the previous cursor before replacing it, and there is no close() on DimCursor itself. If IndexCursor holds file handles or off-heap memory, every query leaks resources proportional to the number of live query dimensions.

In DimCursor.seekTo the old cursor is silently overwritten (the old cursor is leaked). Recommendation: add a close() method to DimCursor (delegating to cursor.close() if IndexCursor is Closeable/AutoCloseable) and call it from wandTopK before returning, and in seekTo before reassigning cursor.

Medium - O(groups) stop-condition check per row in groupBy path

Both SQLFunctionVectorNeighbors and SQLFunctionVectorSparseNeighbors check inside the inner loop whether all groups are full via perGroup.values().stream().allMatch(c -> c >= groupSize). This is O(number of groups) and is called on every candidate row. For large limit values or highly skewed group distributions, this dominates. A simple integer counter of full groups (incremented when a group reaches groupSize) makes the check O(1).

Medium - Conditional super.fromJSON() in LSMSparseVectorIndexMetadata

During index config loading in LocalSchema.readConfiguration(), the JSON passed to setMetadata(JSONObject) does not contain typeName, so super.fromJSON() is never called on the load path. If IndexMetadata.fromJSON reads fields that are important for the parent state, those fields are silently skipped on every database reopen. Worth verifying this is intentional and does not leave the parent object in an incomplete state.

Low - Fully qualified class names in SQLFunctionVectorSparseNeighbors

Per CLAUDE.md: "do not use fully qualified names if possible, always import the class and just use the name". In executeWithIndexes, java.util.HashMap is spelled out fully even though HashMap is already imported and used without qualification elsewhere in the file. Remove the java.util. prefix.

Low - Duplicate inner record types (SourceRow / RidScore)

Both hold (RID rid, float score) and are structurally identical inside SQLFunctionVectorFuse. Only one is needed; the two-pass materialization (SourceRow list then RidScore list) in the execute path could also be collapsed into one.

Low - isOriginalCall heuristic fragility

The method distinguishes an "original DocumentIndexer call" from a "transaction replay scalar posting" purely by checking that keys is a length-2 pair of array-typed values. The length-3 replay case (Integer, RID, Float) is safe today, but if the internal key structure changes this heuristic silently misfires in both directions. An explicit marker flag or a dedicated putRaw entry point for the replay path would be more resilient.

Performance Note (already tracked)

The O(df) scan in countPostings() for IDF is called once per query dimension on every topK invocation with modifier = "IDF". At large corpus sizes or high-cardinality query vectors this is a meaningful bottleneck. Already tracked as #4068.

Minor

• Import order in DefaultSQLFunctionFactory.java: SQLFunctionVectorFuse is inserted after SQLFunctionVectorNeighbors but alphabetically belongs before it.
• The Studio JS correctly replaces em-dashes with hyphens in the existing option labels alongside the new entry.
• applyGroupBy in SQLFunctionVectorFuse does a database lookup for every ranked record, and then the final result-building loop does a second lookup for the same records. A single combined pass would halve the I/O.

Summary

The core algorithm (WAND, IDF, RRF/DBSF/LINEAR fusion, groupBy) is correctly implemented and well-tested. The main thing to address before merge is the cursor resource leak in DimCursor. The O(groups) stop-condition and the conditional super.fromJSON call are worth confirming. Everything else is minor polish.

[claude]

Code Review - PR #4070: Sparse vector index + hybrid fusion + group-by

This is a well-designed and substantial feature PR. The implementation is thoughtful, with good algorithm choices and solid test coverage. Below are my findings.

---

Overview

The PR adds three related features:

1. `LSM_SPARSE_VECTOR` - a posting-list inverted index with WAND-style dot-product retrieval
2. `vector.fuse` - server-side hybrid RRF/DBSF/LINEAR fusion of multiple ranked sources
3. `groupBy` / `groupSize` on `vector.neighbors` and `vector.sparseNeighbors`

The algorithm choices are sound and the code structure follows project conventions closely.

---

Bugs / Correctness Issues

1. Resource leaks: unclosed `IndexCursor` in `initializeMaxWeights()` and `countPostings()`

Both helpers iterate an `IndexCursor` without closing it, while the rest of the WAND code explicitly manages cursor lifecycle via `DimCursor.close()`:

```java
private void initializeMaxWeights() {
final IndexCursor cursor = underlyingIndex.iterator(true); // never closed
while (cursor.hasNext()) { ... }
}

private long countPostings(final int qDim) {
final IndexCursor cursor = underlyingIndex.range(...); // never closed
while (cursor.hasNext()) { ... }
return df;
}
```

Both methods should use try-with-resources or an explicit close in a finally block.

2. WAND correctness for negative document weights

`put()` only skips zero weights but does not reject negative ones:
```java
if (w == 0.0f) continue; // negative weights pass through
dimMaxWeight.merge(dim, w, Math::max); // max of negatives is not a valid upper bound
```

If a user stores negative sparse weights, `dimMaxWeight` becomes an incorrect upper bound and WAND would prune candidates it should not. The index should either validate that weights are positive at write time or document that negative weights are unsupported.

---

Performance

3. `countPostings()` is O(df) per query dimension under IDF

Each `topK()` call in IDF mode does a full scan of every query dimension's posting list to count `df`. For a corpus of 100k docs with average `df` of 1k and a 20-term query, that is 20 sequential O(1k) scans before the WAND loop begins. The PR acknowledges this ("Replaced by an incrementally maintained map in #4068") which is fine, but `dfCache` only helps when the same dim appears twice in one query - the per-query overhead is still O(sum of df over query dims).

4. `totalDocuments()` called once per `topK()` under IDF

This calls `countType(typeName, false)` per query. Depending on how expensive a type count is, this could add measurable latency to every IDF query. Could be cached or moved outside the hot path.

---

Code Quality

5. `TypeLSMSparseVectorIndexBuilder.withMetadata(JSONObject)` returns void, breaking the fluent chain

```java
public void withMetadata(final JSONObject json) { // should return TypeLSMSparseVectorIndexBuilder
...
}
```

The other `withMetadata(IndexMetadata)` overload correctly returns `TypeLSMSparseVectorIndexBuilder`. This one silently breaks the builder pattern and is inconsistent with `TypeLSMVectorIndexBuilder`.

6. Duplicate groupBy/groupSize post-filter logic

The groupBy filtering loop - including the `perGroup` map, `filledGroups` counter, and the two-condition exit gate - is copy-pasted identically into `SQLFunctionVectorNeighbors.executeWithLSMVectorIndexes`, `SQLFunctionVectorSparseNeighbors.executeWithIndexes`, and `SQLFunctionVectorFuse.execute`. A protected helper on `SQLFunctionVectorAbstract` would consolidate this. Not blocking, but a maintenance concern as the three copies must stay in sync.

7. `System.out.println` in benchmark test

`LSMSparseVectorIndexBenchmark.java` contains six `System.out.println` / `printf` calls. Per project conventions these should be replaced with `LogManager`. Benchmark output is arguably intentional, but if so the file should make this explicit.

---

Minor / Style

8. Studio: modifier value concatenated directly into SQL string

`modifier` comes from a `` with two fixed options so injection is not possible in practice. If the select options ever expand, this pattern would need escaping. 9. `LSMSparseVectorIndexMetadata` fields are mutable public Consistent with `LSMVectorIndexMetadata` but allows external mutation of index metadata after creation. Not a regression, just noting. Test Coverage The 21 new tests are well-targeted and cover: persistence/reload, IDF correctness, concurrency, benchmarks, all three fusion strategies, score-less sources with RRF, groupBy/groupSize on all three functions, nested field paths, missing paths, over-fetch cap rejection, and the full E2E Qdrant-migration scenario. One gap: there is no test for negative document weights. Given the WAND correctness issue (#2 above), a test verifying the behaviour (or a thrown validation exception) would close the loop. Summary Solid, well-documented implementation. Two items need attention before merge: Resource leak - close the `IndexCursor` in `initializeMaxWeights()` and `countPostings()` (straightforward try-with-resources fix). Fluent builder - `TypeLSMSparseVectorIndexBuilder.withMetadata(JSONObject)` should return `this`. The negative-weight WAND issue (#2) is worth a decision: either document the constraint or add a write-time validation check. Everything else is either a planned follow-up (#4068) or low-severity style.