Bug Report
Description
The SearchHitsHit schema in spec/schemas/ml._common.yaml declares a model_id property:
SearchHitsHit:
type: object
properties:
...
model_id:
$ref: '_common.yaml#/components/schemas/Name'
...
However, the OpenSearch ML search APIs (_plugins/_ml/models/_search, _plugins/_ml/agents/_search, etc.) never return model_id as a top-level field on search hits. These APIs use standard OpenSearch SearchResponse — the document ID (which IS the model ID) is always in the standard _id field.
Reproduction
# Search for ML models
curl -s http://localhost:9200/_plugins/_ml/models/_search \
-H "Content-Type: application/json" \
-d '{"query":{"match_all":{}},"size":1}'
Response hit structure:
{
"_index": ".plugins-ml-model",
"_id": "6Wd_7p4BTcJJvPo5kauK", // <-- this IS the model_id
"_version": 1,
"_seq_no": 0,
"_primary_term": 1,
"_score": 1.0,
"_source": { ... }
}
Note: no model_id field at the hit level. The _id field contains the model ID.
Impact
This causes downstream clients (e.g., opensearch-js#1032) to generate incorrect TypeScript types where hit.model_id appears valid but is always undefined at runtime.
Root Cause
The SearchModelTransportAction in ML Commons simply delegates to OpenSearch's standard search handler (MLSearchHandler.search()), which returns a standard SearchResponse. No custom field injection occurs.
The model_id field correctly exists on the Source schema (inside _source for model chunks), but it should not be on SearchHitsHit.
Suggested Fix
Remove model_id from the SearchHitsHit schema in spec/schemas/ml._common.yaml (around line 75):
SearchHitsHit:
type: object
properties:
_version:
$ref: '_common.yaml#/components/schemas/VersionNumber'
_seq_no:
$ref: '_common.yaml#/components/schemas/SequenceNumber'
_primary_term:
type: integer
_index:
$ref: '_common.yaml#/components/schemas/IndexName'
_id:
$ref: '_common.yaml#/components/schemas/Id'
_score:
type: ['null', number]
_source:
$ref: '#/components/schemas/Source'
- model_id:
- $ref: '_common.yaml#/components/schemas/Name'
sort:
type: array
items:
type: number
format: float
required:
- _score
Verified On
- OpenSearch 3.6.0 (official tarball)
- OpenSearch 2.19 (reported by issue author in opensearch-js#1032)
The field has never been returned by the ML search API — this is not a regression but an incorrect spec definition since its introduction.
Bug Report
Description
The
SearchHitsHitschema inspec/schemas/ml._common.yamldeclares amodel_idproperty:However, the OpenSearch ML search APIs (
_plugins/_ml/models/_search,_plugins/_ml/agents/_search, etc.) never returnmodel_idas a top-level field on search hits. These APIs use standard OpenSearchSearchResponse— the document ID (which IS the model ID) is always in the standard_idfield.Reproduction
Response hit structure:
{ "_index": ".plugins-ml-model", "_id": "6Wd_7p4BTcJJvPo5kauK", // <-- this IS the model_id "_version": 1, "_seq_no": 0, "_primary_term": 1, "_score": 1.0, "_source": { ... } }Note: no
model_idfield at the hit level. The_idfield contains the model ID.Impact
This causes downstream clients (e.g., opensearch-js#1032) to generate incorrect TypeScript types where
hit.model_idappears valid but is alwaysundefinedat runtime.Root Cause
The
SearchModelTransportActionin ML Commons simply delegates to OpenSearch's standard search handler (MLSearchHandler.search()), which returns a standardSearchResponse. No custom field injection occurs.The
model_idfield correctly exists on theSourceschema (inside_sourcefor model chunks), but it should not be onSearchHitsHit.Suggested Fix
Remove
model_idfrom theSearchHitsHitschema inspec/schemas/ml._common.yaml(around line 75):SearchHitsHit: type: object properties: _version: $ref: '_common.yaml#/components/schemas/VersionNumber' _seq_no: $ref: '_common.yaml#/components/schemas/SequenceNumber' _primary_term: type: integer _index: $ref: '_common.yaml#/components/schemas/IndexName' _id: $ref: '_common.yaml#/components/schemas/Id' _score: type: ['null', number] _source: $ref: '#/components/schemas/Source' - model_id: - $ref: '_common.yaml#/components/schemas/Name' sort: type: array items: type: number format: float required: - _scoreVerified On
The field has never been returned by the ML search API — this is not a regression but an incorrect spec definition since its introduction.