basecamp/fizzy · error · NotImplementedError

Fizzy does not support Queenbee-initiated ownership transfer

Error message

Fizzy does not support Queenbee-initiated ownership transfers

What it means

Account#transferred_ownership! from the Account::QueenbeeIntegration concern (SaaS build only) deliberately raises NotImplementedError. The Queenbee integration interface defines this callback for ownership transfers initiated on the Queenbee side, but hosted Fizzy only supports Fizzy-initiated transfers, so the method is a hard guard; saas/test/models/account/queenbee_integration_test.rb asserts that it raises. Hitting it means your code path tried to apply a Queenbee-initiated ownership change to a Fizzy account, which the product forbids.

Source

Thrown at saas/app/models/account/queenbee_integration.rb:45

  def reactivate!
    reactivate
  end

  def canceled?
    cancelled?
  end

  def owner_name
    users.owner.first&.name
  end

  def owner_email
    users.owner.first&.identity&.email_address
  end

  def transferred_ownership!
    raise NotImplementedError, "Fizzy does not support Queenbee-initiated ownership transfers"
  end

  def plan
    "FreeV1"
  end

  def comped?
    false
  end

  def comped=(value)
  end
end

View on GitHub (pinned to 7aabe74580)

Solutions

Do not call transferred_ownership!; the raise is intentional and test-asserted, so skip Queenbee-side transfer events in the dispatcher
Implement ownership transfer inside Fizzy (reassign the owning user), then notify Queenbee through the outbound client API instead of accepting the reverse direction
If you dispatch Queenbee events generically, filter the ownership-transfer event type in one place before method dispatch
If the raise reaches production logs from an existing sync job, treat it as a signal that a new Queenbee event type needs an explicit handler (skip or alert), not a bug to patch by implementing the method silently

Example fix

# before: symmetric Queenbee event dispatch includes the transfer callback
when 'ownership.transferred' then account.transferred_ownership!

# after: transfers are Fizzy-initiated only; acknowledge and skip
when 'ownership.transferred'
  Rails.logger.info('Skipping Queenbee-initiated transfer for account ' + account.queenbee_id.to_s)

Defensive patterns

Strategy: try-catch

Validate before calling

return if event_name == 'ownership.transferred' # Fizzy raises NotImplementedError by design
account.transferred_ownership!

Try / catch

begin
  account.transferred_ownership!
rescue NotImplementedError => e
  Rails.logger.warn(e.message + ' for account ' + account.id.to_s)
end

Prevention

Treat transferred_ownership! as deliberately unimplemented: the SaaS test suite asserts it raises
Filter unsupported Queenbee event types in one place before dispatching to integration methods
Perform ownership changes Fizzy-side, then push them to Queenbee via the outbound client
Keep an explicit list of handled Queenbee callbacks next to the dispatcher so new event types surface at review

When it happens

Trigger: Calling account.transferred_ownership! on an Account that includes Account::QueenbeeIntegration. Typical call sites: a Queenbee event/webhook handler with a case that maps 'ownership transferred' events onto the integration methods, a generic sync job that invokes the whole interface, or a console/script exercising every callback.

Common situations: Implementing a handler for Queenbee account events (create, cancel, reactivate, transfer) and wiring every callback symmetrically; a Queenbee client gem upgrade that starts delivering a new ownership-transfer event type to existing Fizzy installs; a developer assuming the concern's public methods are all safe to call from the sync side.

AI-assisted analysis of basecamp/fizzy@7aabe74580 (2026-08-21). Data as JSON: /api/errors/05788e129588b198. Report an issue: GitHub.