Image Webhook plugin crashes playlist renderer with "Render method is only applicable for recipe plugins"

[GVDub]

LaraPaper version: 12.56.0
Description:
The Image Webhook plugin type appears to not be fully implemented for playlist use despite having an "Add to Playlist" button in the UI. When an Image Webhook plugin is added to a playlist, the playlist renderer attempts to render it on its own cycle and throws a fatal error, overwriting the device display with an error screen.
Steps to reproduce:

Create an Image Webhook plugin (Plugins → Image Webhook, give it a name, save)
Add it to a playlist via the "Add to Playlist" button
POST a valid PNG image to the webhook URL — image is accepted and "Current Image" updates correctly
Wait for the playlist renderer to cycle

Expected behavior:
The playlist displays the most recently pushed image when it cycles to the Image Webhook plugin.
Actual behavior:
The playlist renderer throws Failed to render plugin N (name): Render method is only applicable for recipe plugins and replaces the display with an error screen, overwriting the correctly pushed image.
Workaround:
Remove the Image Webhook from the playlist. Direct device pushes via api/display/update work correctly but bypass playlist rotation entirely.
Additional context:
Discovered while building a scheduled job to push Ambient Weather Network station data to e-ink displays. The external rendering pipeline works correctly — the bug is purely in the playlist renderer's handling of the Image Webhook plugin type.

[bnussbau]

There is no LaraPaper version: 12.56.0. Can you recheck?
Also I cannot reproduce this.
Maybe related to #175 ? Could you please verify that all migrations ran?

[GVDub]

I've never migrated. This is on a brand new installation. it's 0.31.3.

[bnussbau]

Interesting. Still cannot reproduce 🤔

If plugin_type === 'image_webhook', data is never stale

larapaper/app/Models/Plugin.php

Lines 213 to 215 in ca9eea6

	if ($this->plugin_type === 'image_webhook') {
	return false;
	}

and if current_image is set after uploading the image via the webhook, it should have a current_image set
not call the render method.

larapaper/routes/api.php

Lines 108 to 120 in ca9eea6

	if ($plugin->isDataStale() || $plugin->current_image === null) {
	$plugin->updateDataPayload();
	try {
	$markup = $plugin->render(device: $device);
	GenerateScreenJob::dispatchSync($device->id, $plugin->id, $markup);
	} catch (Exception $e) {
	Log::error("Failed to render plugin {$plugin->id} ({$plugin->name}): ".$e->getMessage());
	// Generate error display
	$errorImageUuid = ImageGenerationService::generateDefaultScreenImage($device, 'error', $plugin->name);
	$device->update(['current_screen_image' => $errorImageUuid]);
	}
	}

But in your case it is called.

larapaper/app/Models/Plugin.php

Lines 495 to 499 in ca9eea6

	public function render(string $size = 'full', bool $standalone = true, ?Device $device = null): string
	{
	if ($this->plugin_type !== 'recipe') {
	throw new InvalidArgumentException('Render method is only applicable for recipe plugins.');
	}

Could you verify that in the plugins table this instance has a type of image_webhook and current_image is not null after the image is pushed to the webhook url?

[GVDub]

Thanks for the quick response. After some investigation, the plugin record no longer exists in the database — I deleted the plugin via the UI to stop the error screens from displaying, so Plugin::where('name', 'Ambient Weather')->first() returns null.
However, I can report what the state was before deletion:
The image POST to the webhook URL returned a successful response, but "Current Image" in the plugin UI still showed "No image uploaded yet" after the POST — suggesting the image was accepted by the endpoint but not actually saved to the plugin record. This means current_image was null when the playlist renderer first cycled to the plugin, which is likely why it fell through to the render call despite the image_webhook type check.
So the sequence appears to have been:

Image Webhook plugin created and added to playlist
Image POSTed to webhook URL — endpoint accepted it but current_image remained null in the database
Playlist renderer cycled, found current_image === null, called render, crashed
Plugin deleted via UI to stop the error screens
Playlist still held a reference to the deleted plugin — secondary crash

Two potential issues here: the image POST not persisting current_image correctly, and the playlist renderer not handling a missing/deleted plugin gracefully.
Happy to recreate the plugin and test again with more careful logging if that would help narrow it down.

[GVDub]

Further investigation has identified the root cause. The bug is a timing/initialization issue rather than a fundamental flaw in the Image Webhook plugin type.

What actually happened:

The Image Webhook plugin was added to a playlist immediately after creation, before any image had been POSTed to the webhook URL. At that point current_image was null. When the playlist renderer cycled to the plugin, it found current_image === null and called render(), which correctly threw "Render method is only applicable for recipe plugins."

Verified working sequence:

1. Create Image Webhook plugin
2. POST an image to the webhook URL first — confirmed 200 response and current_image updates correctly in the database
3. Only then add the plugin to a playlist

With this sequence the playlist renderer finds a valid current_image and displays it correctly. No render errors.

Confirmed via tinker:

\App\Models\Plugin::find(16)->only(['current_image', 'plugin_type']);
// Returns: ["current_image" => "uuid...", "plugin_type" => "image_webhook"]

Suggested improvement:

The isDataStale() check correctly returns false for image_webhook type, but the outer condition $plugin->current_image === null still triggers the render call for a newly created plugin that hasn't received its first image yet. A graceful fallback — such as skipping the plugin silently or displaying a "waiting for first image" placeholder — would prevent the crash for anyone who adds an Image Webhook plugin to a playlist before pushing their first image.

Happy to close this if you agree with the analysis, but leaving it open in case you want to implement the graceful fallback.

[bestknee]

Seeing a similar error "Render method is only applicable for recipe plugins.", but when the Image Webhook is used as part of a mashup item in the playlist. Is this a supported use of the Image Webhook?

"Failed to render mashup playlist item 18: Render method is only applicable for recipe plugins."

[bnussbau]

Mashup with image webhook is currently unsupported. Will fix in the UI. UPDATE: fixed in 0.33