search

bigcartel / dugway

Easily build and test Big Cartel themes.
https://developers.bigcartel.com/api/themes
MIT License
149 stars 22 forks source link

500 error with Product.find("") AJAX call #105

Closed pjv closed 10 years ago

pjv commented 10 years ago

I'm getting a 500 error when trying to use Product.find.

I'm using Dugway v. 0.9.0 (upgraded since taking the trace below that shows 0.8.3 - same exact error) on a fully up to date OS X install. ruby 2.0.0p247.

The javascript looks like this:

Product.find('knot-bracelet', function(product) {
  return console.log(product.name);
});

'knot-bracelet' is a valid permalink on the store I am working with.

Below is the trace. Anybody have an idea what might be happening? 

Error: IOError at /product/knot-bracelet.js
====================================

> not opened for reading

activesupport (3.2.16) lib/active_support/json/encoding.rb, line 207
--------------------------------------------------------------------

``` ruby
  202     def as_json(options = nil) to_s end #:nodoc:
  203   end
  204   
  205   module Enumerable
  206     def as_json(options = nil) #:nodoc:
> 207       to_a.as_json(options)
  208     end
  209   end
  210   
  211   class Array
  212     def as_json(options = nil) #:nodoc:

App backtrace

Full backtrace

pjv commented 10 years ago

Some additional data... it seems like it will work once or twice right after re-starting the dugway server. Then it fails after that as above.

joshnabbott commented 10 years ago

@outerim @deadformat and I have somewhat determined this is an error regarding conflicting gems. We're having a hard time figuring out exactly what is conflicting with what though.

pjv commented 10 years ago

Thanks - if you figure out even a clunky work-around that may not be the "final solution", I'd appreciate hearing it. This is currently stopping me from being able to move forward on a major project.

pjv commented 10 years ago

...or if you can give me a quick outline of what you know that makes you think it is a gem conflict, maybe i can try to push toward some kind of resolution. i have pretty high motivation to get this fixed since it is currently holding me up.

outerim commented 10 years ago

@pjv assuming it is a conflict you could try using bundler. Create a file named Gemfile in the root directory of your theme (where you run dugway server, same place the config.ru is, etc). It's contents should look like this:

source 'https://rubygems.org'

gem 'dugway'

Then run the command bundle install. It should generate a bunch of output indicating gems that are being installed or used. Something along the lines of

$ bundle
Resolving dependencies...
Using i18n (0.6.4)
Using multi_json (1.8.4)
Using activesupport (3.2.17)
Using coderay (1.1.0)
Using erubis (2.7.0)
Using better_errors (0.9.0)
Using bigcartel-currency-locales (1.3.1)
Using bigcartel-theme-fonts (1.1.1)
Using bundler (1.3.5)
Using chunky_png (1.3.0)
Using coffee-script-source (1.7.0)
Using execjs (2.0.2)
Using coffee-script (2.2.0)
Using fssm (0.2.10)
Using sass (3.2.14)
Using compass (0.12.2)
Using daemons (1.1.9)
Using htmlentities (4.3.1)
Using multi_xml (0.5.5)
Using httparty (0.10.2)
Using liquid (2.4.1)
Using rack (1.4.5)
Using rack-mount (0.8.3)
Using rubyzip (0.9.9)
Using hike (1.2.3)
Using tilt (1.4.1)
Using sprockets (2.11.0)
Using sprockets-sass (0.9.1)
Using eventmachine (1.0.3)
Using thin (1.5.1)
Using thor (0.17.0)
Using uglifier (1.3.0)
Using will_paginate (3.0.5)
Using dugway (0.9.0)
Your bundle is complete!
Use `bundle show [gemname]` to see where a bundled gem is installed.

Once the bundle has been generated you can force dugway to run with the bundle by prefixing any dugway commands with bundle exec. For example bundle exec dugway server to launch the server.

pjv commented 10 years ago

@outerim : tried the bundle install / exec and i get the exact same error.

pjv commented 10 years ago

i wiped my entire set of gems and tried to start over from scratch. i installed rbenv and installed ruby 2.1.1. i am using less so i followed the instructions to create a gemfile with the appropriate lines and then did a bundle install. i still see the same issue.

would it help (or hurt) to update the gems? after doing the bundle install, gem outdated gives me this:

activesupport (3.2.17 < 4.0.4) better_errors (0.9.0 < 1.1.0) bigdecimal (1.2.4 < 1.2.5) httparty (0.10.2 < 0.13.0) i18n (0.6.4 < 0.6.9) liquid (2.4.1 < 2.6.1) minitest (4.7.5 < 5.3.1) psych (2.0.3 < 2.0.4) rack (1.4.5 < 1.5.2) rake (10.1.0 < 10.2.1) rdoc (4.1.0 < 4.1.1) rubyzip (0.9.9 < 1.1.2) sass (3.2.18 < 3.3.4) sprockets-sass (0.9.1 < 1.0.3) test-unit (2.1.1.0 < 2.5.5) thin (1.5.1 < 1.6.2) thor (0.17.0 < 0.19.1) tilt (1.4.1 < 2.0.1) uglifier (1.3.0 < 2.5.0)

outerim commented 10 years ago

@pjv, thanks this would appear not to be a gem issue then... Is it possible you could post a simplified test case? For instance a run dugway create and tweak things so that it exhibits this problem? Also the subdomain of the store you are using could be helpful. I tried a store called finelight which had a product with a matching permalink and was unable to reproduce this issue by repeatedly loading localhost:9292/product/knot-bracelet.js.

pjv commented 10 years ago

yes, finelight is the store that i am developing for.

try putting something in the cart and then hitting that url again and see if you get the error then.

EDIT: never mind. i just tried that and i can still access that url, but when i reload the cart page i still get the error. i will work on building a simplified test case. maybe i'll find the issue in the process.

EDIT 2: accckkkk! ok, i was using the wrong product. i think if you put the knot-bracelet product into the cart and then try to access the url you listed, then you may see the error.

pjv commented 10 years ago

OK, i have reproduced the issue with a very simple case.

dugway create test-store

edit layout.html to include the ajax api (add the following line in head): <script src="{{ 'api' | theme_js_url }}" type="text/javascript"></script>

edit cart.js.coffee so that it has the following content:

$ ->
  Cart.refresh (cart) ->
    for item in cart.items
      do (item) ->
        Product.find item.product, (product) ->
          console.log product.name

  $('body#cart').on 'click', '.remove', (event) ->
    event.preventDefault()

    $(this)
      .closest('li').find('input[id$=_qty]').val(0)
      .closest('form').submit()

cd test-store dugway server

now put something in the cart

outerim commented 10 years ago

Thanks @pjv. With yours and @deadformat's help I was able to determine what's going on. It's actually even easier to reproduce than we were making it. Essentially all you have to do is load an HTML version of a product, then load it's json representation. e.g. http://localhost:9292/knot-bracelet then http://localhost:9292/knot-bracelet.js

This seems to happen because the HTML rendering pipeline modifies cached store data in such a way that it cannot be dumped as json subsequently. I'm looking into a solution now.

outerim commented 10 years ago

So I have a workaround for now. It makes dugway quite a bit slower but it should correct the issues you are seeing. Change your Gemfile to load dugway this way:

gem 'dugway', github: 'bigcartel/dugway', branch: 'fix-object-caching'

Then re-run bundle and bundle exec dugway server. It's a really poor solution because of how slow it makes it but hopefully it unblocks you. I'm going out of town for the weekend but perhaps someone else can take up the reins and figure out a way of preventing liquid from modifying the product objects when pages are rendered. I tried using ActiveSupport's deep_dup instead of the shallow copy that's being done now and that didn't fix it either. Ugh. Maybe @ihearithurts wants a weekend side project :)

pjv commented 10 years ago

@outerim thanks for this. i can move ahead with my project now. i'm no ruby dev, but if i can help in some way with a better solution, let me know.

mattwigham commented 10 years ago

This is now fixed in version 0.10.1, so I'll be deleting the fix-object-caching branch. Sorry for the troubles, but thanks for reporting this.