[Spanner] v2: client-level queryOptions passed to SpannerClient are silently ignored

Open Beginner friendly
  • Is something wrong?
#9,811 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
84/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
php
Domain
backend, databases

Research direction

Start with Spanner/src/Operation.php around lines 103–109 and compare the validateOptions() calls in that file. The issue identifies the destructuring change and the affected options; check existing Spanner tests for client level options and add coverage for returnInt64AsObject and defaultQueryOptions. Done when constructor options take effect and the relevant tests pass.

Written by the indexing model from the issue text.

Description

In v2, queryOptions and returnInt64AsObject passed to SpannerClient have no effect, even though both are documented constructor options. Query-level queryOptions and the SPANNER_OPTIMIZER_* environment variables still work.

The options do reach Operation, but its constructor doesn't destructure the result of validateOptions() (Operation.php#L103-L109):

$options = $this->validateOptions(
    $options,
    ['returnInt64AsObject', 'routeToLeader', 'defaultQueryOptions']
);
// $options is [[...]] here, so all three fall back to their defaults
$this->mapper = new ValueMapper($options['returnInt64AsObject'] ?? false);
$this->routeToLeader = $options['routeToLeader'] ?? true;
$this->defaultQueryOptions = $options['defaultQueryOptions'] ?? [];

Changing this to [$options] = $this->validateOptions(...), matching the other calls in Operation.php, fixes the issue.

This looks like a regression from the v2 rewrite (#7841). In v1, client-level query options were applied in Connection\Grpc and tested in GrpcTest. Both were removed with the Connection layer.

Environment details
  • OS: Alpine Linux (Docker) + Spanner emulator
  • PHP version: 8.4.16
  • Package name and version: google/cloud-spanner v2.11.3
Steps to reproduce
  1. Create a SpannerClient with returnInt64AsObject => true.
  2. Run a query that returns an INT64.
Code example
<?php
// SPANNER_EMULATOR_HOST=localhost:9010 php repro.php
require 'vendor/autoload.php';

use Google\Cloud\Spanner\SpannerClient;

$client = new SpannerClient([
    'projectId' => 'emulator-project',
    'returnInt64AsObject' => true,
]);
$database = $client->connect('test-instance', 'test-database');

var_dump($database->execute('SELECT 1 AS x')->rows()->current()['x']);
// Expected: object(Google\Cloud\Core\Int64)
// Actual:   int(1)
Dominant language
PHP
Stars
1.2k
Forks
466
Avg merge
1d 17h
Merged PRs (30d)
40

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from googleapis/google-cloud-php

All issues in googleapis/google-cloud-php

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.