x-pack/platform/plugins/shared/streams/server/plugin.ts (1)

275-324: ⚠️ Potential issue | 🟠 Major

Validate unsupported alerting config before using the fake RulesClient.

This startup path casts a three-method stub to RulesClient, so unsupported rules/queries only fail once the preconfiguration sync is already running. If reconciliation touches any other RulesClient member, bootstrap can die mid-sync with a generic runtime error. Reject those shapes before enableStreams/bulkUpsert, and make the fallback client throw a descriptive error for any accessed member.

Run the following script to verify which RulesClient members the streams code can hit and whether the preconfigured path rejects unsupported config before side effects begin:

#!/bin/bash
set -euo pipefail

echo "RulesClient member usage under streams:"
rg -n --type=ts -C2 '\brulesClient\.[A-Za-z_][A-Za-z0-9_]*\b' \
  x-pack/platform/plugins/shared/streams/server/lib/streams \
  x-pack/platform/plugins/shared/streams/server/plugin.ts

echo
echo "Preconfigured startup branch:"
sed -n '266,329p' x-pack/platform/plugins/shared/streams/server/plugin.ts

Expected result: only members intentionally supported by the stub are reachable, and unsupported rules/queries are rejected before bulkUpsert starts. As per coding guidelines, "avoid any and unknown."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@x-pack/platform/plugins/shared/streams/server/plugin.ts` around lines 275 -
324, The current stubbed RulesClient (the object cast to RulesClient) only
implements bulkGetRules/create/update and is used when building
attachmentService.getClient, queryService.getClient and
streamsService.getClient, which risks runtime failures during
streamsClient.enableStreams or streamsClient.bulkUpsert; instead, validate the
preconfigured.rules/queries shapes up-front (before calling enableStreams or
bulkUpsert on streamsClient) and replace the stub with a defensive proxy that
throws a clear, descriptive Error for any accessed/unimplemented member; locate
the RulesClient stub in plugin.ts, add a validation step that inspects
this.config.preconfigured.stream_definitions (and any rules/queries entries) and
rejects invalid shapes before constructing
attachmentClient/featureClient/queryClient, and implement the fallback
RulesClient as a Proxy or wrapper that throws "Unsupported RulesClient method:
<methodName>" for any property access other than the explicitly supported
methods (bulkGetRules, create, update).

x-pack/platform/plugins/shared/streams/common/config.ts (1)

14-14: Prefer a typed schema over schema.any() for stream_definitions.

Using schema.any() bypasses config validation entirely, allowing malformed stream definitions to slip through until runtime. Since stream definitions have a known structure (per PR notes requiring "full definitions" for nested items), consider defining a proper schema—even a minimal one—to catch configuration errors at startup.

If the shape is intentionally flexible during this initial implementation, at minimum document the expected structure inline or consider marking this configuration as experimental/tech preview.

As per coding guidelines: "Use TypeScript for all new code; avoid any and unknown."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@x-pack/platform/plugins/shared/streams/common/config.ts` at line 14, Replace
the untyped schema.any() used for stream_definitions with a concrete schema that
enforces the known stream definition shape: change stream_definitions to
schema.arrayOf(schema.object(...)) and validate required top-level properties
(e.g., id/name/type as strings, an optional description, and a nested items
array/object with its own minimal schema) so malformed configs fail at startup;
update the symbol stream_definitions in config.ts and add inline comments
documenting the expected fields and mark it experimental if the shape may
change.

x-pack/platform/plugins/shared/streams/server/lib/streams/state_management/execution_plan/translate_classic_stream_pipeline_actions.test.ts (1)

37-50: Add one regression case for the internal-user client path.

These tests still exercise the helper through asCurrentUser, so they don't pin the startup path this refactor adds. Switching one happy-path case to asInternalUser would make it much harder to accidentally reintroduce a request-scoped assumption later.

🧪 Minimal test tweak

-      clusterClient.asCurrentUser.indices.getIndexTemplate.mockImplementationOnce(async () => ({
+      clusterClient.asInternalUser.indices.getIndexTemplate.mockImplementationOnce(async () => ({
         index_templates: [
           {
             name: 'my-template',
             index_template: {
               composed_of: [],
               index_patterns: 'my-*',
             },
           },
         ],
       }));

-      await translateClassicStreamPipelineActions(actionsByType, clusterClient.asCurrentUser);
+      await translateClassicStreamPipelineActions(actionsByType, clusterClient.asInternalUser);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams/server/lib/streams/state_management/execution_plan/translate_classic_stream_pipeline_actions.test.ts`
around lines 37 - 50, Add a regression test that exercises the internal-user
code path by calling translateClassicStreamPipelineActions with
clusterClient.asInternalUser instead of asCurrentUser; specifically, duplicate
the existing happy-path setup (mocking
clusterClient.asInternalUser.indices.getIndexTemplate to return the same
index_templates payload) and invoke
translateClassicStreamPipelineActions(actionsByType,
clusterClient.asInternalUser) so the test covers the internal-user client path
and prevents reintroducing request-scoped assumptions in
translateClassicStreamPipelineActions.