Skip to main content
Released on April 15, 2026, this is a minor release that focuses on AI-driven search integration through MCP, enhanced Dynamic Index hierarchical support, and operational improvements through event-driven autoscaling and enhanced configuration management.
For supported Kubernetes versions and key component versions, see Platform support and component versions.

​
Key highlights

Lucidworks Search 5.17 introduces support for the Model Context Protocol (MCP), an open standard that enables AI assistants to search your Lucidworks Search data. With the new MCP server, you can connect Claude Code to your Lucidworks Search instance using a standardized protocol.
The MCP server integrates with Lucidworks Search’s existing security controls, query pipelines, and multi-tenant architecture, allowing different users and use cases to access different data subsets through query profiles.

B2B Commerce

Electronic component distributors and industrial suppliers can search technical specifications using queries like “Find ceramic capacitors rated for 50V with 10% tolerance” to locate precise parts across complex catalogs.

B2C Commerce

Retail customers can ask “Find wireless headphones under $200 with noise cancellation, sorted by rating” to discover products conversationally without navigating faceted search interfaces.

Knowledge Management

Employees search enterprise documentation with queries like “Find JWT authentication guides from the past six months” and receive filtered results with highlighted snippets while field-level security protects sensitive content.
For complete configuration options, multi-tenant setups, and troubleshooting, see Lucidworks MCP.

​
Dynamic Index hierarchical support

Lucidworks Search 5.17 enhances Dynamic Index with support to store raw ingestion data in a hierarchical, structured directory layout with versioned, parent-child-grandchild directories. You can now supply data with nested subfiles, each maintaining their own version numbers. For example, a parent file can contain multiple subfiles, and those subfiles can contain their own nested subfiles, with each level tracking independent versions. This improvement simplifies the management of complex document structures and removes the previous reliance on manifest files for replication. Updates and versioning at each level reduce reprocessing overhead and simplify the management of the product catalog and large volumes of data. The concise structure provides consistent, relevant search results and data insights.
Each subfile is its own basename directory with its own versions folder. A subfile can also contain its own subfiles folder.
PARENT_BASENAME
versions
VERSION_NUMBER
PARENT_BASENAME.txt
subfiles
CHILD_BASENAME
versions
VERSION_NUMBER
CHILD_BASENAME.txt
subfiles
GRANDCHILD_BASENAME
versions
VERSION_NUMBER
GRANDCHILD_BASENAME.txt
For more information, see Enable Dynamic Index.
Incremental update support has been removed from Dynamic Index for Lucidworks Search 5.17.0. Future releases are scheduled to contain the incremental update feature.

​
Connectors improvements

​
Skipping validation is now supported in V2 and Pro connectors

All V2 and Pro connectors now support a new core property that allows you to skip validation when needed. In previous versions of Lucidworks Search, long-running validation checks could cause connector configuration timeouts in the UI, preventing you from saving connector configurations even when the settings were correct. You can now configure connectors to skip validation by setting the appropriate property in the datasource configuration.

Configuration parameters

​
Skip Validation
boolean
default:"false"
Enable to skip configuration validation when it takes too long and causes a timeout issue.
This gives you more control over the connector configuration process and prevents unnecessary delays when you’re confident in your settings.

​
The Selenium version for the Web connector has been upgraded

The Selenium Hub used by the Web connector has been upgraded from version 4.20.0 to version 4.38.0. The previous version was over a year old and contained security vulnerabilities. Users can expect more reliable web crawling operations, enhanced security, and improved browser compatibility with Chrome, Firefox, and Edge.

​
Facet and JSON Facet stage improvements

Both the Facet and JSON Facet stages have been enhanced with several new capabilities that give you more control over facet presentation and matching:
  • Boost, bury, and suppress facet values The Facet and JSON Facet stages now support boost, bury, and suppress options for individual facet values, similar to the capabilities previously available only in facet rules. You can now promote important facet values to the top of the list (boost), move less relevant values to the bottom (bury), or hide specific values entirely (suppress) directly within the stage configuration. This provides greater flexibility for controlling facet display without requiring separate rules.
  • Facet field ordering You can now control the order in which facet fields appear in query responses for both standard facets and JSON facets. This ordering capability is available in both facet stages and facet rules, allowing you to define a specific display sequence for Field and Range facets that matches your business requirements or user interface needs.

​
Additional model parameters supported in Ray and Seldon vectorization stages

The Ray / Seldon Vectorize Field and Ray/Seldon Vectorize Query stages now support passing additional custom parameters to Ray and Seldon models beyond the basic text input. You can now include parameters such as tracking IDs, custom endpoints, input/output keys, and other model-specific configuration options in your vectorization requests.
​
Model Configuration
array
Additional model parameters to pass to the model. These will be included in the model request. Each item in the array contains a key-value pair.
​
Parameter Name
string
required
The name of the model parameter to pass in the request.
​
Parameter Value
string
The value for the model parameter.
This enhancement provides greater flexibility for logging, monitoring, and customizing model behavior to meet specific deployment requirements. The feature is backward compatible with existing configurations and works with both Ray and Seldon model deployments.

​
Operational improvements

Lucidworks Search 5.17 includes several infrastructure and operational enhancements that improve platform performance, scalability, and reliability. These improvements are managed by the Lucidworks cloud operations team and provide automatic benefits to all Lucidworks Search customers.

​
Event-driven autoscaling with KEDA

Lucidworks Search now uses KEDA (Kubernetes Event-Driven Autoscaling) to provide more responsive and efficient infrastructure scaling. Unlike traditional autoscaling that relies primarily on CPU and memory metrics, KEDA enables Lucidworks to scale your infrastructure based on actual workload demands, scheduled patterns, and business metrics. This provides several benefits:
  • Better response to traffic patterns Your infrastructure automatically scales up during peak usage periods and scales down during off-hours, ensuring optimal performance when you need it.
  • Improved cost efficiency Resources are allocated based on actual demand rather than static thresholds, reducing unnecessary infrastructure costs while maintaining performance.
  • More predictable performance Scheduled scaling aligns capacity with known traffic patterns (such as business hours or peak shopping seasons), preventing performance degradation during expected high-traffic periods.
KEDA-based autoscaling is now active for query pipeline and indexing services in your Lucidworks Search environment, providing automatic benefits without requiring any configuration changes.

​
Enhanced configuration management with ConfigSync

Lucidworks Search continues to leverage ConfigSync internally to maintain consistent configuration across your environment and provide reliable disaster recovery capabilities. Lucidworks Search 5.17 adds several ConfigSync enhancements that improve operational visibility and data protection:
  • Improved observability Enhanced monitoring capabilities provide better insight into configuration synchronization events, making it easier for Lucidworks support to diagnose and resolve configuration-related issues.
  • Commerce Studio collection protection ConfigSync now automatically includes Commerce Studio collections (with the _em suffix) in backup operations, ensuring complete configuration protection for Commerce Studio-enabled applications.
These improvements strengthen the reliability and recoverability of your Lucidworks Search environment, providing peace of mind for mission-critical search applications.

​
Enhanced monitoring capabilities

Lucidworks Search 5.17 introduces enhanced monitoring infrastructure with new exporters for Kafka and JMX metrics. These improvements enable more comprehensive observability of your search platform’s health and performance. The Lucidworks cloud operations team now has deeper visibility into Kafka consumer lag, topic metrics, broker performance, and JVM-level application metrics. This enhanced monitoring enables faster detection and resolution of potential issues, improving overall platform reliability and reducing response times for support incidents.

​
API Updates

Lucidworks Search 5.17 removes several deprecated endpoints in favor of more standardized alternatives. These changes align Lucidworks Search’s API surface with modern best practices and improve consistency across services. The following endpoints have been removed:
  • PUT /collections/{collection}/schema/dynamicfields/{fieldName} has been removed. Instead, use POST /solr/{collection}/schema with a replace-dynamic-field command in the request body: 
    {
  "replace-dynamic-field": {
    "name": "*_s",
    "type": "string",
    "stored": true
  }
}
  • PUT /collections/{collection}/schema/fields/{fieldName} has been removed. Instead, use POST /solr/{collection}/schema with a replace-field command in the request body: 
    {
  "replace-field": {
    "name": "field_name",
    "type": "string",
    "stored": true
  }
}

​
Application API enhancements for Solr collection configuration

The Lucidworks Search Application Create API now provides advanced options for controlling default Solr shard and replica strategies when creating applications programmatically. You can now specify the number and types of replicas (NRT, TLOG, or PULL) for the collections that will be created with your application. The API also provides visibility into all collections that will be created for the application, giving you better control over resource allocation and replication strategies. This enhancement is particularly useful for customers who need to customize Solr topology to match specific performance, availability, or resource constraints when deploying Lucidworks Search applications through automation.

​
OpenAPI documentation improvements

Several Lucidworks Search services have been updated to use OpenAPI specifications and resolve Swagger documentation issues. The fusion-indexing, fusion-api-gateway, and fusion-chassis services now provide improved API documentation with proper OpenAPI compliance, making it easier to understand available endpoints, request/response formats, and integration patterns. These updates enhance the developer experience when working with Lucidworks Search APIs and ensure that API documentation accurately reflects the actual service capabilities.

​
Bug fixes

​
PIN rules: pinned items outside the result window are now excluded rather than promoted to position 1

When a document was pinned to a position greater than the query’s rows value, Lucidworks Search incorrectly promoted it to position 1 instead of omitting it. PIN rule processing is now pagination-aware: pins that fall outside the current page are ignored.
ScenarioBeforeAfter
Pin at position 15, rows=10Promoted to position 1Excluded from results
Pin at position 15, rows=30Appears at position 15Appears at position 15

​
LWAI Gateway SSL protocol mismatch fixed

In Lucidworks Search 5.9.16, deployments using TLS with the LWAI Gateway service experienced HTTP 503 Service Unavailable errors when users attempted to configure LWAI Vectorize Field or Query stages. This occurred because the API Gateway attempted HTTPS connections to the LWAI Gateway service, which was only listening on HTTP, causing an Unsupported or unrecognized SSL message error. The protocol mismatch has been resolved, and TLS deployments can now properly configure LWAI vectorization stages.

​
Chunking RAG bridge stage now escapes document IDs properly

In previous versions of Lucidworks Search, the Chunking RAG Bridge stage failed with a Solr syntax error when processing documents with IDs containing special characters such as colons: 
{
  "timestamp" : "2026-04-09T14:50:03.947759",
  "service" : "query",
  "error" : "client",
  "path" : "/query-pipelines/Lucidworks_Docs_Site_Chunking_memoryUuid/collections/chunking/select",
  "message" : "org.apache.solr.search.SyntaxError: Cannot parse '(id:https://doc.lucidworks.com/docs/lw-platform/lw-cs/cstudio-editor*  OR id:https://doc.lucidworks.com/docs/lw-platform/lw-platform/overview*  OR ...': Encountered \" \":\" \": \"\" at line 1, column 9.\nWas expecting one of:\n    <AND> ...\n    <OR> ...\n    <NOT> ...\n    \"+\" ...\n    \"-\" ...\n    <BAREOPER> ...\n    \"(\" ...\n    \")\" ...\n    \"*\" ...\n    \"^\" ...\n    <QUOTED> ...\n    <TERM> ...\n    <FUZZY_SLOP> ...\n    <PREFIXTERM> ...\n    <WILDTERM> ...\n    <REGEXPTERM> ...\n    \"[\" ...\n    \"{\" ...\n    <LPARAMS> ...\n    \"filter(\" ...\n    <NUMBER> ...\n"
}
This pattern is commonly seen in web-crawled content where the document ID is a URL such as https://example.com. The stage now properly escapes document IDs in filter queries, allowing it to work correctly with web-crawled content and other sources that use special characters in document IDs.

​
Pipeline cache initialization fixed to reduce ZooKeeper load

In previous versions of Lucidworks Search, query and index pipeline services generated excessive ZooKeeper read traffic due to an uninitialized cache. The cache was created but never initialized, causing every pipeline lookup to bypass the cache and query ZooKeeper directly. This resulted in high ZooKeeper traffic that scaled with query volume and the number of pipeline pods in the cluster. The cache initialization has been fixed, significantly reducing ZooKeeper traffic and improving overall cluster performance.

​
Solr Indexer stage no longer fails with NullPointerException when using Unmapped Fields Mapping

In previous versions of Lucidworks Search starting with 5.9.10, the Solr Indexer stage could fail with a NullPointerException when the Unmapped Fields Mapping configuration was enabled with a DELETE operation. This occurred when a field configured for deletion in the Unmapped Fields Mapping settings caused the validator to incorrectly return null when processing other unrelated fields that had multiple values being mapped to single-value fields. Documents would fail to index entirely when this condition was triggered. The field validation logic has been fixed to properly handle DELETE operations in the Unmapped Fields Mapping configuration, ensuring that unmapped field operations only affect their intended target fields and do not interfere with the validation of other fields in the document.

​
Ray vectorization now handles non-ASCII characters correctly

In previous versions of Lucidworks Search, Ray vectorization failed when processing text containing non-ASCII characters such as trademark symbols, copyright symbols, or other special characters. Query pipelines failed with a Model execution error: CANCELLED: Failed to read message error, while index pipelines silently omitted vector fields from documents without any error message. This has been fixed by properly setting charset=UTF-8 in the Content-Type header for all Ray model requests. Query and index pipelines using Ray-based vectorization stages now correctly process text containing special characters, ensuring that documents with these characters are properly vectorized.

​
Filter queries now trigger rules when fq contains OR for the same field

In previous versions of Lucidworks Search, rules were only triggered when filter queries (fq) contained single values for a field, such as fq=categories_s:hep-th. Rules failed to trigger when multiple values for the same field were combined using OR logic, such as fq=categories_s:(hep-ph OR hep-th). This prevented rules from applying consistently across different query patterns. The rules engine has been enhanced to support OR-based filter values for the same field, so rules now trigger correctly whether you use single filter values or combine multiple values with OR clauses.

​
Vectorize query stage performance improved

In previous versions of Lucidworks Search, the vectorize query stage could experience significant latency due to inefficient OAuth token handling. The OAuth token initialization was being performed lazily on each request rather than being cached properly. This has been fixed by optimizing the OAuth token initialization and caching strategy, significantly reducing query latency. Additional logging has been added to improve troubleshooting and observability for vectorization stages.

​
Admin UI logging loop fixed

Previously, the Admin UI could enter an infinite logging loop when the /api/ui-logs endpoint failed. When this endpoint returned an error, the Admin UI would attempt to log that error, which would send another request to the same failing endpoint, creating a cascading loop. The Admin UI now detects and prevents logging errors that originate from the ui-logs endpoint itself, breaking the infinite loop. Additionally, log queues are now properly cleared even when logging fails, and error details are output to the console for debugging purposes.

​
JavaScript stage security enhancement

A security patch has been created to disable the Nashorn JavaScript engine for query and index pipeline JavaScript stages. This enhancement restricts JavaScript execution to only the more secure GraalVM engine, providing enhanced security for environments with strict security requirements. This feature is particularly useful for customers undergoing penetration testing or who require highly secure JavaScript execution environments. Contact Lucidworks if you need this security enhancement enabled.

​
Parsing and indexing fixes

Several datasource indexing and parsing bugs have been fixed that previously caused data inconsistencies, missing documents, or incorrect field extraction.
  • When Lucidworks Search parsed a document into multiple documents (such as splitting a large file into sections), it would index an extra container-doc document representing the parent document alongside the parsed child documents. This behavior caused confusion for users who would see unexpected extra documents in their index. The connector now skips indexing the container-doc while still maintaining proper deletion handling for parsed documents.
  • When Lucidworks Search parsed XML files with a root path configuration of / (representing the entire XML file as a single document), the absolute_resource_name field incorrectly included a #0 suffix. For example, https://example.com/file.xml would be stored as https://example.com/file.xml#0. This suffix has been removed, and the absolute_resource_name field now correctly reflects the original XML file path without any suffix.

​
LWAI Vectorize stage validation errors improved

In previous versions of Lucidworks Search, providing invalid or misplaced parameters in the LWAI Vectorize stage configuration (such as placing a parameter meant for modelConfig into useCaseConfig instead) resulted in an unhelpful NullPointerException. The stage now properly validates configuration parameters and returns an HTTP 400 Bad Request with a descriptive error message that indicates which parameter is invalid, the list of valid parameters for each configuration section, and contextual suggestions. This improves the user experience and reduces troubleshooting time.

​
Updating a datasource now displays default values

In previous versions of Lucidworks Search, default values for datasource configuration fields were only displayed when creating a new datasource. When editing an existing datasource, fields that had no value set by the user would appear empty instead of showing their default values. This made it difficult to understand the actual datasource configuration being used and could lead to confusion about whether default values were being applied. Default values now display properly in edit mode for all fields that have not changed the default value, ensuring consistency between the create and edit experiences.

​
Next job run time displays properly

In previous versions of Lucidworks Search, the next scheduled run time for jobs did not appear in the Jobs UI unless the browser was manually refreshed. This has been fixed, and the job schedule information now displays correctly and updates automatically without needing to manually refresh your browser.

​
Platform support and component versions

​
Kubernetes platform support

Lucidworks has tested and validated support for the following Kubernetes platforms and versions:
  • Google Kubernetes Engine (GKE): 1.30, 1.31, 1.32, 1.33, 1.34, 1.35
  • Microsoft Azure Kubernetes Service (AKS): 1.30, 1.31, 1.32, 1.33, 1.34, 1.35
  • Amazon Elastic Kubernetes Service (EKS): 1.30, 1.31, 1.32, 1.33, 1.34, 1.35
Support is also offered for Rancher Kubernetes Engine (RKE and RKE2) and OpenShift 4 versions that are based on Kubernetes 1.30, 1.31, 1.32, 1.33, 1.34, 1.35; note that RKE2 may require some Helm chart modification. OpenStack and customized Kubernetes installations are not supported. For more information on Kubernetes version support, see the Kubernetes support policy.

​
Component versions

The following table details the versions of key components that may be critical to deployments and upgrades.
ComponentVersion
Solrfusion-solr 5.17.0 (based on Solr 9.6.1)
ZooKeeper3.9.1
Spark3.4.1
Ingress ControllersNginx, Ambassador (Envoy), GKE Ingress Controller
Rayray[serve] 2.46.0
Helm3.4.1
More information about support dates can be found at Lucidworks Semantic Version Support Lifecycle.