Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Runtime errors thrown in aliases.php under PHP8+ #91

Open
javiermarinros opened this issue Apr 25, 2022 · 16 comments
Open

Runtime errors thrown in aliases.php under PHP8+ #91

javiermarinros opened this issue Apr 25, 2022 · 16 comments

Comments

@javiermarinros
Copy link
Contributor

A runtime error is thrown for most of class alias defined in src/aliases.php of this kind:

Cannot declare class google\appengine\api\modules\InvalidModuleStateException, because the name is already in use

Given that PHP namespaces are case-insensitive, most of the alias defined there are not necessary, as the old php55 sdk names are case-insensitive equal to the php7+ SDK.

@javiermarinros javiermarinros changed the title Runtime errors thrown in aliases.php Runtime errors thrown in aliases.php under PHP8+ Aug 5, 2022
@javiermarinros
Copy link
Contributor Author

@zachluna @pmaloogoogle would you take a look at this, please?

@jinglundong
Copy link
Contributor

Thanks for reporting this issue, @javiermarinros!

Do you mind helping us understand this issue further? aliases.php was used by the autoload. Does it mean the whole autoload functionality is broken? Are theses aliases unnecessary or blocking the common usage of this SDK?

Seems like we are missing test coverage on the use cases that could trigger this error. Do you have any recommendation about reproducing this issue, so we could add tests?

@javiermarinros
Copy link
Contributor Author

Hi @jinglundong, thank you for your help

You can replicate this error deploying a test php project into AppEngine with this setup:

app.yaml

runtime: php81
app_engine_apis: true

entrypoint: serve app.php

handlers:
  - url: .*
    script: auto

app.php

<?php

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(-1);

set_error_handler(
    static function (int $severity, string $message, string $file, int $line, mixed $context = null): bool {
        echo '<pre>'.print_r(func_get_args(), true).'</pre>';
        return true;
    },
    error_reporting()
);
set_exception_handler(
    static function (Throwable $exception) {
      echo '<pre>'.print_r($exception, true).'</pre>';
    }
);

require 'vendor/autoload.php';

echo "Load done\n";

The issue can be resolved by two approaches:

  • Remove unnecessary aliases, as most of them try to alias a class that is case-insensitive equal to the original one, and PHP can handle namespace and class names in a case-insensitive way. This would have better performance as it will reduce unnecessary class_alias invocations. This would leave alias.php like this:
$classMap = [
    'Google\AppEngine\Api\AppIdentity\AppIdentityService' => 'google\appengine\api\app_identity\AppIdentityService',
];

foreach ($classMap as $class => $alias) {
    @class_alias($class, $alias);
}

  • The other method would be checking if the alias class exists before aliasing, but it doesn't make much sense to try to alias already existing classes in every request:
foreach ($classMap as $class => $alias) {
    if (!class_exists($alias, false)) {
        class_alias($class, $alias);
    }
}

I hope this info can help you.

@jinglundong
Copy link
Contributor

Thanks for the detailed explanation and suggestions! I agree with your analysis and would prefer removing the unnecessary aliases as well. I don't see any down sides of this approach.

From my reading of https://www.php.net/manual/en/language.namespaces.rationale.php, I believe namespaces are case-insensitive for all the php versions (that GAE supports). So, we don't need to worry about causing problems in specific php versions.

Sorry for the late response, since I've been out of the office in the past two weeks. I will try to run your sample and probably send out a PR next week.

@javiermarinros
Copy link
Contributor Author

Hi @jinglundong have you had time to prepare the PR? Thank you.

@jinglundong
Copy link
Contributor

Sorry, I totally dropped the ball. I will give it another shot this week.

@jinglundong
Copy link
Contributor

I started the fix, but got delayed by a high severity CVE. Will continue the work next week. Sorry for all the delays.

@javiermarinros
Copy link
Contributor Author

It's okay, thank you for the help!

@javiermarinros
Copy link
Contributor Author

Hi @jinglundong do you have any news about this fix?

@jinglundong
Copy link
Contributor

Sorry that I dropped the ball. I'm proposed a fix as suggested at #95.

@javiermarinros
Copy link
Contributor Author

Thank you! I also proposed a fix with several more fix for PHP 8 compatibility issues and some unused dependencies removals at #94

@jinglundong
Copy link
Contributor

I approved and merged #94. I think the next step is to tag it as 2.1.1.

@jinglundong
Copy link
Contributor

PHP 8.1 tests are failing after #94. Sending out a revert PR for review at #96.

@SimoTod
Copy link

SimoTod commented Apr 20, 2023

We have the same issue, when using this dependency, we get a lot of noise in our logs. Do you have any plans for merging #95? Thanks

@jinglundong
Copy link
Contributor

jinglundong commented Apr 21, 2023

That's a fair question. I will context switch back to this and fix it. One challenge I/we have is that we need to keep this Github Repo and Google's internal code base in sync. I will investigate and discuss with my teammates.

@jinglundong
Copy link
Contributor

Monty, let's talk about this offline when you have time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants