elasticsearch/docs/reference/migration/migrate_8_7.asciidoc
James Rodewig e00b354c26
[DOCS] Remove breaking change tags (#98144)
With https://github.com/elastic/stack-docs/pull/2495 merged, we no longer reuse breaking changes in the Stack Install/Upgrade guide.

This removes the related `notable-breaking-changes[]` tags from the 8.9+ docs and updates the RN generator template.

## Out of scope
With the removal of these tags, we may no longer need the `notable` property for changelog entries and can likely simplify the logic for the [BreakingChangesGenerator](https://github.com/elastic/elasticsearch/blob/main/build-tools-internal/src/main/java/org/elasticsearch/gradle/internal/release/BreakingChangesGenerator.java). Updating those files is outside the scope of this PR. I've opened https://github.com/elastic/elasticsearch/issues/98145 to track that work.
2023-08-03 15:23:47 -04:00

43 lines
1.6 KiB
Text

[[migrating-8.7]]
== Migrating to 8.7
++++
<titleabbrev>8.7</titleabbrev>
++++
This section discusses the changes that you need to be aware of when migrating
your application to {es} 8.7.
See also <<release-highlights>> and <<es-release-notes>>.
[discrete]
[[breaking-changes-8.7]]
=== Breaking changes
The following changes in {es} 8.7 might affect your applications
and prevent them from operating normally.
Before upgrading to 8.7, review these changes and take the described steps
to mitigate the impact.
There are no notable breaking changes in {es} 8.7.
But there are some less critical breaking changes.
[discrete]
[[breaking_87_ingest_changes]]
==== Ingest changes
[[making_jsonprocessor_stricter_so_it_does_not_silently_drop_data]]
.Making `JsonProcessor` stricter so that it does not silently drop data
[%collapsible]
====
*Details* +
The ingest node's `json` processor was previously lenient. It would accept invalid JSON data if it started with valid JSON data.
Anything after the valid part would be silently discarded. From 8.7 onwards, the default behavior is to reject invalid JSON data with
an exception so that data is not silently lost. The old behavior can be reproduced by passing `false` as the value of the new
`strict_json_parsing` processor parameter.
We consider this change to be a bugfix but list it here as a breaking change since it may affect the behavior of applications which
were sending invalid JSON data to the `json` processor.
*Impact* +
Ensure your application only sends valid JSON data to the `json` processor, or modify the `json` processors in your pipelines to set
the `strict_json_parsing` parameter to `false`.
====