Fails since 7.14.0

[elastic]

Fails since 7.14.0

[LukaPrebil]

Another workaround, without returning errors:

// Needed as the es client >[email protected] validates whether it is connected to a real ES instance
// by GETting / and checking these fields in the response
esMock.add({ method: "GET", path: "/" }, () => ({
  name: "mocked-es-instance",
  version: {
    number: "7.12.1",
    build_flavor: "default",
  },
  tagline: "You Know, for Search",
}));

[xfournet]

Workaround for client verification:
mock.add({ method: 'GET', path: '/' }, () => new ResponseError({ statusCode: 401, body: '' }));

[xfournet]

Updating to @elastic/elasticsearch 7.14.0 make my unit tests failing with that error:

    ResponseError: Response Error

      at onBody (../node_modules/@elastic/elasticsearch/lib/Transport.js:349:23)
      at Class.onEnd (../node_modules/@elastic/elasticsearch/lib/Transport.js:275:11)
      at endReadableNT (../node_modules/readable-stream/lib/_stream_readable.js:1010:12)

Still works well with 7.13.0

[seancolyer]

@delvedor I believe I've narrowed it down to the following mock being added in some of our tests (where function is checking an index size as part of its other operations):

    mock.add({
      method: 'GET',
      path: `/*/_stats`
    }, () => {
      return {
        _all: {
          total: {
            store: {
              size_in_bytes: 1000000000
            }
          }
        }
      }
    });

Previously, this works fine. It seems that now if you have this you also need the explicit hack:

    mock.add({ method: "GET", path: "/" }, () => ({
      name: "mocked-es-instance",
      version: {
        number: "7.14.1",
        build_flavor: "default",
      },
      tagline: "You Know, for Search",
    }));

Otherwise in our case, @elastic/elasticsearch 7.14.1 will bomb out with the product license error hitting the elasticsearch-mock 0.3.1 values.

Let me know if this is enough to reproduce.

[LukaPrebil]

I am also getting an error since 7.14.0. ProductNotSupportedError: The client noticed that the server is not Elasticsearch and we do not support this unknown product.

[xfournet]

Relate to elastic/elasticsearch-js#1487

[exos]

The problem is since elastic-search 7.12.0

[xfournet]

Another possible hack. This one is not specific to mock and that can be also used to continue to use elasticsearch-js with AWS Elasticsearch

const client = new Client(...);

const productCheckSymbol = Object.getOwnPropertySymbols(client.transport).find(({ description }) => description === 'product check');
if (productCheckSymbol) {
  client.transport[productCheckSymbol] = 2;
}

I am jumping on this bandwagon and confirming my tests are broken on 7.14.0 and not 7.13.0.

[delvedor]

Hello! Bug confirmed, thank you for reporting!
I'll work on a fix.

[delvedor]

Fixed in v0.3.1, please update the client to at least v7.14.1 as well.

[seancolyer]

FYI @delvedor there's some edge case here where this is still broken, I don't know exactly what it is.

90%+ of my tests worked with 0.3.1, but there was some that were still broken.

For some reason, I still end up needing one of the hacks above in some tests.

  // ProductNotSupportedError: The client noticed that the server is not Elasticsearch and we do not support this unknown product.
  mock.add({ method: "GET", path: "/" }, () => ({
    name: "mocked-es-instance",
    version: {
      number: "7.14.1",
      build_flavor: "default",
    },
    tagline: "You Know, for Search",
  }));

It's perhaps related to an issue with nock or possibly mock.clearAll in a beforeEach being used in those tests (which we use for non-es testing). Not sure. Burned a bunch of time on this already.

As an aside, the fact that the product checking wasn't part of a major release was a major disservice to developers. I say this as developers bought into the ES ecosystem, not even pursuing OSS version.

This was exposed for us as an issue with a routine winston-elasticsearch patch bump, (which included 7.14 es), and exposed cascading dependency failures in our tests, and even after switching the rest of the app to 7.14 (and 0.3.1 of this lib) we still had failures.

[delvedor]

Hi @seancolyer, can you provide a way to reproduce the bug you are experiencing? It would be really helpful to debug it.

I say this as developers bought into the ES ecosystem, not even pursuing OSS version.

The product check should be transparent if you are using a genuine version of ES, what issue are you facing?

[delvedor]

It looks like it's an issue in the routing library, until it's fixed the only workaround is what you are doing already. Nice catch!