src/data/manifest.json is missing from build artifacts

[fieryprophet]

Describe the bug

src/data/manifest.json is not being included with the build artifacts which results in the following error on use:

File not found: /vendor/aws/aws-sdk-php/src/data/manifest.json {"exception":"[object] (InvalidArgumentException(code: 0): File not found: /vendor/aws/aws-sdk-php/src/data/manifest.json at /vendor/aws/aws-sdk-php/src/functions.php:160)

Expected Behavior

manifest.json would load properly.

Current Behavior

As manifest.json is missing the loader fails and the SDK is unusable.

Reproduction Steps

Any operation using the SDK from one of the latest build artifacts will result in this error if they fail to resolve the compiled mainfest.json.php artifact that is included in the build artifacts.

Possible Solution

Include manifest.json in the build artifact.

Additional Information/Context

No response

SDK version used

3.285.4

Environment details (Version of PHP (php -v)? OS name and version, etc.)

PHP 8.2 under Windows 11/WSL2

[SamRemis]

Hi @fieryprophet,

Chiming in while investigating another issue that I think may be related. If I download the zip for the latest SDK version, I see that manifest.json file is present in the archive. There is an issue that's currently surfacing with one of our dependencies latest version and WSL2. If you're able, could you tell me if 3.283.11 is the first version that broke and you can successfully install 3.283.10?

[fieryprophet]

I'll take a look, but I am also noticing that it's supposed to first attempt to use /src/data/manifest.json.php which is included in the artifact (and should therefore be working in my case) but for some reason the is_readable() check for that file is failing (WSL2 bug maybe? Permission issue? idk) and then the fallthrough does not find the original manifest.json file, hence the error.

So I can see why for the vast majority of people they haven't encountered this bug if it the compiled version is part of the artifacts, but it obviously makes the fallback redundant if there is no fallback file included in the artifact. And there's still the issue with the compiled version not being resolved in my case.

[fieryprophet]

@SamRemis 3.283.10 is still missing src/data/manifest.json in the build artifact and I get the same error when testing it.

[SamRemis]

Thank you, can you tell me what your install method is? Are you using the artifacts released via the github releases? Using composer?

[fieryprophet]

Installing via composer 2.6.5

[fieryprophet]

I am beginning to think the is_readable() check failing is just some wonkiness between WSL2 and how it resolves UNC paths (long story, running a WSL2-based project via PHP on Win to get around the queue worker not talking to Stable Diffusion on Windows) which I can bypass, but exposed this issue as a side effect.

[fieryprophet]

Just to further clarify, Composer is pulling release 3.284.5 from https://api.github.com/repos/aws/aws-sdk-php/zipball/c462af819d81cba49939949032b20799f5ef0fff and if you download that zip you will see it definitely does not include src/data/manifest.json

[SamRemis]

The manifest.json file doesn't exist in the artifacts, but that's expected; we only bundle the manifest.json.php.

Steps I took to try to reproduce:

1. I downloaded it from the releases page here, where the file existed
2. I tried the link above where it exist as well
3. I then tried moving to my machine with WSL2, creating an empty composer project, and running composer require aws/aws-sdk-php. From there, I checked that the file was in vendor/aws/aws-sdk-php/src/data/manifest.json.php and then ran a sanity check by creating an s3 client and calling listBuckets(). Everything worked as expected.

Do you mean that it's just missing manifest.json but manifest.json.php is present?

[fieryprophet]

The manifest.json file doesn't exist in the artifacts, but that's expected; we only bundle the manifest.json.php.

Steps I took to try to reproduce:

1. I downloaded it from the releases page here, where the file existed
2. I tried the link above where it exist as well
3. I then tried moving to my machine with WSL2, creating an empty composer project, and running composer require aws/aws-sdk-php. From there, I checked that the file was in vendor/aws/aws-sdk-php/src/data/manifest.json.php and then ran a sanity check by creating an s3 client and calling listBuckets(). Everything worked as expected.

Do you mean that it's just missing manifest.json but manifest.json.php is present?

Correct the json.php file exists but .json does not. Why the fallback if that file is not included in the builds?

[yenfryherrerafeliz]

Hi @fieryprophet, I agree that it should not fallback to check if that file exists when it will not exists, however, I think that what may be causing this issue at your end is that the context from where your code is being ran does not have enough permissions to read the compiled file. The reason why I think that is the problem is because if you check the implementation here, you will see that it checks for if that compiled file is able to be read, and if not then is when it fall back to where is failing.
So, could you please do the following:
Assuming that it fails when doing a S3 request.

• Can you please go to your vendor folder and check that the following path exists:
  • "aws/aws-sdk-php/src/data/2006-03-01/api-2.json.php"

And if it exists then, you may need to check your permissions.

I look forward to your response.

Thanks!

[fieryprophet]

@yenfryherrerafeliz Yeah, I resolved my triggering issue by calling the AWS code from within the WSL2 context instead of externally via a UNC path. However I definitely feel the fallback code for this issue needs addressing if the expected .json file isn't present in the build for the to actually use when the compiled version is inaccessible for some reason.

[yenfryherrerafeliz]

Hi @fieryprophet, thanks again for reporting this. We have added an item to our backlog so we can revisit this in the future, with the purpose of improving the handling or the message we provide so it can be more clear for when the compiled file can't be read in that function.

I will close this issue now but please feel free of opening a new issue for anything you get that we can help you with.

Thanks!

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[SamRemis]

Also I apologize for the slow response here; the fallback predates me, so I can't say for sure, but my best guess as to the reason it's there is for ease of development. If you pull/fork the SDK from GitHub, then it will give you both the .json and the .json.php files. If you need to modify one of them, it's much simpler to modify a json file than it is to modify a compressed PHP array. You can just delete the .json.php file, edit the .json file as needed and instantly see the changes reflected in the SDK.