X-pack licensing plugin issues too many duplicate requests on page load

[shahzad31]

Kibana version:

Master

Original install method (e.g. download page, yum, from source, etc.):
Source

Describe the bug:

When for example Observability homepage is loaded, it has too many requests for licensing info originating from x-pack/licensing plugin.

In below example there are 9 xhr requests for same api.

This is the URL it calls
http://localhost:5601/api/licensing/info

There should be only one request to get license info.

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[pgayvallet]

There should be only one request to get license info.

Not really. We are using pooling and manual triggers to stay sync with the server's state.

However having 7 requests during startup seems a lot. @restrry I guess it is not expected? Do you know what could cause that?

[shahzad31]

it's actually 9 requests on page load in above example :)

Alright i was not aware of pooling to sync with server state.

[mshustov]

@restrry I guess it is not expected?

no, it's not expected behaviour. We even have a test to ensure we do not over-fetch

kibana/x-pack/plugins/licensing/common/license_update.test.ts

Line 79 in 3d67eaa

it('new subscriptions does not force re-fetch', async () => {

The root problem is Observability plugin uses http.fetch to perform AJAX request to 3rd party service https://feeds.elastic.co/observability-solution/..., which is not supported at the moment.

kibana/src/core/public/http/types.ts

Line 263 in 0d45d9b

* A function for making an HTTP requests to Kibana's backend. See {@link HttpFetchOptions} for options and

Because response doesn't contain kbn-license-sig header, this condition gives a false positive

kibana/x-pack/plugins/licensing/public/plugin.ts

Line 104 in 5f781dc

if (this.prevSignature !== signatureHeader) {

We should:

• handle the case when kbn-license-sig header is not present
• log a warning when fetch used against non-Kibana backend

[joshdover]

log a warning when fetch used against non-Kibana backend

Honestly, we should probably throw an error. I'm surprised this works tbh. There are a lot of assumptions in that service and registered interceptors that this is only used for requests against Kibana's backend.