Potential bug - error 404, no query results for model [Spatie\WebhookClient\Models\WebhookCall]

[hashimaziz1]

I've set up my Stripe webhooks as shown in the documentation and using the Stripe CLI have confirmed that all of the events are returning status code 200. However, when I navigate to my payment view (where my Stripe form should be displaying but isn't due to the error) I can see the following in my Laravel log file:

[[2022-02-25 23:11:54] local.ERROR: Too few arguments to function App\Jobs\StripeWebhooks\PaymentIntentSucceeded::__construct(), 0 passed in D:\Users\Hashim\Documents\Projects\Websites\RadioCodes\radiocodes\vendor\laravel\framework\src\Illuminate\Foundation\Bus\Dispatchable.php on line 17 and exactly 1 expected {"exception":"[object]
...

When I do the only thing I can think of to fix this error and pass $webhook through to each preceding method and then finally to the dispatch call for PaymentIntentSucceeded like so:

$this->storeStripe($webhookCall);

...I get an even weirder error as a response:

Error 404: No query results for model [Spatie\WebhookClient\Models\WebhookCall]

This error doesn't even show in my Laravel log file and can only be seen from my dev tools. Searching Google for it tells me that it's an error returned by FindOrFail(), but since I'm not using one in my code I'm guessing this is a bug with the package, especially since I'm getting the error after following everything the documentation says.

PaymentIntentSucceeded:

class PaymentIntentSucceeded implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    /** @var \Spatie\WebhookClient\Models\WebhookCall */
    public $webhookCall;

   public function __construct(WebhookCall $webhookCall)
    {
        $this->webhookCall = $webhookCall;
    }

    public function handle()
    {

        $paymentIntent = $this->webhookCall->payload["data"]["object"];

        $transaction = new Transaction;
        $transaction->payment_gateway = "Stripe"; 
        /* etc... */
        $transaction->save();

    }
}

stripe-webhooks:

return [
    /*
     * Stripe will sign each webhook using a secret. You can find the used secret at the
     * webhook configuration settings: https://dashboard.stripe.com/account/webhooks.
     */
    'signing_secret' => env('STRIPE_WEBHOOK_SECRET'),

    /*
     * You can define the job that should be run when a certain webhook hits your application
     * here. The key is the name of the Stripe event type with the `.` replaced by a `_`.
     *
     * You can find a list of Stripe webhook types here:
     * https://stripe.com/docs/api#event_types.
     */
    'jobs' => [
        "payment_intent.succeeded" => \App\Jobs\StripeWebhooks\PaymentIntentSucceeded::class,
        // 'source_chargeable' => \App\Jobs\StripeWebhooks\HandleChargeableSource::class,
        // 'charge_failed' => \App\Jobs\StripeWebhooks\HandleFailedCharge::class,
    ],

    /*
     * The classname of the model to be used. The class should equal or extend
     * Spatie\StripeWebhooks\ProcessStripeWebhookJob.
     */
    'model' => \Spatie\StripeWebhooks\ProcessStripeWebhookJob::class,

    /**
     * This class determines if the webhook call should be stored and processed.
     */
    'profile' => \Spatie\WebhookClient\WebhookProfile\ProcessEverythingWebhookProfile::class,

    /*
     * When disabled, the package will not verify if the signature is valid.
     * This can be handy in local environments.
     */
    'verify_signature' => env('STRIPE_SIGNATURE_VERIFY', true),
];

Route file:

Route::stripeWebhooks('stripe-webhook');

Any ideas? I can also provide more of the code if necessary, like most Stripe payment forms the request originates from a client-side AJAX fetch, which then goes to a payment route, then to the controller which dispatches the job.

[freekmurze]

I currently don’t have time to look into this in detail. The tests prove that this package is working correctly. Can you PR a failing test (and a fix should the package be in error)?

[hashimaziz1]

I currently don’t have time to look into this in detail. The tests prove that this package is working correctly. Can you PR a failing test (and a fix should the package be in error)?

It seems to be a strategy in the Spatie packages to quickly close issues using "the tests" as an excuse, but tests do not/cannot prove that a specific bug doesn't exist, which is the entire purpose of filing a bug report. For obvious reasons, I can't provide a fix to a bug that I don't understand, and discounting all bug reports just because they don't also come with a fix is a weird strategy. If you don't have a fix for the bug it would make much more sense to leave the issue option so people could continue reporting instances of it/information on it with the goal of ultimately resolving the bug rather than brushing it under the carpet.

[JasperTey]

I recently ran into the No query results for model [Spatie\WebhookClient\Models\WebhookCall] issue with the underlying package Spatie\WebhookClient I was using in a production app. Since this package uses the WebhookClient package under the hood, this might be relevant.

Quoting from my comment at: spatie/laravel-webhook-client#49 (comment)

Eventually I thought it might be related to race conditions and db transactions, because the issue seemed to occur when a stream of consecutive webhooks were received in rapid succession. So I did two things:

• In the webhook processing Job (which extends ProcessWebhookJob), I added a public $delay = 5;
• Updated my queue configuration's after_commit to true. I could've also done this at the job-level with public $afterCommit = true;

This appears to have resolved things, at least on an anecdotal level. I would need to write some formal tests to confirm for sure whether the after_commit made a difference.