Exclude license header check for HighlightFunctionIT

[dai-chen]

Description

Excludes HighlightFunctionIT from license-header checks because RAT 0.18 misdetects its first 256 bytes (import FULLTEXT_RELEVANCE_FUNC) as unsupported IBM424_rtl charset. This began failing today because opensearch-project/OpenSearch#22770 upgraded Apache RAT from 0.15 to 0.18. Remove after the upstream RAT fix.

Related Issues

N/A

Check List

• New functionality includes testing.
• New functionality has been documented.
• New functionality has javadoc added.
• New functionality has a user manual doc added.
• New PPL command checklist all confirmed.
• API changes companion pull request created.
• Commits are signed per the DCO using --signoff or -s.
• Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🧪 PR contains tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ Recommended focus areas for review Possible Issue The PROBE_TIMEOUT of 10 seconds is generous, but if both probes (resolve and field_caps) are issued sequentially and each takes near the timeout, the total delay approaches 20 seconds. For a query that would otherwise respond quickly, this could appear as a hang. Consider whether a shorter timeout or a combined budget is more appropriate, or document that queries may experience this latency when pruning is enabled. private static final TimeValue PROBE_TIMEOUT = TimeValue.timeValueSeconds(10); Possible Issue The prunedIndexName is memoized and reused across multiple build() calls. If the same builder instance is used for different queries or if the filter changes between calls, the stale pruned name from the first call will be incorrectly applied to subsequent queries. This can cause queries to read the wrong set of indices. /** Memoized because build() runs once per scan on the calling thread. */ @EqualsAndHashCode.Exclude @ToString.Exclude private OpenSearchRequest.IndexName prunedIndexName;

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Add thread-safety to memoization The memoization of prunedIndexName is not thread-safe. If build() is called concurrently from multiple threads, race conditions could occur where pruning runs multiple times or returns inconsistent results. Consider using synchronization or making the field volatile with proper double-checked locking. opensearch/src/main/java/org/opensearch/sql/opensearch/request/OpenSearchRequestBuilder.java [172-184] if (prunedIndexName == null) { - prunedIndexName = - client - .getNodeClient() - .map( - nodeClient -> new IndexPruner(nodeClient).prune(indexName, sourceBuilder.query())) - .orElse(indexName); - log.info( - "Index expression has {} names after pruning", prunedIndexName.getIndexNames().length); - log.debug("Pruned index expression from {} to {}", indexName, prunedIndexName); + synchronized (this) { + if (prunedIndexName == null) { + prunedIndexName = + client + .getNodeClient() + .map( + nodeClient -> new IndexPruner(nodeClient).prune(indexName, sourceBuilder.query())) + .orElse(indexName); + log.info( + "Index expression has {} names after pruning", prunedIndexName.getIndexNames().length); + log.debug("Pruned index expression from {} to {}", indexName, prunedIndexName); + } + } } return prunedIndexName; Suggestion importance[1-10]: 7 __ Why: Valid concern about thread-safety in the memoization pattern. The comment states "Memoized because build() runs once per scan on the calling thread," but without explicit synchronization, concurrent access could lead to race conditions or multiple pruning operations.	Medium
General	Reduce probe timeout duration The 10-second timeout for pruning probes is very generous and could significantly delay query execution if probes fail or are slow. Consider reducing this timeout to 1-2 seconds to prevent excessive query latency, especially since the fallback behavior is to query the full expression. opensearch/src/main/java/org/opensearch/sql/opensearch/request/IndexPruner.java [36] -private static final TimeValue PROBE_TIMEOUT = TimeValue.timeValueSeconds(10); +private static final TimeValue PROBE_TIMEOUT = TimeValue.timeValueSeconds(2); Suggestion importance[1-10]: 4 __ Why: While reducing the timeout from 10s to 2s could improve responsiveness, the PR documentation explicitly states the timeout is "generous because a fallback can fail the query, not merely slow it." The current value appears to be a deliberate design choice to avoid false failures.	Low