facebook-php-business-sdk

fatals: (v25.0.2) throws whenever the caller did not also call . Introduced in v25.0.2 by the new dependency (commit ). v25.0.0 and v25.0.1 are unaffected. Versions 25.0.2 1.3.1 PHP 8.5 / Composer 2.10.1 Reproducer Adding before makes the fatal go away. Cause line 28 imports and references etc. inside (lines 936-946). lives in under . The package declares PSR-4 as , which means Composer looks for the class at and can't find it. The class only becomes available as a side effect of being autoloaded — it does at the top. is instantiated only inside (). Callers that pre-populate and skip never trigger that load, and fatals on the first reference. Fix Add a autoload entry to 's : Or move to a PSR-4-compliant path. Either way becomes loadable without depending on being instantiated first. Workaround for users on v25.0.2

Summary 25.0.2 moved PII normalization out of the SDK and into . That package's 1.3.1 release ships in , which violates PSR-4 ( → , so the class must be in ). Composer can't autoload it, so any call into fatals: This makes 25.0.2 unusable for the Conversions API out of the box. Reproduction 25.0.1 works (self-contained, no dependency). Environment 25.0.2, 1.3.1, Composer 2.9.5, PHP 8.4. Root cause / fix Upstream in , filed separately: https://github.com/facebook/capi-param-builder/issues/36 Until that's fixed, 25.0.2 should either pin a fixed release or restore the bundled . Users can work around by pinning .

fails to close curl handles on PHP 8.0+, leaving TCP sockets open in for the lifetime of the PHP process. Two separate incompatibilities compound the problem: 1. returns on PHP 8.0+ because now returns a object, not a — the guard condition is never true, so the entire block is skipped 2. Even if the block were reached, is a no-op on PHP 8.0+ — the socket is only released when the object is destroyed via / GC ## Root cause ## Fix Also updates the docblock on from to . ## PHP 8.0 migration context return type changed from to object — PHP 8.0 migration guide returns for — type checks must use is now a no-op; the PHP docs recommend explicit to release the handle ## Impact In a long-running PHP CLI process (e.g. a Magento cron job), every HTTP call that ends with the remote closing the connection leaves an orphaned socket. These accumulate without bound and can exhaust file descriptors on high-uptime servers. We observed this in production with (runs every 20 minutes). A single cron process had been running for 15+ hours with open Facebook sockets visible via : ## Environment