DEV Community: Ahmed Elkholy

Test a committed Laravel webhook whose acknowledgement was lost

Ahmed Elkholy — Tue, 27 Oct 2026 14:00:00 +0000

The webhook committed. The sender never received the acknowledgement. Now it retries.

That is different from a handler that failed and rolled back. If you test only exceptions inside the handler, you can miss the successful-commit/uncertain-delivery boundary.

If your only test throws inside the handler, it may never exercise the successful-commit/uncertain-delivery boundary. A recovery test should state both the delivery observation and the business invariant.

I maintain Laravel FailureLab, an MIT, test-only package for named fault injection and bounded sequential replay. Its public runner is in-process, not a distributed network simulator.

Install in the test application

composer require --dev mykholy/laravel-failurelab:^1.2

Use PHP 8.3+, Laravel 12/13, APP_ENV=testing and disposable storage. Do not run replay tests against real payment providers.

Model successful commit with a lost acknowledgement

The following method belongs in a Laravel feature-test class. It creates test-only tables in a fresh disposable database. The unique event identity and transaction belong to the example application, not FailureLab.

use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Schema;
use Mykholy\FailureLab\FailureLab;

public function test_ack_loss_preserves_one_local_effect(): void
{
    Schema::create('processed_events', function (Blueprint $table): void {
        $table->string('event_id')->primary();
    });
    Schema::create('ledgers', function (Blueprint $table): void {
        $table->id();
        $table->string('event_id')->unique();
    });

    $handler = static function (): void {
        DB::transaction(static function (): void {
            $new = DB::table('processed_events')->insertOrIgnore([
                'event_id' => 'evt_synthetic_123',
            ]);
            if ($new === 1) {
                DB::table('ledgers')->insert(['event_id' => 'evt_synthetic_123']);
            }
        });
    };

    FailureLab::replay('commit, first ack lost')
        ->times(3)
        ->loseAcknowledgementOn(1)
        ->run($handler)
        ->assertDeliveries(3)
        ->assertAllCompleted()
        ->assertAcknowledgementPlanSatisfied()
        ->assertAcknowledgedAfterLoss();

    $this->assertDatabaseCount('processed_events', 1);
    $this->assertDatabaseCount('ledgers', 1);
}

Do not create these tables twice if your test migrations already own them. This demonstrates one already verified synthetic event. Real endpoints need separate signature and tenant-isolation tests.

times(3) explicitly requests three callback invocations. loseAcknowledgementOn(1) records loss only after that callback completed. No packet is dropped and no queue delivery is scheduled. The plan assertion prevents a callback failure from accidentally satisfying the successful-handler loss scenario.

The second image isolates ordinary duplicate-delivery replay; the full example above also injects the lost acknowledgement. Both need an application-owned idempotent handler.

The database count is the business invariant. Successful callbacks alone do not establish deduplication. Removing the insertion guard may produce a later constraint error, or duplicates without a unique key. Neither is equivalent to completing all deliveries with one intended effect.

Inject an interruption at a named seam

For an application-owned checkout adapter, put a checkpoint after fake-provider acceptance and before local finalization:

$report = FailureLab::scenario('accepted before local completion')
    ->interruptOnceAt('provider.accepted')
    ->attempts(2)
    ->run(function ($checkpoint) use ($checkout): string {
        $reference = $checkout->captureUsingFakeGateway('order-42');
        $checkpoint->hit('provider.accepted');
        $checkout->markPaid('order-42', $reference);
        return $reference;
    });

$report->assertFaultPlanSatisfied()->assertCompleted();

This is an integration sketch: supply the checkout service and a fake gateway with stable provider idempotency. Then assert one accepted capture and the correct local order state. FailureLab does not make an unsafe checkout idempotent.

The plan assertion catches a renamed or unreachable seam. The completion assertion proves the callback eventually returned. Neither replaces your business invariant.

Separate replay, concurrency and process death

Sequential replay is not a race test. Use independent workers and real SQL integrations for competing claims. The repository has a separate Linux SIGKILL drill; that is not a feature of the public Scenario API. An exception cannot reproduce every process-death boundary.

Start with one recovery boundary, a synthetic provider and an explicit invariant. Quickstart, fake provider, runnable example and limitations.

*Visuals: AI-generated editorial artwork; copyable implementation code remains in the article.

Disclosure: Generated by an autonomous AI agent and checked against package source and existing examples. Adapted snippets were not freshly executed during preparation.*

Test the JSON your Laravel API actually sends for accidental secret exposure

Ahmed Elkholy — Fri, 23 Oct 2026 14:00:00 +0000

Your API test passes. The response still contains an API key.

A 200 status and the expected JSON shape do not establish that the response is safe to expose. A serializer refactor or a new settings property can introduce a sensitive field without breaking either assertion.

Explicit API Resources and model hiding rules are a good start. A response-level regression assertion checks the output after those mechanisms run.

I maintain Laravel LeakProof for this boundary. It inspects selected sensitive field names and recognizable credential patterns. It does not contact providers to validate keys.

Install and add the assertion trait

composer require --dev mykholy/laravel-leakproof:^1.1

Supports Laravel 12/13. The package's PHP constraint starts at 8.2; Laravel 13 requires 8.3+. Deployed middleware needs the package outside require-dev deliberately.

This test-only route uses synthetic content and should make the assertion fail:

<?php
namespace Tests\Feature;

use Illuminate\Support\Facades\Route;
use Mykholy\LeakProof\Testing\Concerns\AssertsNoSensitiveData;
use Tests\TestCase;

final class IntegrationSettingsLeakTest extends TestCase
{
    use AssertsNoSensitiveData;

    public function test_settings_do_not_expose_credentials(): void
    {
        Route::get('/_test/settings', static fn () => response()->json([
            'data' => ['settings' => ['openaiApiKey' => 'synthetic-example']],
        ]));

        $response = $this->getJson('/_test/settings');
        $response->assertOk();
        $this->assertNoSensitiveData($response);
    }
}

Replace the response with a safe public representation, such as ['data' => ['configured' => true]], and rerun. In a real integration, change the Resource/controller serializer rather than filtering only a fixture. This is an expected red/green demonstration, not a claim of a freshly executed host test.

Apply the same check to your endpoint

The image shows a shorter application-endpoint variant. Import Tests\TestCase, authenticate an authorized caller, and adapt /api/settings to your application. Keep the synthetic route above for an isolated detector demonstration.

Field detection is different from value detection

A name such as openaiApiKey is a strong signal even with a placeholder value. A credential embedded inside a generic string needs a recognizable value pattern. Selected AI-provider formats are supported; unknown or future formats are not universally recognizable.

Diagnostics show sanitized JSON paths and rule identifiers without printing the secret. Unknown object-key names are sanitized too, to avoid leaking personal data through test failures. Never add real credentials to fixtures to exercise a detector.

Intentional tokens need precise exceptions

A login endpoint can intentionally return a token to an authorized caller:

$this->assertNoSensitiveData($response, ['data.access_token']);

An exception grants permission to the selected subtree. Keep it narrow and reviewed. A one-segment wildcard can suit a known list, but allowing every token-like field can hide a regression. Authorization tests must still establish who can receive that response.

Scan local JSON fixtures

Save synthetic JSON in leakproof-sample.json:

{"data":{"user":{"name":"Example User","password":"example-only"}}}

Run inside the Laravel application:

php artisan leakproof:scan leakproof-sample.json --format=json

A finding or incomplete traversal returns 1; clean inspection returns 0; invalid/unreadable input returns 2. Output contains sanitized paths and rules. The command reads local files, not remote APIs.

Incomplete must not mean clean

The documented defaults include maximum depth 32, 50,000 nodes, 100 findings and 2 MiB JSON input. Exceeding inspection limits is inconclusive rather than successful. Review those budgets with realistic fixtures.

Middleware is opt-in and off by default. Report mode logs sanitized findings; block mode can reject legitimate token responses if exceptions are wrong. Test selected staging routes first.

Limits

Unknown patterns, encoded values and authorization mistakes may escape detection. Emails, phone numbers and other personal information are not automatically classified as secrets. Streams, HTML and downloads are outside JSON inspection. Keep policies, data minimization and explicit serializers; LeakProof adds one focused regression signal.

Installation, supported detection rules and examples. MIT licensed.

*Visuals: AI-generated editorial artwork. Use the copyable code examples for implementation.

Disclosure: This article was generated by an autonomous AI agent, checked against package source and documentation. Adapted examples were not freshly executed during preparation.*

A Laravel 403 test can pass after an unauthorized database write

Ahmed Elkholy — Tue, 20 Oct 2026 14:00:00 +0000

Your authorization test is green. The endpoint returns 403 Forbidden. But did the database stay unchanged?

A denied response proves what the client received. It does not prove what the application did before returning it.

The false-green test

Consider this deliberately incorrect controller fragment:

$order->update(['status' => $request->string('status')->toString()]);
Gate::authorize('update', $order);

If authorization rejects the caller after the update commits, a test that checks only assertForbidden() can still pass. The application returned the expected status and changed a record the caller had no right to change.

The application fix is to authorize before writing. The regression test should preserve both requirements: deny the caller and leave the relevant persisted state unchanged.

Install the test helper

I maintain Laravel AccessProof, an MIT package that combines real in-process Laravel HTTP feature-test requests with explicit database watches.

composer require --dev mykholy/laravel-accessproof:^1.2

It supports Laravel 12/13 and PHP 8.3+. Use APP_ENV=testing and a disposable database. An environment guard cannot prove your configured database is safe.

Watch the state a denied caller must not change

In your Laravel feature test, create an owner, outsider and order using your existing factories. This example assumes your application has tenant_id and status fields and a PATCH order endpoint; adapt them to your domain.

use Mykholy\AccessProof\AccessProof;

AccessProof::request($this)
    ->as($outsider)
    ->watch($order, ['tenant_id', 'status'])
    ->patchJson(
        '/api/orders/'.$order->getKey(),
        ['status' => 'paid'],
    )
    ->send()
    ->assertForbidden()
    ->assertUnchanged();

Take the snapshot before send(). The package reads the persisted watched row after the request without relying on an Eloquent tenant scope that might hide it. Updating or deleting that row fails the unchanged assertion. It does not snapshot every table.

With the incorrect controller, the status assertion can pass while the unchanged assertion fails. After moving authorization before the update, both should pass. That is the expected demonstration, not a claim that an arbitrary host application has been tested.

Give denial tests a positive control

For sensitive reads, 404 creates another false-green possibility: perhaps the URI does not exist. Some apps deliberately return 404 for inaccessible records. Rejecting every 404 is not the solution.

Verify that the same URI works for the owner, then deny the outsider:

AccessProof::compareRead($this)
    ->owner($owner)
    ->outsider($outsider)
    ->getJson('/api/orders/'.$order->getKey())
    ->withoutBodyMarker('ACCESSPROOF_TEST_SECRET_42')
    ->verify();

Seed the protected resource with that synthetic marker. Never use a real credential or customer identifier. The paired check expects an allowed owner response and denied outsider response from the same GET endpoint. Authentication remains application-owned; the outsider stays authenticated afterward, so keep guest scenarios in separate methods.

Counts cannot detect every replacement

For a denied POST, watchCount('orders', ['tenant_id' => $targetTenantId]) detects a net count change. A delete followed by an insert may keep the same count. For that boundary, use a bounded row watch:

AccessProof::request($this)
    ->as($outsider)
    ->watchRows('orders', ['tenant_id' => $targetTenantId], ['status', 'total'])
    ->postJson('/api/orders/batch-action')
    ->send()
    ->assertDenied()
    ->assertUnchanged();

The predicate is required. The default bound is 500 matching rows and the default identity column is id. Narrow the rows and columns to your business invariant. This checks final state in that set, not every transient operation.

What this does not establish

AccessProof does not discover routes or enforce policies. You supply meaningful actor/resource/action combinations. It does not observe email, remote APIs, queued jobs, filesystem writes or unwatched databases. A temporary mutation that is later reversed may escape final-state comparison. Add your application's assertions for those effects.

The repository includes an anonymized maintainer-reported SaaS field report. Its host app is private; that is supporting context, not independent public replication or security certification.

Start with one denied write and assert the state it must preserve. Installation, API reference and limitations.

*Visuals: AI-generated editorial artwork; copyable code is included below each visual.

Disclosure: Prepared with AI assistance and checked against package documentation and source APIs. Application-specific examples require adaptation and execution in your test environment; these adapted snippets were not freshly executed during preparation.*