Remove deprecated 'body' key from Request interfaces

[mshustov]

elasticsearch-js client deprecated body key usage in request interfaces. body key support will be removed in the following major release.
Kibana codebase should be upgraded accordingly to prepare for this breaking change.

// from
const response = await client.search({
  index: 'test',
  body: {
    query: {
      match_all: {}
    }
  }
})

// to
const response = await client.search({
  index: 'test',
  query: {
    match_all: {}
  }
})

Right now it affects DX of elasticsearch service mocks. Since consumers of the mocks have to declare a compatible interface explicitly.

(esClient.bulk.mock.calls[0][0] as estypes.BulkRequest)?.body

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[pgayvallet]

@elastic/clients-team do you know if removing the body key from the client's signature is still something planned?

[JoshMock]

@pgayvallet I would like to include that as part of 9.0. It would significantly simplify the type definitions for each API.

[TinaHeiligers]

@JoshMock any updates on plans that we need to know about?

[JoshMock]

The plan is tentative, primarily because I wanted to check back in with you all on how you're feeling about it. 🙂 What's the overall sentiment?

While it does make sense to remove something that's deprecated (albeit, deprecated before my time as maintainer), automated codegen does all the work to maintain the second set of type definitions, so the effort isn't any higher. The only pain it really presents, then, is the readability of the generated API function code (e.g. T.CatAliasesRequest | TB.CatAliasesRequest would become T.CatAliasesRequest for all functions). On the whole, that's a pretty small annoyance, just multiplied by a few hundred functions.

In other words, it's a nice-to-have, but only for aesthetic/readability purposes.

[afharo]

I'm ++ to having them removed and simplify the types. However, the hardest part for us to to identify all usages of body in the Kibana codebase. I wonder if there's any "easy" way to identify all usages so that we can tackle them. body is a widely used word in many different scopes, so a binary search doesn't really help 😅

[JoshMock]

@afharo When I get to some other 9.0 changes I hope to make, I can publish an alpha release to npm that drops body types. That way you'd be able to run your test suite and get an idea of how widespread it will be.

[afharo]

@JoshMock, that sounds like a great approach. I wonder how many usages are missing tests (and implemented in .js so types won't complain). But we can hope for the best and for QA in beta versions to highlight any remaining uncaught usage.

cc @elastic/kibana-core, how does that sound?

[JoshMock]

I wonder how many usages are missing tests (and implemented in .js so types won't complain)

If I totally remove body support, you might know at run time if the request bodies are validated during your tests. If not, I could push a branch to Github that also throws an error if a body property is used. Then you could clone, build and install that branch and test Kibana against that.