ActiveRecord::SubclassNotFound (Invalid single-table inheritance type) after file change about devise-jwt

[waiting-for-dev]

Hi @alfie-max . What makes you think that the root of your issue is in devise-jwt?

[alfie-max]

Firstly, using just devise doesn't cause this issue. (web authentications)

Then there is this : https://github.com/waiting-for-dev/devise-jwt/blob/master/lib/devise/jwt/models/jwt_authenticatable.rb#L19

Here the self object is not getting updated after a code change.

[waiting-for-dev]

I still don't understand which is the issue. Could you please elaborate it more and, if you know it, point to the solution?

Here the self object is not getting updated after a code change.

What do you mean by this? There self refers to the ActiveRecord::Base subclass, not to any instance.

Also, I don't see devise-jwt in the backtrace you pasted in the rails issue.

[alfie-max]

This method find_for_jwt_authentication seems to be called on every request whenever authenticate_trader! is called, but this binding with the ActiveRecord class User only happens the first time the app is loaded, and hence the self.object_id here is the old id of the previous class instance when the app was first loaded,
and hence the self == subclass equality fails here :
https://github.com/rails/rails/blob/master/activerecord/lib/active_record/inheritance.rb#L201

Also, when i say the self object i too refer to the ActiveRecord::Base subclass, which is the Trader class in my case.

I'm trying to find a fix, but i have no clue on where to get started with

[alfie-max]

@waiting-for-dev do you see what i see?

[waiting-for-dev]

Rails autoloading is quite famous to be the source of a lot of issues, particularly with STI.

Maybe you can solve your issue following their recommendation:

http://guides.rubyonrails.org/autoloading_and_reloading_constants.html#autoloading-and-sti

[alfie-max]

Hi, wasn't able to get back to this till now. So i checked out the link you shared. But it's not that the class is not available during that time. Its that what this gem has already loaded is not getting reloaded along with when rails reloads the classes when a code change is detected.

So when the app is initially loaded,
both devise-jwt and rails has loaded the class Trader(in my case)
So the object id of the class Trader then in memory is lets say YYY

Now after a code change has been made, the class gets reloaded by rails and gets the id ZZZ but what devise-jwt still references is YYY.

And so when rails tries to find the STI subclass, it fails.

I think this should make the issue much clearer.

[waiting-for-dev]

Hi @alfie-max ,

Rails auto-loading combined with Rails STI is a perfect cocktail to have issues like the one you encountered. So, I'm not sure that this gem is doing something "wrong" about it, and I suspect you should do some little hack as it is usually the case with rails auto-loading. To be honest, right now I don't have the time to deep into this, so I recommend you to search for the root of the issue and if you find that this gem is really responsible of it you can submit a Pull Request I would be happy to merge. Sorry I can't help beyond this.

[redtachyons]

I tried to find the cause of this issue, Here we are storing model mappings in JWT.config.mappings this configuration is not auto loaded and will remain the same for entire lifespan of the app. But the actual model will reload and will have new class with same name but with different object_id.

Eg

model Trader is loaded is object id 1
JWT.config.mappings will be {:trader => Trader()}
Now once the app is reloaded in file change, Trader will get reloaded and get new id 2.

But devise jwt will be still using old model which is cached inside mappings hash. So the equality comparison fails

I am not sure about which gem is to be fixed

• If it is devise-jwt gem, then we have to make config hash compatible with autoload
• If it is active record, then we have to change comparison logic, from object_id to model name

[alfie-max]

Got an advice from @matthewd that instead of storing the mapping as a class instance why don't we store the class name. So that when required we can find the class instance using that?

[waiting-for-dev]

Hey @alfie-max & @redtachyons ,

do you have in mind following with PR waiting-for-dev/warden-jwt_auth#5 & #24 ? I'm waiting for some feedback in the first one from @alfie-max . If not, please tell me so I can assign them to myself and work on them when I find the time.

Thanks

[alfie-max]

It would be good if you could take a look, but i'm still looking into this and wish to get this fixed, but recently haven't been able to find the time for it.

[waiting-for-dev]

Fixed in 0.4.4