Skip to content

Oracle 19c: add a guard test that validateOracleOptions log-export allowlist == embedded baseline 'supported' set #546

Description

@wz-gsa

Context

In #537, the Oracle create/update parameter allowlist (validateOracleOptions in services/rds/validate.go) originally duplicated the RDS Oracle supported log-export set as a hand-maintained Go literal ([alert, audit, listener, trace, oemagent]), separate from the embedded baseline services/rds/baselines/oracle19c/log_exports.yml supported: list.

A hostile self-review flagged this as a drift risk: if someone edits log_exports.yml supported (e.g. RDS adds a new export type) without updating the Go literal, the two silently diverge and a customer request for the new type is rejected even though the baseline claims support.

Done in #537

Changed validOracleLogExports() to derive the allowlist from loadOracleLogExports().Supported (fail-closed on load error), so there is a single source of truth. This removes the duplication.

Remaining (this issue)

Add a small unit test asserting the invariant explicitly, so a future refactor that reintroduces a hardcoded list can't silently drift:

  • default_exports is a subset of supported (you can't default-enable an unsupported export), and
  • every value the create path passes through to EnableCloudwatchLogsExports is a member of supported.

Small, no behavior change — purely a regression guard. Relates to #527 (log-export baseline).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions