Problem

We had a recent issue with a package where the same named variable was declared in both the package level manifest and the data stream level manifest. This was unintentional and I thought it could be an opportunity to improve package validation.

Proposed change

Add a semantic validation rule that fails when it detects variable shadowing in manifests. The rule would need to consider variables declared at the root level, policy_template level, and data stream level. It needs to take into account that variables are scoped to an input type at the policy_template level and data stream level.

Or if variable shadowing / redeclaration is an intentional feature then the spec should document the expected behavior with respect to precedence. Developers need to know which value should be passed into the Agent handlebar template.

Example of shadowing

In this hypothetical example access_key_id has been declared three times for the same data stream.

# manifest.yml
vars:
  - name: access_key_id
    type: text
    title: Access Key ID

policy_templates:
  - name: billing
    data_streams:
      - billing
    inputs:
      - type: foo/metrics
        vars:
          - name: access_key_id
            type: text
            title: Access Key ID

# data_stream/billing/manifest.yml
streams:
  - input: foo/metrics
    vars:
      - name: access_key_id
        type: text
        title: Access Key ID