Disable SDK from autoloading during composer execution.

[ChrisLightfootWild]

Proposal to prevent the SDK from auto-loading during composer script execution.

During a composer script, the packaged dependencies in the composer.phar are currently locked to PSR-3 v2 and thus any local application dependencies which expect v3 can trigger a fatal error.

By preventing the SdkAutoloader from being auto-loaded, we can hopefully avoid the fatal error from triggering.

Fixes #1673.

---

To test, we can perform the following actions:

make update PHP_VERSION=8.3

make bash PHP_VERSION=8.3

OTEL_PHP_AUTOLOAD_ENABLED=true composer run-script test-psr3

Before:

> OpenTelemetry\Tests\Integration\Composer\Psr3CompatabilityTest::run

Fatal error: Declaration of Psr\Log\AbstractLogger::emergency(Stringable|string $message, array $context = []): void must be compatible with Psr\Log\LoggerInterface::emergency($message, array $context = []) in /usr/src/myapp/vendor/psr/log/src/LoggerTrait.php on line 18

echo $?
255

After:

> OpenTelemetry\Tests\Integration\Composer\Psr3CompatabilityTest::run

echo $?
0

[codecov]

Codecov Report

❌ Patch coverage is 0% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 68.25%. Comparing base (ddb222d) to head (e3005fb).
⚠️ Report is 12 commits behind head on main.

Files with missing lines	Patch %	Lines
src/SDK/Common/Util/ComposerHandler.php	0.00%	7 Missing ⚠️
src/SDK/_autoload.php	0.00%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1727      +/-   ##
============================================
- Coverage     68.37%   68.25%   -0.12%     
- Complexity     2971     2974       +3     
============================================
  Files           448      449       +1     
  Lines          9020     8720     -300     
============================================
- Hits           6167     5952     -215     
+ Misses         2853     2768      -85     

Flag	Coverage Δ
8.1	68.03% <0.00%> (-0.03%)	⬇️
8.2	68.22% <0.00%> (-0.03%)	⬇️
8.3	68.22% <0.00%> (+<0.01%)	⬆️
8.4	68.23% <0.00%> (-0.02%)	⬇️
8.5	68.21% <0.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/SDK/_autoload.php	0.00% <0.00%> (ø)
src/SDK/Common/Util/ComposerHandler.php	0.00% <0.00%> (ø)

... and 216 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ddb222d...e3005fb. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[brettmc]

What would happen if you were starting your application through a composer script? eg something like composer run-my-application ?

[ChrisLightfootWild]

Previously, if you were using a compatible version of psr/log then the SDK would bootstrap.

If you were using an incompatible version, it would cause a fatal exception.

---

With the proposed changes, the SDK is essentially disabled.

[Nevay]

Suggested change

	if (getenv('COMPOSER_DEV_MODE') === false) {
	if (getenv('COMPOSER_BINARY') === false) {

COMPOSER_DEV_MODE is only set by the run-script command, running scripts directly still fails:

OTEL_PHP_AUTOLOAD_ENABLED=true composer test-psr3

Edit: checking solely for COMPOSER_BINARY will be too strict as this environment variable is also propagated to @php scripts.

[ChrisLightfootWild]

@Nevay Ah, that is unfortunate - thanks for highlighting. Realistically, there may be no safe way to do this then? 🤔

[brettmc]

Why not start with COMPOSER_DEV_MODE, since that covers some failure cases? It could be broken out into its own class+function such as ComposerHandler::isRunning() to allow for future expansion of methods to identify whether composer is running?

[ChrisLightfootWild]

I've made the suggested change to move to a ComposerHandler::isRunning() check.

I have also added an additional rudimentary check to try to infer whether or not the composer executable has been called directly.

This does fix the problem with running this way:

OTEL_PHP_AUTOLOAD_ENABLED=true composer test-psr3

Are there any foreseen problems in doing these additional checks?

[ChrisLightfootWild]

I also noted a discussion started here which links to this issue.

[bobstrecansky]

@Nevay / @brettmc - can y'all take a look at this when you get a moment?