instructure/canvas-lms · error · CanvasCache::Redis::UnsupportedRedisMethod

Redis method `# ` is potentially dangerous, and should only…

Error message

Redis method `#{command}` is potentially dangerous, and should only be called from console, and only if you fully understand the consequences. If you're sure, retry after wrapping in `RedisClient.with_dangerous_redis_methods`

What it means

The Twemproxy adapter allows certain risky commands (ALLOWED_UNSUPPORTED) only when explicitly opted in. If the command is in ALLOWED_UNSUPPORTED but RedisClient.dangerous_redis_methods_allowed? is false and GuardRail.environment is not :deploy, check_command raises UnsupportedRedisMethod telling you to wrap the call in RedisClient.with_dangerous_redis_methods.

Solutions

Wrap the call: RedisClient.with_dangerous_redis_methods { redis.flushdb }
Run the command with GuardRail.activate(:deploy) { ... } in a controlled deploy context
Replace the destructive command with a safer, supported alternative (e.g. targeted deletes)
Move the command into a proper deploy/maintenance script that sets the right environment

Example fix

// before
redis.flushdb
// after
RedisClient.with_dangerous_redis_methods do
  redis.flushdb
end

Defensive patterns

Strategy: try-catch

Validate before calling

dangerous = ALLOWED_METHODS.include?(cmd.to_s.upcase) && !RedisClient.dangerous_redis_methods_allowed? && GuardRail.environment != :deploy

Try / catch

begin
  RedisClient.with_dangerous_redis_methods { redis.call(cmd) }
rescue CanvasCache::Redis::UnsupportedRedisMethod => e
  Rails.logger.error("dangerous redis call blocked: #{e.message}")
end

Prevention

Always wrap risky commands in RedisClient.with_dangerous_redis_methods
Restrict destructive Redis work to :deploy GuardRail environment
Prefer targeted deletes over FLUSH-style commands

When it happens

Trigger: Calling an allowed-but-dangerous command (e.g. FLUSHDB/FLUSHALL-style methods) outside RedisClient.with_dangerous_redis_methods and outside a :deploy GuardRail environment — typically from a console or script.

Common situations: Developer runs a destructive maintenance command in the Rails console against proxied Redis; a rake task performs flush/delete without the dangerous-methods wrapper; environment detection misconfigures GuardRail so the deploy exception doesn't apply.

Related errors

AI-assisted analysis of instructure/canvas-lms@1c9f0bb801 (2026-09-15). Data as JSON: /api/errors/2a760bf8768c031c. Report an issue: GitHub.

Appendix: source

Thrown at gems/canvas_cache/lib/redis_client/twemproxy.rb:107

    def call(command, _config)
      check_command(command.first.to_s)
      super
    end

    def call_pipelined(commands, _config)
      commands.each do |command|
        check_command(command.first.to_s)
      end
      super
    end

    def check_command(command)
      if UNSUPPORTED_METHODS.include?(command)
        raise CanvasCache::Redis::UnsupportedRedisMethod,
              "Redis method `#{command}` is not supported by Twemproxy, and so shouldn't be used in Canvas"
      end
      if ALLOWED_UNSUPPORTED.include?(command) && !RedisClient.dangerous_redis_methods_allowed? && GuardRail.environment != :deploy
        raise CanvasCache::Redis::UnsupportedRedisMethod,
              "Redis method `#{command}` is potentially dangerous, and should only be called from console, and only if you fully understand the consequences. If you're sure, retry after wrapping in `RedisClient.with_dangerous_redis_methods`"
      end
    end
  end
end

View on GitHub (pinned to 1c9f0bb801)