Fix type and schema mismatches across the spec

[sean-]

Summary

Fixes type and schema mismatches across the spec, verified against server source code. Two classes of bug are addressed:

1. Integer type mismatches. Code generators use the format specifier to choose native integer types — wrong formats produce incorrect generated code (e.g., int64 emits long in Java / int64 in Go where the server expects int).
2. Path parameter cardinality. Several path parameters referenced the singular Name / Id schemas where the server splits the value on commas (or vice versa). The singular schemas accept a string; Names / Ids are oneOf single-or-array, matching the comma-separated syntax the server actually accepts.

All changes were verified by reading the Java/Kotlin server declarations for each field.

Bug fix: notifications HeaderParamsMap has wrong type (integer → string)

HeaderParamsMap.additionalProperties was defined as type: integer, format: int32, but the server declares this as Map<String, String> (CustomWebhookDestination.kt). This is not a width mismatch — the type is entirely wrong. Code generators emit integer-typed map values where the server sends and expects strings.

Bug fix: path parameter cardinality (Name/Id ↔ Names/Ids)

Three path parameters had a schema reference that did not match server behavior. The singular Name and Id schemas accept a single string; Names and Ids are oneOf single-or-array, matching the comma-separated path syntax accepted by Strings.splitStringByCommaToArray. Code generators emit the wrong type — a single string where the server accepts a list, or a list where the server accepts only a single name.

Spec parameter	Before	After	Server behavior
snapshot.delete::path.snapshot	Name	Names	Server splits on commas via Strings.splitStringByCommaToArray, stored as String[] snapshots.
ingest.get_pipeline::path.id	Id	Ids	Server splits on commas via Strings.splitStringByCommaToArray.
snapshot.delete_repository::path.repository	Names	Name (reverse)	Server reads a single repository string. Wildcard matching is performed on a single name pattern, not a comma-separated list.

Server references (OpenSearch 27333365):

• RestDeleteSnapshotAction.java#L73 — Strings.splitStringByCommaToArray(request.param("snapshot"))
• DeleteSnapshotRequest.java#L58-L71 — private String[] snapshots; public DeleteSnapshotRequest(String repository, String... snapshots)
• RestGetPipelineAction.java#L71 — Strings.splitStringByCommaToArray(restRequest.param("id"))
• RestDeleteRepositoryAction.java#L70 — request.param("repository") (single string)
• DeleteRepositoryRequest.java#L55-L70 — private String name

Changes by area

ML plugin (ml.yaml, ml._common.yaml) — int64 → int32

• size (×10): _search request bodies — SearchSourceBuilder.size is Java int
• total_chunks (×2), chunk_number (×2): Java Integer
• num_outputs: Java int

Security Analytics (security_analytics.yaml) — int64 → int32

• size, startIndex (×2 each): request.paramAsInt() in alert and findings handlers
• nearby_findings: request.paramAsInt() in correlation handler

Core OpenSearch schemas — mixed direction

int64 → int32 (server uses Java int):

• indices.forcemerge max_num_segments
• cluster.stats ClusterStatsIndices.count
• cluster.remote_info num_nodes_connected
• nodes.stats ThreadCount active/largest/queue/threads
• snapshot file_count, SnapshotShardsStats 6 fields
• indices.recovery RecoveryFiles recovered/reused/total
• indices.stats ShardCommit.num_docs
• _common RecoveryStats current_as_source/current_as_target, RefreshStats.listeners

int32 → int64 (server uses Java long):

• indices.stats ShardCommit.generation
• nodes.info NodeInfoJvmInfo.pid, NodeInfoNetwork.refresh_interval
• _common SegmentsStats.count

integer/int32 → number/double:

• cluster.stats ClusterIndicesShards.replication

Core search APIs — mixed direction

int64 → int32: TermSuggestion.Option.freq, MultiSearchItem.status, ReindexStatus.batches
int32 → int64: AggregationProfileDebug.total_buckets, FetchProfileBreakdown (8 fields), Term.ttf
number → integer/int64: MultiSearchResult.took
number → integer/int32: MultiSearchItem.status

Flow Framework (flow_framework.common.yaml) — add missing int64 format

11 type: integer fields lacked a format specifier. Without format: int64, code generators default to int32, but the server uses Java long:

• created_time, last_updated_time — Instant.toEpochMilli()
• total.value — TotalHits.value
• _version, _seq_no, _primary_term (×6) — long in GetResult.java
• took (×2) — long tookInMillis

Notifications (notifications._common.yaml) — integer → string (bug)

• HeaderParamsMap additionalProperties: type: integer, format: int32 → type: string

Snapshot and ingest namespaces — path parameter cardinality

• snapshot.delete::path.snapshot: Name → Names
• snapshot.delete_repository::path.repository: Names → Name (reverse)
• ingest.get_pipeline::path.id: Id → Ids

Server references

All changes verified against these commits:

Repo	SHA
OpenSearch	27333365da0d55a16bea2ebaf34f6f2a691f6d50
ml-commons	be86ad045dac49f35d811b74f2928a27536da2a4
security-analytics	4c3d533dd7d71d734f94deb9038fd9b46ae368f2
flow-framework	30ed527ae0b121ee7e47db8326d6672ca4d76aa8
notifications	690f3df226f2da10da23bb717ff151406be8c436

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.