Ember error on Unpinning, Archiving topic


#1

I’ve had a hard time using the admin utility tool to unpin and/or archive topics. I tried to do so on both dev v1.8.0.beta1 +3|Firefox 50.1.0 and production v1.8.0.beta2 +63|Firefox 50.1.0 & Chrome 55.0.2883.95, resulting in slightly different errors. I have tried this both on newly created topics and topics generated at the creation of a category.

I ran rspec with one inconsequential failure:

rspec ./spec/models/user_visit_spec.rb:36 # UserVisit#by_day collect closed interval visits

Acceptance tests would’ve been more telling, but, weirdly, when I went to /qunit, nothing loaded:

dev:

Unprocessable Entity
unwrapErrorThrown@ember:30421:15
errorFor@ember:30403:14
onerrorDefault@ember:30393:17
EventTarget.trigger@ember:57841:9
Promise.prototype._onError/<@ember:58725:9
Queue.prototype.invoke@ember:339:7
Queue.prototype.flush@ember:407:9
DeferredActionQueues.prototype.flush@ember:531:9
Backburner.prototype.end@ember:601:7
Backburner.prototype.run@ember:724:11
run@ember:21520:12
performAjax/args.error@discourse/lib/ajax:87:11
jQuery.Callbacks/fire@jquery:3183:11
jQuery.Callbacks/self.fireWith@jquery:3313:7
done@jquery:8757:5
.send/callback/<@jquery:9121:9
  ember
Uncaught promise:  Object { jqXHR: Object, textStatus: "error", errorThrown: "Unprocessable Entity" }

production w/Firefox:

No Reason Phrase
o@https://graphme.io/assets/ember_jquery-60dedd1dca1d8b8ce48b6d0087db3b96f3149b9b5af2d0c7c6357967d29031fb.js:10:25500
i@https://graphme.io/assets/ember_jquery-60dedd1dca1d8b8ce48b6d0087db3b96f3149b9b5af2d0c7c6357967d29031fb.js:10:25357
r@https://graphme.io/assets/ember_jquery-60dedd1dca1d8b8ce48b6d0087db3b96f3149b9b5af2d0c7c6357967d29031fb.js:10:25286
ye.trigger@https://graphme.io/assets/ember_jquery-60dedd1dca1d8b8ce48b6d0087db3b96f3149b9b5af2d0c7c6357967d29031fb.js:19:30372
j.prototype._onError/<@https://graphme.io/assets/ember_jquery-60dedd1dca1d8b8ce48b6d0087db3b96f3149b9b5af2d0c7c6357967d29031fb.js:20:324
a.prototype.invoke@https://graphme.io/assets/ember_jquery-60dedd1dca1d8b8ce48b6d0087db3b96f3149b9b5af2d0c7c6357967d29031fb.js:3:26544
a.prototype.flush@https://graphme.io/assets/ember_jquery-60dedd1dca1d8b8ce48b6d0087db3b96f3149b9b5af2d0c7c6357967d29031fb.js:3:27069
u.prototype.flush@https://graphme.io/assets/ember_jquery-60dedd1dca1d8b8ce48b6d0087db3b96f3149b9b5af2d0c7c6357967d29031fb.js:3:27837
p.prototype.end@https://graphme.io/assets/ember_jquery-60dedd1dca1d8b8ce48b6d0087db3b96f3149b9b5af2d0c7c6357967d29031fb.js:3:28182
p.prototype.run@https://graphme.io/assets/ember_jquery-60dedd1dca1d8b8ce48b6d0087db3b96f3149b9b5af2d0c7c6357967d29031fb.js:3:29309
l@https://graphme.io/assets/ember_jquery-60dedd1dca1d8b8ce48b6d0087db3b96f3149b9b5af2d0c7c6357967d29031fb.js:9:423
e/n.error@https://graphme.io/assets/application-21942e0b16b99fd916a9193250f85511ffed539932522c8923d0b334e3d20270.js:1:28767
oe.Callbacks/l@https://graphme.io/assets/ember_jquery-60dedd1dca1d8b8ce48b6d0087db3b96f3149b9b5af2d0c7c6357967d29031fb.js:2:6505
oe.Callbacks/c.fireWith@https://graphme.io/assets/ember_jquery-60dedd1dca1d8b8ce48b6d0087db3b96f3149b9b5af2d0c7c6357967d29031fb.js:2:7278
r@https://graphme.io/assets/ember_jquery-60dedd1dca1d8b8ce48b6d0087db3b96f3149b9b5af2d0c7c6357967d29031fb.js:3:10235
.send/n/<@https://graphme.io/assets/ember_jquery-60dedd1dca1d8b8ce48b6d0087db3b96f3149b9b5af2d0c7c6357967d29031fb.js:3:16063

production w/Chrome:

Does anyone else have this problem? Perhaps I should come back after I get qunit in order. :notsureif:


(Robin Ward) #2

What errors are you seeing on the server side when this happens?


(Jeff Atwood) #3

Can we repro this @techAPJ?


(cpradio) #4

I can’t repro this. I just updated my sandbox to latest and both pin/unpin, archive/unarchive work just fine.

Going to run the rspecs now and qunit to rule those out (as maybe the tests are bad?)

Edit @7:09 PM EST: All qunit tests passed.

Edit @7:25 PM EST: Lots of rspec failures, but I think my dev machine is to blame. I think I need to flush and re-initialize the test database before running them. Will have to look into that later, as I got to get the kids to bed.


#5

Well, thank you for scrutinizing this. @eviltrout my first instinct should’ve been to check the server. :facepalm:

So, while I know how to remedy the problem, I still don’t know why it happens.

My plugin uses a callback

DiscourseEvent.on(:post_created) do |post, opts, user|
    #the work
end

Before now, I did not have a guard clause checking the post_type. Now, I make sure it’s post_type == 1 (the pinned “post” was type 3). For some reason, not having the guard clause would raise this error, on the newly created post:

ActiveRecord::RecordInvalid - Validation failed: Body is too short (minimum is 20 characters), Body seems unclear, is it a complete sentence?:
  activerecord (4.2.7.1) lib/active_record/validations.rb:79:in `raise_record_invalid'
  activerecord (4.2.7.1) lib/active_record/validations.rb:43:in `save!'
  activerecord (4.2.7.1) lib/active_record/attribute_methods/dirty.rb:29:in `save!'
  activerecord (4.2.7.1) lib/active_record/transactions.rb:291:in `block in save!'
  activerecord (4.2.7.1) lib/active_record/transactions.rb:351:in `block in with_transaction_returning_status'
  activerecord (4.2.7.1) lib/active_record/connection_adapters/abstract/database_statements.rb:211:in `transaction'
  activerecord (4.2.7.1) lib/active_record/transactions.rb:220:in `transaction'
  activerecord (4.2.7.1) lib/active_record/transactions.rb:348:in `with_transaction_returning_status'
  activerecord (4.2.7.1) lib/active_record/transactions.rb:291:in `save!'

Edit: The weird part to me is that this validation (which probably normally doesn’t run for post_type 3) did run when the I delineated the callback.


#6

Now I know why this happened. It’s not that DiscourseEvent.on(:post_created) inadvertently ran any validations on new posts that did not need it. I ran this in the callback

post.custom_fields['gist_thumbnail_url'] = url
post.save!

which caused all the validations to run. :drevil: This is the root.


(Régis Hanol) #7