Describe the bug/error/problem
multi_json 1.21.0 deprecated the legacy MultiJson constant in favor of MultiJSON. elasticsearch-api still references the legacy constant as its default serializer, in lib/elasticsearch/api.rb (still present on main, commit 73acacb):
DEFAULT_SERIALIZER = MultiJson
Every call that goes through Elasticsearch::API.serializer (e.g. Utils.__bulkify for bulk requests, msearch, msearch_template, fleet.msearch) routes through multi_json's deprecation shim and emits, once per process:
The MultiJson constant is deprecated and will be removed in v2.0. Use MultiJSON instead.
MultiJSON.dump is deprecated and will be removed in v2.0. Use MultiJSON.generate instead.
The second warning appears because dump/load are themselves deprecated aliases on the new MultiJSON module (the current API is generate/parse).
This is the same problem that was reported for the transport layer in elastic/elastic-transport-ruby#125 and fixed in elastic-transport 8.5.3: with an up-to-date transport, elasticsearch-api is now the remaining source of these warnings.
To Reproduce
require 'elasticsearch' # with multi_json >= 1.21 installed
Warning[:deprecated] = true
Elasticsearch::API.serializer.dump({ a: 1 })
# => The MultiJson constant is deprecated and will be removed in v2.0. Use MultiJSON instead.
# => MultiJSON.dump is deprecated and will be removed in v2.0. Use MultiJSON.generate instead.
In a real application the warnings appear at runtime on the first bulk indexing request (or any other API that serializes a payload through Elasticsearch::API.serializer).
Expected behavior
No deprecation warnings: the serializer should use the MultiJSON constant and its current API (generate/parse) when multi_json >= 1.21 is loaded, falling back to MultiJson.dump/MultiJson.load on older versions. Checking defined?(::MultiJSON) handles both cases without version sniffing.
Your Environment (please complete the following information):
- Operating System: macOS 15
- Ruby Version: Ruby MRI 4.0.1
- Elasticsearch client version:
elasticsearch / elasticsearch-api 8.19.3 (the legacy constant is also still referenced on main)
multi_json version: 1.21.1
- Elasticsearch version: 8.19
Additional context
A workaround for applications is to inject a custom serializer:
module MultiJsonSerializerShim
def self.dump(object, options = {})
MultiJSON.generate(object, options)
end
def self.load(string, options = {})
MultiJSON.parse(string, options)
end
end
Elasticsearch::API.settings[:serializer] = MultiJsonSerializerShim
Issue opened with the help of Claude Code.
Describe the bug/error/problem
multi_json1.21.0 deprecated the legacyMultiJsonconstant in favor ofMultiJSON.elasticsearch-apistill references the legacy constant as its default serializer, inlib/elasticsearch/api.rb(still present onmain, commit73acacb):Every call that goes through
Elasticsearch::API.serializer(e.g.Utils.__bulkifyfor bulk requests,msearch,msearch_template,fleet.msearch) routes throughmulti_json's deprecation shim and emits, once per process:The second warning appears because
dump/loadare themselves deprecated aliases on the newMultiJSONmodule (the current API isgenerate/parse).This is the same problem that was reported for the transport layer in elastic/elastic-transport-ruby#125 and fixed in
elastic-transport8.5.3: with an up-to-date transport,elasticsearch-apiis now the remaining source of these warnings.To Reproduce
In a real application the warnings appear at runtime on the first bulk indexing request (or any other API that serializes a payload through
Elasticsearch::API.serializer).Expected behavior
No deprecation warnings: the serializer should use the
MultiJSONconstant and its current API (generate/parse) whenmulti_json >= 1.21is loaded, falling back toMultiJson.dump/MultiJson.loadon older versions. Checkingdefined?(::MultiJSON)handles both cases without version sniffing.Your Environment (please complete the following information):
elasticsearch/elasticsearch-api8.19.3 (the legacy constant is also still referenced onmain)multi_jsonversion: 1.21.1Additional context
A workaround for applications is to inject a custom serializer:
Issue opened with the help of Claude Code.