|
| 1 | +[[release-notes-8.19.1]] |
| 2 | +== {es} version 8.19.1 |
| 3 | + |
| 4 | +coming[8.19.1] |
| 5 | + |
| 6 | +Also see <<breaking-changes-8.19,Breaking changes in 8.19>>. |
| 7 | + |
| 8 | +[[bug-8.19.1]] |
| 9 | +[float] |
| 10 | +=== Bug fixes |
| 11 | + |
| 12 | +Data streams:: |
| 13 | ++ |
| 14 | +.Disables auto-sharding for LOOKUP index mode |
| 15 | +[%collapsible] |
| 16 | +=============== |
| 17 | +Auto-sharding for data streams caused unsupported replica scaling when the index mode was set to `LOOKUP`. |
| 18 | +This happened because lookup mappers do not support scaling beyond one replica. |
| 19 | +{es-pull}131429[#131429] resolves this issue by disabling auto-sharding for data streams with `LOOKUP` index mode, avoiding unsupported replica settings. |
| 20 | +=============== |
| 21 | + |
| 22 | +EQL:: |
| 23 | ++ |
| 24 | +.Resolves EQL parsing failure for IP-mapped fields in `OR` expressions |
| 25 | +[%collapsible] |
| 26 | +=============== |
| 27 | +Parsing EQL queries failed when comparing the same IP-mapped field to multiple values joined by an `OR` expression. |
| 28 | +This occurred because lookup operators were internally rewritten into `IN` expressions, which are unsupported for IP-type fields. |
| 29 | +{es-pull}132167[#132167] resolves the issue and ensures EQL can now successfully parse and execute such or queries involving IP fields. (issue: {es-issue}118621[#118621]) |
| 30 | +=============== |
| 31 | + |
| 32 | +ES|QL:: |
| 33 | ++ |
| 34 | +.Fixes inconsistent equality and hashcode behavior for `ConstantNullBlock` |
| 35 | +[%collapsible] |
| 36 | +=============== |
| 37 | +Inconsistent equality checks caused `constantNullBlock.equals(anyDoubleBlock)` to return false, even when `doubleBlock.equals(constantNullBlock)` returned true. |
| 38 | +This asymmetry led to unreliable comparisons and mismatched hashcodes when `ConstantNullBlock` was functionally equivalent to other standard blocks. |
| 39 | +{es-pull}131817[#131817] resolves the issue and ensures both equality and hashcode functions are symmetric for these block types. |
| 40 | +=============== |
| 41 | ++ |
| 42 | +.Fixes `ConcurrentModificationException` caused by live operator list |
| 43 | +[%collapsible] |
| 44 | +=============== |
| 45 | +A `ConcurrentModificationException` caused test failures in `CrossClusterAsyncEnrichStopIT.testEnrichAfterStop` under certain conditions. |
| 46 | +This happened because the ES|QL driver added a live operator list to the `DriverStatus` object, which could be modified while the status was being serialized. |
| 47 | +{es-pull}132260[#132260] fixes the issue by copying the operator list before storing it, preventing concurrent changes during status reads. |
| 48 | +(issue: {es-issue}131564[#131564]) |
| 49 | +=============== |
| 50 | ++ |
| 51 | +.Prevents null pointer exception for `to_lower` and `to_upper` with no parameters |
| 52 | +[%collapsible] |
| 53 | +=============== |
| 54 | +Calling the `to_lower` or `to_upper` functions with no parameters caused a null pointer exception (NPE), instead of returning a clear error. |
| 55 | +This behavior was a result of an older implementation of these functions. |
| 56 | +{es-pull}131917[#131917] resolves the issue and ensures that empty parameter calls now return the correct error message. (issue: {es-issue}131913[#131913]) |
| 57 | +=============== |
| 58 | ++ |
| 59 | +.Fixes `aggregate_metric_double` decoding and `mv_expand` behavior on multi-index queries |
| 60 | +[%collapsible] |
| 61 | +=============== |
| 62 | +Sorting across multiple indices failed when one index contained an `aggregate_metric_double` field and another did not. |
| 63 | +In this case, the missing field was encoded as `NullBlock` but later incorrectly decoded as `AggregateMetricDoubleBlock`, which expects four values. This mismatch caused decoding errors. |
| 64 | +{es-pull}131658[#131658] resolves the issue and also improves `mv_expand` by returning the input block unchanged for unsupported `AggregateMetricDoubleBlock` values, avoiding unnecessary errors. |
| 65 | +=============== |
| 66 | ++ |
| 67 | +.Fixes incorrect `ingest_took` value when combining bulk responses |
| 68 | +[%collapsible] |
| 69 | +=============== |
| 70 | +Combining two `BulkResponse` objects with `ingest_took` set to `NO_INGEST_TOOK` resulted in a combined `ingest_took` value of `-2`, which was invalid. |
| 71 | +This occurred because the combination logic failed to preserve the sentinel `NO_INGEST_TOOK` constant. |
| 72 | +{es-pull}132088[#132088] resolves the issue and ensures the result is correctly set to `NO_INGEST_TOOK` when applicable. |
| 73 | +=============== |
| 74 | ++ |
| 75 | +.Adds support for splitting large pages on load to avoid memory pressure |
| 76 | +[%collapsible] |
| 77 | +=============== |
| 78 | +Loading large rows from a single segment occasionally created oversized pages when decoding values row-by-row, particularly for text and geo fields. |
| 79 | +This could cause memory pressure or degraded performance. |
| 80 | +{es-pull}131053[#131053] resolves the issue by estimating the size of each page as rows are loaded. |
| 81 | +If the estimated size exceeds a configurable `jumbo` threshold (defaulting to one megabyte), row loading stops early, the page is returned, and remaining rows are processed in subsequent iterations. |
| 82 | +This prevents loading incomplete or oversized pages during data aggregation. |
| 83 | +=============== |
| 84 | + |
| 85 | +Infra/Core:: |
| 86 | ++ |
| 87 | +.Grants server module read/write permissions for deprecated `path.shared_data` setting |
| 88 | +[%collapsible] |
| 89 | +=============== |
| 90 | +Grants the server module read/write access to the deprecated `path.shared_data` setting. |
| 91 | +{es-pull}131680[#131680] resolves issues surfaced in internal testing and ensures compatibility with legacy configurations. |
| 92 | +=============== |
| 93 | + |
| 94 | +Ingest Node:: |
| 95 | ++ |
| 96 | +.Fixes incorrect mapping resolution in simulate ingest API when `mapping_addition` is provided |
| 97 | +[%collapsible] |
| 98 | +=============== |
| 99 | +When using the simulate ingest API with a `mapping_addition`, the system incorrectly ignored the existing mapping of the target index and instead applied the mapping from a matching index template, if one existed. |
| 100 | +This caused mismatches between the index and simulation behavior. |
| 101 | +{es-pull}132101[#132101] resolves the issue and ensures that the index’s actual mapping is used when available, preserving consistency between simulation and execution. |
| 102 | +=============== |
| 103 | + |
| 104 | +Machine Learning:: |
| 105 | ++ |
| 106 | +.Prevents double-counting of allocations in trained model deployment memory estimation |
| 107 | +[%collapsible] |
| 108 | +=============== |
| 109 | +A recent refactor introduced a bug that caused the trained model memory estimation to double-count the number of allocations, leading to inflated memory usage projections. |
| 110 | +{es-pull}131990[#131990] resolves the issue by reverting the change and restoring accurate memory estimation for trained model deployments. |
| 111 | +=============== |
| 112 | + |
| 113 | +Mapping:: |
| 114 | ++ |
| 115 | +.Fixes decoding failure for non-ASCII field names in `_ignored_source` |
| 116 | +[%collapsible] |
| 117 | +=============== |
| 118 | +A decoding error occurred when field names in `_ignored_source` contained non-ASCII characters. |
| 119 | +This happened because `String.length()` was used to calculate the byte length of the field name, which only works correctly for ASCII characters. |
| 120 | +{es-pull}132018[#132018] resolves the issue by using the actual byte array length of the encoded field name, ensuring proper decoding regardless of character encoding. |
| 121 | +=============== |
| 122 | + |
| 123 | +Search:: |
| 124 | ++ |
| 125 | +.Fixes index sort compatibility for `date_nanos` fields in indices created before 7.14 |
| 126 | +[%collapsible] |
| 127 | +=============== |
| 128 | +Indices created prior to version 7.14 that used an index sort on a `date_nanos` field could not be opened in more recent versions due to a mismatch in the default `index.sort.missing` value. |
| 129 | +A change in version 7.14 modified the default from `Long.MIN_VALUE` to `0L`, which caused newer versions to reject those older indices. |
| 130 | +{es-pull}132162[#132162] resolves the issue by restoring the expected default value for indices created before 7.14, allowing them to open successfully in newer versions. (issue: {es-issue}132040[#132040]) |
| 131 | +=============== |
| 132 | ++ |
| 133 | +.Fix missing removal of query cancellation callback in QueryPhase |
| 134 | +[%collapsible] |
| 135 | +=============== |
| 136 | +The timeout cancellation callback registered in `QueryPhase` via `addQueryCancellation` was not removed after the query phase completed. |
| 137 | +This caused unintended timeouts or cancellations during subsequent phases under specific conditions (such as large datasets, low timeouts, and partial search results enabled). |
| 138 | +{es-pull}130279[#130279] resolves the issue and ensures predictable behavior by reintroducing the cleanup logic. (issue: {es-issue}130071[#130071]) |
| 139 | +=============== |
| 140 | + |
| 141 | +[[enhancement-8.19.1]] |
| 142 | +[float] |
| 143 | +=== Enhancements |
| 144 | + |
| 145 | +Engine:: |
| 146 | +* Available disk space is now recorded when merge tasks are scheduled, helping to diagnose issues caused by running merges despite low disk space on nodes. This information appears in heap dumps and can inform adjustments to `indices.merge.disk.watermark.high` or inspire future enhancements such as aborting already running merges. {es-pull}131711[#131711] |
| 147 | + |
| 148 | + |
| 149 | + |
| 150 | + |
| 151 | + |
0 commit comments