[BUG] Compression is broken with ml-commons streaming

[Swiddis]

What is the bug?
All requests with compression (tested: gzip, zstd) fail when ml-commons is installed with streaming. This breaks, among other things, the http_compress=True option in opensearchpy.

How can one reproduce the bug?
Steps to reproduce the behavior:

1. gradlew run -Dstreaming=true

Plugins:

integTest-0 arrow-flight-rpc         3.6.0-SNAPSHOT
integTest-0 opensearch-job-scheduler 3.6.0.0-SNAPSHOT
integTest-0 opensearch-ml            3.6.0.0-SNAPSHOT
integTest-0 transport-reactor-netty4 3.6.0-SNAPSHOT

$ echo '{"settings":{"number_of_shards":1}}' \
  | gzip \
  | curl -X PUT "localhost:9200/test_bug" -H "Content-Type: application/json" -H "Content-Encoding: gzip" --data-binary @- --silent \
  | jq
{
  "error": {
    "root_cause": [
      {
        "type": "not_x_content_exception",
        "reason": "Compressor detection can only be called on some xcontent bytes or compressed xcontent bytes"
      }
    ],
    "type": "not_x_content_exception",
    "reason": "Compressor detection can only be called on some xcontent bytes or compressed xcontent bytes"
  },
  "status": 400
}

What is the expected behavior?

{
  "acknowledged": true,
  "shards_acknowledged": true,
  "index": "test_bug"
}

What is your host/environment?

• OS: Linux, kernel 5.10
• Version: mainline
• Plugins: opensearch-ml & streaming plugins.

Do you have any screenshots?

N/A

Do you have any additional context?
N/A

[nathaliellenaa]

Can I get assigned to this?

[nathaliellenaa]

Streaming in ml commons requires setting http.type to reactor-netty4 / reactor-netty4-secure. Through testing, I've confirmed this is the source of the issue:

Configuration	http.type	Result
./gradlew run (no streaming)	netty4 (default)	✅ Working
./gradlew run -Dstreaming=true	reactor-netty4	❌ Failing
./gradlew run -Dstreaming=true (reverted http.type)	netty4 (default)	✅ Working

This confirms the issue originates from the transport-reactor-netty4 plugin, not ml commons.

@rishabhmaurya Could you take a look at this, or direct to the right person to reach out to?

[nathaliellenaa]

@Swiddis We're planning to migrate away from the transport-reactor-netty4 dependency for streaming in ml commons as no one owns the plugins. Is this issue block something critical?

[andrross]

Catch All Triage - 1