Skip to content

Implement generic stripKnownOptions to restore strict validation (Breaking Change) #9379

Description

@cy-yun

Currently, Spanner\Database and Spanner\Transaction use ArrayTrait::pluckArray() to extract a hardcoded whitelist of options before passing the remainder of the request to the Operation layer.

The Problem:
Using pluckArray() as a hardcoded whitelist has two major flaws:

  1. It silently drops valid options: Every time a new GAX call option or Spanner configuration is added, it must be manually added to the pluckArray. If forgotten, valid options (like timeoutMillis) are silently dropped, causing bugs. Fix dropped options in Spanner Database and Transaction operations #9378 is planned to patch the valid options that are being dropped.
  2. It defeats strict validation: The original goal of OptionsValidator::validateOptions() in the Operation layer is to catch typos and undocumented keys by throwing a LogicException. Because pluckArray() at the Database level silently drops unknown keys, the OptionsValidator never receives the typo'd keys and cannot throw the intended exception.
    Proposed Solution:
    Instead of relying on hardcoded whitelists (pluckArray) in Database.php, we should implement a generic method (e.g., stripKnownOptions) in the global OptionsValidator (or simply use explicit unset() statements).

This allows higher-level classes like Database to explicitly strip only the specific Spanner-level keys they consume (e.g., begin, transactionType, sessionOptions). They can then safely pass the entire remaining array down to Operation.php.

Expected Outcome:

  • Valid GAX/Protobuf options will safely pass down to Operation.php without needing to be hardcoded in Database.php.
  • Unknown, undocumented, or typo'd options will also pass down to Operation.php, where they will correctly trigger the strict validateOptions() check and throw an exception.

🚨 Breaking Change Notice 🚨
This is a breaking change and must be slated for a major version update. By removing the silent dropping of unknown keys in Database.php, we are restoring strict validation. Any users who are currently passing undocumented or typo'd keys (which were previously silently ignored) will begin encountering LogicExceptions upon upgrading.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions