Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error handling - undefined method 'status' #3

Closed
zlenderja opened this issue Aug 16, 2022 · 2 comments · Fixed by #4
Closed

Error handling - undefined method 'status' #3

zlenderja opened this issue Aug 16, 2022 · 2 comments · Fixed by #4

Comments

@zlenderja
Copy link

zlenderja commented Aug 16, 2022

Context

Library versions

ruby (2.7)
rails (6.1.6.1)
anycable-rails (1.3.4)
yabeda-anycable (0.1.1)

Description of the problem

Let's say I have a channel with a method that contains a bug.

class SampleChannel < ApplicationCable::Channel
  def subscribe
  end

  def speak
    speak! # this method doesn't exist
  end
end

When a message is sent from the client, when I use yebeda-anycable, the logs output this error

undefined method 'status'

instead of warning me about a missing method which is the actual problem in the codebase.

This happens due to response being nil in this line when an error was raised from the channel object.

By default the yabeda-anycable middleware is added to the middleware chain in the 3rd place.

[
    [0] #<AnyCable::Middlewares::Exceptions:0x00007fb07d309140>,
    [1] #<AnyCable::Rails::Middlewares::Executor:0x00007fb086720ea0 @executor=#<Class:0x00007fb085ecb638>>,
    [2] #<Yabeda::AnyCable::Middleware:0x00007fb06e3c6718>,
    [3] #<AnyCable::Middlewares::CheckVersion:0x00007fb06e3bcce0 @version="v1">,
    [4] #<AnyCable::Middlewares::EnvSid:0x00007fb06e3bcc90>
]

which means the AnyCable::Middlewares::Exceptions catches the error raised in Yabeda::AnyCable::Middleware but not the error which is raised by the channel.

Possible solutions

Handling within yabeda-anycable

One way to fix it is to check if response object responds to :status method. A commit with such fix.

Changing the order in the middleware chain

Another solution would probably be to change the order in the middleware chain. If Yabeda::AnyCable::Middleware is listed before the AnyCable::Middlewares::Exceptions, it also works as expected.

[
    [0] #<Yabeda::AnyCable::Middleware:0x00007fb06e3c6718>,
    [1] #<AnyCable::Middlewares::Exceptions:0x00007fb07d309140>,
    [2] #<AnyCable::Rails::Middlewares::Executor:0x00007fb086720ea0 @executor=#<Class:0x00007fb085ecb638>>,
    [3] #<AnyCable::Middlewares::CheckVersion:0x00007fb06e3bcce0 @version="v1">,
    [4] #<AnyCable::Middlewares::EnvSid:0x00007fb06e3bcc90>
]

However, AnyCable::MiddlewareChain.use only allows to append the middleware to the chain, there aren't any #insert_before or #insert_after methods available on the AnyCable::MiddlewareChain. We could add such methods to AnyCable::MiddlewareChain first, and then use them within this library.

Summary

Are there some other ways to resolve the issue I haven't thought of? I wonder what do you think which approach should be used to resolve it?

@Envek
Copy link
Member

Envek commented Aug 18, 2022

Thank you very much for the detailed explanation and proposed fix!

For the AnyCable middleware chain functionality changes I will summon @palkan ;-)

@palkan
Copy link

palkan commented Aug 23, 2022

Thank you very much for the detailed explanation and proposed fix!

+1

Yeah, I faced this issue (and thought that I fixed it 🙂).

Exception handling middleware should be the first one to catch possible exceptions in middlewares.

So, we need to handle exceptions in Yabeda middleware (we're using ensure, right? Thus, we're expecting exceptions and need to take care of them).

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 a pull request may close this issue.

3 participants