Fix: Make Rust widget renderer optional to prevent Sidekiq worker crashes

[rileyseaburg]

Problem

The Sidekiq worker was crashing on startup with Fiddle::DLError: libwidget_renderer.so: cannot open shared object file.

This occurred because the Rails initializer loads widget_renderer.rb for ALL processes (including Sidekiq), but the Sidekiq worker deployment doesn't include the Rust buildpack, so the native library doesn't exist.

Root Cause

widget_renderer.rb was calling Rutie.init unconditionally, which would fail with a Fiddle::DLError when the .so file wasn't present.

Solution

Modified ext/widget_renderer/lib/widget_renderer.rb to only call Rutie.init when the library file is actually found. If the library isn't present, it logs a warning and the WidgetRenderer class simply won't be available.

This is safe because:

1. The Form#touchpoints_js_string method already has a fallback to ERB rendering when WidgetRenderer is unavailable
2. Sidekiq doesn't need the WidgetRenderer - it's only used by the web controller for serving form widgets

Testing

• ✅ Deployed to staging Sidekiq worker - now running successfully
• ✅ Staging web app still has WidgetRenderer available (library found in release directory)

Changes

• ext/widget_renderer/lib/widget_renderer.rb: Added conditional check before calling Rutie.init

[Copilot]

Pull request overview

This PR makes the Rust widget renderer optional to prevent Sidekiq worker processes from crashing when the native library is unavailable. The solution conditionally initializes the Rutie extension only when the library file is found, with appropriate error handling and logging.

Key Changes:

• Modified widget_renderer.rb to wrap Rutie initialization in a conditional check based on whether the native library was found
• Added rescue block to catch Fiddle::DLError exceptions during library loading
• Added informative logging for both success and failure scenarios

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.