Saved Objects `config` type export broken on master

[majagrubic]

Kibana version: Master

Elasticsearch version: Snapshot

Server OS version: Mac OS 10.14.5

Browser version: Chrome 80.0

Browser OS version: Mac OS 10.14.5

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

Describe the bug:
Saved Objects Export fails with status 400.

{"statusCode":400,"error":"Bad Request","message":"[request body.type]: types that failed validation:\n- [request body.type.0]: expected value of type [string] but got [Array]\n- [request body.type.1.6]: config is not exportable"}

Steps to reproduce:
0. Add Kibana Sample Data

1. Go to Kibana Management Console > Saved Objects
2. In the header of Saved Objects table, select "Export 54 Objects" (there should be 54 from the sample data)
3. Click Export All
4. Error message is displayed

Expected behavior:
.ndjson file is generated and ready for download.

Screenshots (if relevant):

Errors in browser console (if relevant):
Response:

{"statusCode":400,"error":"Bad Request","message":"[request body.type]: types that failed validation:\n- [request body.type.0]: expected value of type [string] but got [Array]\n- [request body.type.1.6]: config is not exportable"}

Provide logs and/or server output (if relevant):
I don't see anything weird in the server log.

Any additional context:
Selecting individual objects and exporting them succeeds.

This works fine on 7.6.0 so must have been recently introduced.

[elasticmachine]

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

[joshdover]

@pgayvallet would you be able to look at this one since you’re working in this area? My guess is that we broke this in one of the recent changes to these routes or the validation parsing of arrays.

[joshdover]

The fact that we have no tests to catch this is a little alarming as well 😬

[pgayvallet]

The fact that we have no tests to catch this is a little alarming as well

The fact that we actually do might scare you even more then: test/api_integration/apis/saved_objects/export.js

[joshdover]

I was able to reproduce this issue as well

I'm guessing that the input data in the API tests don't match what the UI is actually sending right now. We probably need true e2e tests that click through the UI.

[pgayvallet]

[request body.type.0]: expected value of type [string] but got [Array]

This part of the error message makes me think the export is sending a nested array of types, which definitly should not be permitted (but that probably was accepted before the migration...)

\n- [request body.type.1.6]: config is not exportable"}

@majagrubic is the config type registration migrated to NP ? If so, that broke the import/export attribute of the type until #59291 is merged, so that would explain that one.

[majagrubic]

is the config type registration migrated to NP?

I'm sorry, not sure what this refers to. I've run this on about a day-old master and a brand new ES snapshot, whatever was in master by then is what you're seeing here.

[pgayvallet]

TIL the config type is handled differently than the others. It's not properly registered from any plugin, and instead is present in the default mapping

kibana/src/core/server/saved_objects/migrations/core/build_active_mappings.ts

Lines 131 to 142 in ea7c78d

	function defaultMapping(): IndexMapping {
	return {
	dynamic: 'strict',
	properties: {
	config: {
	dynamic: 'true',
	properties: {
	buildNum: {
	type: 'keyword',
	},
	},
	},

The legacy SO service was using the root properties of the mappings as the 'types' references, therefor accessing it

const allTypes = Object.keys(getRootPropertiesObjects(mappings));

In NP, we properly check the type registry instead, where the config type is not present.

We should handle config type as any other SO type, and register it, probably from core itself.

This depends on #59291, as we need to be able to register the management section for the type.