Soap Recorder Bundle Laravel Package

Technical Evaluation

Architecture fit

• Wrong framework, right pattern. liip/soap-recorder-bundle ships a Symfony Bundle class, a DI extension, and XML/YAML service definitions. Laravel's container consumes none of these — no service provider, no auto-discovery, no Laravel config surface. The design (decorate the SoapClient, key a fixture by request hash, replay thereafter) is exactly what our test suite needs; the packaging is unusable as-is.
• The interception point is the \SoapClient transport boundary. That is a clean seam — but it is the bundle's seam, not ours. Laravel has no first-class SOAP abstraction, so our real seam is either a hand-rolled ext-soap wrapper or a third-party SDK's internal client. Any recorder must sit under that, which means writing our own decorator regardless.
• Net: the only thing this package gives a Laravel team is a reference implementation of a ~200–400 LOC idea, delivered inside ~all DI glue.

Integration feasibility

• Technically installable (plain PHP + ext-soap underneath) but not productively integrable. Composer resolution against Laravel 10/11 will almost certainly fail on Symfony/PHP constraints, forcing --ignore-platform-reqs or a fork-and-patch — permanent tax on a test-only utility with a low ROI bar.
• Even if it installed, we would be vendoring an archived bundle to obtain one recorder class. That is strictly worse than owning the class.

Technical risk

• Archived and explicitly [DEPRECATED], 12 stars, 0 dependents. No security patching, no PHP 8.x/ext-soap fixes, no handling of typed SOAP objects, fault responses, or WSDL drift.
• Secret capture is the headline risk. SOAP headers routinely carry credentials, tokens, and PII; the bundle's default behaviour writes request/response pairs to fixture files that get committed. A TPM signing off on adoption is implicitly signing off on a data-handling control that does not exist.
• Score 0.14 is a do-not-adopt signal, not a stylistic complaint. Test infrastructure gates the correctness of every merge; archived code in that position is an unpriced liability.

Key questions

1. Which SOAP endpoints do we call, through which client, and is that seam an interface we own or a vendor SDK's?
2. Would HTTP-layer record/replay (php-vcr, or Laravel's Http::fake() if SOAP rides Guzzle) cover the need without touching SOAP at all?
3. Are fixtures committed and code-reviewed, or generated per-run? Who owns header/payload redaction, and where is it enforced?
4. How volatile are the upstream WSDLs? High churn turns replay fixtures into false confidence.
5. Is there a maintained successor or a credible maintained fork, or is this genuinely orphaned?

Integration Approach

Stack fit

• Poor as a dependency, good as a design reference. Preferred order: (1) HTTP-layer VCR if SOAP is HTTP-observable; (2) a thin in-house SoapClient decorator behind an interface we own; (3) this bundle — only if the application is Symfony 2/3, which it is not.
• The reusable asset is the contract: record-once/replay-thereafter, fixture keyed by method + normalized arguments, explicit record / replay / passthrough modes.

Migration path

• Do not vendor. Extract the design and implement it in-repo. Size it honestly at 200–400 LOC plus fixture-directory conventions and a redaction step — cheaper to own than a patched fork, and legible to the whole team.
• Keep production bindings untouched: the recording client implements the same interface as the production client and is bound only in the test container.

Compatibility

• Expect Symfony 2/3-era constraints and a PHP ceiling below current runtimes. ext-soap becomes a hard CI dependency — verify it in every build image, including Paratest workers.
• Fixture matching must be deterministic: strip timestamps, nonces, and message IDs from the request key or replay will miss under load.

Sequencing (TPM decision gates)

1. Inventory SOAP calls and map each to its client seam; flag which have no test coverage today. Gate: is the problem worth solving at all?
2. Spike HTTP-layer VCR against one representative endpoint. Gate: is SOAP-layer recording even necessary? Timebox: half a day.
3. Implement the decorator behind an interface only if step 2 fails. Gate: approve 1–2 engineer-days.
4. Fixture hygiene before the first recorded run — redaction rules, directory layout, review policy, pre-commit secret scanning.
5. Wire CI to replay-only, plus a scheduled job that re-records against sandbox to catch upstream drift.

Operational Impact

Maintenance

• Zero upstream. Every bug, compatibility break, and runtime upgrade is ours. Deprecation compounds this: each PHP/ext-soap bump re-opens the fork question. A small in-house recorder has lower total cost of ownership than a patched archive because the surface is small and ours.

Support

• No maintainer, no issue activity, no community corpus. Support is internal documentation plus the one engineer who ran the spike. 12 stars / 0 dependents means troubleshooting is first-principles — factor that into on-call expectations for flaky-test triage.

Scaling

• Fixtures grow monotonically and SOAP XML is not diff-friendly. Past a few hundred cases, plan an artifact store or a separate fixtures repo.
• Paratest workers can collide writing the same fixture path — recording must be single-writer or namespaced per worker.
• Repository bloat and review fatigue are real: large XML fixtures get rubber-stamped in PRs, which quietly erodes the value of review.

Failure modes

• Fixture drift — upstream contract changes, recordings still pass, tests go green while production breaks. Mitigate with scheduled re-record against sandbox.
• Stale fixtures masking regressions — replay hides client-side serialization bugs because the request never leaves the process.
• Secret leakage — credentials/PII in SOAP headers committed to git. Highest-severity risk; requires pre-commit scanning and a documented redaction owner.
• Replay miss → silent passthrough to a live endpoint from CI, producing flakiness or unintended writes. Passthrough must be explicitly disabled in CI.
• Filesystem failures — permissions/disk in containers surface as opaque errors mid-suite.

Ramp-up

• Conceptually trivial: engineers grasp record/replay in an hour.
• The organizational ramp is the real cost — every new hire will ask why an archived, deprecated Symfony bundle sits in a Laravel codebase, and that question has no good answer. Budget half a day for the spike, one to two days for a clean implementation plus fixture policy, and a short ADR recording the build-not-buy decision so the question is answered once.

TPM recommendation: Do not adopt as a dependency. Leverage it as (a) evidence in the build-vs-buy record, (b) a reference specification for the ~200–400 LOC decorator we own, and (c) the framing for a scoped spike — "deterministic SOAP fixture replay in N days." Publish the decision and the fixture-hygiene policy alongside the code so the archived-bundle question never gets re-litigated.