fix(workflows): Remove server-side defaults from generated Elasticsearch Zod schemas

[shahargl]

Summary

Fixes an issue where elasticsearch.esql.query workflow steps fail with:

verification_exception: Both [include_execution_metadata] and [include_ccs_metadata] query parameters are set. Use only [include_execution_metadata]

close https://github.com/elastic/security-team/issues/14967

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 7e9c8e9

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
workflowsManagement	4.2MB	4.1MB	-6.3KB

[Copilot]

Pull request overview

This PR fixes a bug in Elasticsearch workflow steps where mutually exclusive query parameters (include_ccs_metadata and include_execution_metadata) were both being sent to Elasticsearch, causing verification exceptions. The fix prevents server-side defaults (marked with @server_default in the Elasticsearch specification) from being applied in the generated Zod schemas.

Key changes:

• Added logic to identify and remove server-side defaults from OpenAPI specs before Zod schema generation
• Added comprehensive test coverage to verify the fix prevents default values from being applied
• Integrated the server defaults removal into the OpenAPI preprocessing pipeline

Reviewed changes

Copilot reviewed 4 out of 6 changed files in this pull request and generated 3 comments.

File	Description
es_server_defaults.test.ts	Adds tests verifying that server-side defaults are not applied by Zod schemas for mutually exclusive ES
oas_remove_server_defaults.ts	Implements logic to parse elasticsearch-specification schema.json and remove default values for fields marked with @server_default
index.ts	Exports the new createRemoveServerDefaults function
openapi_ts.config.ts	Integrates server defaults removal into the OpenAPI preprocessing pipeline

[Copilot]

The function doesn't handle potential errors from file reading or JSON parsing. If schemaPath is invalid or the file contains malformed JSON, the error message will be generic and unhelpful. Consider wrapping in a try-catch block with a descriptive error message that includes the schema path.

Suggested change

	const schema = JSON.parse(fs.readFileSync(schemaPath, 'utf8'));
	let schema: unknown;
	try {
	schema = JSON.parse(fs.readFileSync(schemaPath, 'utf8'));
	} catch (err) {
	throw new Error(
	`Failed to read or parse schema file at "${schemaPath}": ${(err instanceof Error ? err.message : String(err))}`
	);
	}

[Copilot]

[nitpick] The function name findServerDefaults suggests it returns something, but it has a void return type and operates via side effects on serverDefaultFields. Consider renaming to collectServerDefaultFields or extractServerDefaultFields to better convey its side-effect behavior.

[Copilot]

If ES_SPEC_SCHEMA_PATH points to a non-existent or malformed file, the error won't be caught here and will propagate during the reduce operation with unclear context. Consider validating the path exists before passing it to createRemoveServerDefaults or wrapping the reduce operation in error handling with a descriptive message.

[Kiryous]

Nice catch. LGTM!

There's a room to refactor the parsing and accessing schema.json and OpenAPI spec, but maybe let's leave it for a subsequent effort.