Discourse v2026.3.0 (Docker): faraday-multipart version conflict (plugin pins 1.1.1, core activates 1.2.0)

[cedricSarre]

Summary

On Discourse v2026.3.0 running in Docker, this plugin fails to load because it pins faraday-multipart to 1.1.1 while Discourse/core already activates faraday-multipart 1.2.0.
This triggers a RubyGems activation conflict and aborts migrations/boot.

Environment

• Discourse version: v2026.3.0
• Deployment: Docker (official Discourse Docker setup)
• Plugin: moderation-api/discourse-moderation-api
• Relevant file: plugin.rb
  https://github.com/moderation-api/discourse-moderation-api/blob/main/plugin.rb

Steps to reproduce

1. Enable/install the discourse-moderation-api plugin in a Discourse Docker setup.
2. Rebuild the container (which runs migrations), e.g.:

   cd /var/discourse
   ./launcher rebuild app

Actual result

Rebuild/migrations abort with:

Gem::LoadError: can't activate faraday-multipart-1.1.1, already activated faraday-multipart-1.2.0
/var/www/discourse/lib/plugin_gem.rb:25:in `PluginGem.load'
/var/www/discourse/lib/plugin/instance.rb:901:in `Plugin::Instance#gem'
/var/www/discourse/plugins/discourse-moderation-api/plugin.rb:14:in `Plugin::Instance#activate!'
...

Expected result

The plugin should load successfully on Discourse v2026.3.0 (Docker) without a gem activation conflict, and rebuild/migrations should complete.

Proposed fix

In plugin.rb, update the pinned dependency:

• From:

  gem "faraday-multipart", "1.1.1", { require: false }

• To:

  gem "faraday-multipart", "1.2.0", { require: false }

Additional context

Discourse installs plugin gems with --ignore-dependencies, so this plugin explicitly declares gems in plugin.rb. On Discourse v2026.3.0, faraday-multipart 1.2.0 is already activated, so pinning 1.1.1 causes the conflict.