Skip to content

fix(channel): surface backend failures when toggling a plugin#3295

Open
szafranski wants to merge 1 commit into
iOfficeAI:mainfrom
szafranski:fix/channel-toggle-surface-enable-failures
Open

fix(channel): surface backend failures when toggling a plugin#3295
szafranski wants to merge 1 commit into
iOfficeAI:mainfrom
szafranski:fix/channel-toggle-surface-enable-failures

Conversation

@szafranski

@szafranski szafranski commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

Pull Request

Description

The channel enable/disable endpoints return HTTP 200 with { success: false, error } on failure, but httpRequest only throws on non-2xx responses and enablePlugin/disablePlugin discarded the response body. A failed enable therefore showed a success toast while the toggle reverted and the plugin stayed disabled — exactly the misleading feedback reported when re-enabling a channel.

Adds expectBridgeSuccess, which throws when a BridgeResponse reports success: false, and applies it to channel enable/disable so the existing try/catch handlers surface the real error instead of a success message.

Note: the functional root cause lives in AionCore (re-enable rejected an empty config) — see the companion PR iOfficeAI/AionCore. This PR makes any genuine enable/disable failure honest in the UI rather than silently reverting the toggle.

Related Issues

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation update

Testing

  • My code follows the project's code style guidelines
  • I have performed a self-review of my own code
  • My changes generate no new warnings or errors

Added 3 unit tests in httpBridge.test.ts covering success (resolves), failure (throws the backend error on HTTP 200 + success: false), and the generic-message fallback.

  • bunx vitest run → 1202 passed
  • bunx tsc --noEmit → clean
  • bun run lint → 0 errors
  • bun run format → applied

Additional Context

httpRequest unwraps the { data } envelope, so enablePlugin/disablePlugin already received the inner BridgeResponse; they just ignored it. The wrapper centralizes the success check so all existing callers (channel toggles, auto-enable) benefit without changes.


Thank you for contributing to AionUi! 🎉

@codecov

codecov Bot commented Jun 11, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@szafranski szafranski force-pushed the fix/channel-toggle-surface-enable-failures branch 5 times, most recently from 73d86ee to dd816bd Compare July 8, 2026 08:15
The channel enable/disable endpoints return HTTP 200 with
`{ success: false, error }` on failure, but `httpRequest` only throws on
non-2xx responses and `enablePlugin`/`disablePlugin` discarded the body.
A failed enable therefore showed a success toast while the toggle
reverted and the plugin stayed disabled — exactly the misleading
feedback reported when re-enabling a channel.

Add `expectBridgeSuccess`, which throws when a `BridgeResponse` reports
`success: false`, and apply it to channel enable/disable so the existing
try/catch handlers surface the real error instead of a success message.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@szafranski szafranski force-pushed the fix/channel-toggle-surface-enable-failures branch from dd816bd to f8c99f5 Compare July 11, 2026 09:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Channels (e.g. Telegram) can't be re-enabled after being disabled

1 participant