Can't destroy while in state error

[Zachary Dixon]

I understand this error, I'm just not sure why I'm getting it.

I'm trying to destroy a record which then returns an error from the server:

An error occurred during the storage operation!

After this, shouldn't the StateMachine transition out of error so it can try to be deleted again? Or is there a way I need to handle this?

If I try to destroy it again, I get:

Can't destroy while in state error

[Robert Mosolgo]

I don't know "why" it works like this, but I can tell you what I've gleaned from experience:

- If the server responds 500 during a storage operation (create, update, destroy), the record is thrown into "error" state.

- "error" state is a total dead end. On the Batman.Model::lifecycle transition table, no transitions start from "error"

- I don't know of any way of getting out of error state. Maybe I'm missing something, but I've never seen it.

- Maybe it's because if the server responds 500, that's really an error and the application should error out. 

It looks like you could manually change the state by setting the stateMachine's `_state` accessor: https://github.com/batmanjs/batman/blob/master/src/utilities/state_machine.coffee#L78

But I don't really see a good way to hook that in -- the state machine doesn't fire any events unless the transition is valid ... 

Short answer: fix that 500 :P

robert

[Zachary Dixon]

Dang, that's what I was afraid of.

Of course the best thing would be to fix the 500 :) I just wanted to be prepared in case one happened before we found it in production. Although, they probably shouldn't be happening in production anyway (or very rarely at least), so I probably won't worry about it too much.

[Robert Mosolgo]

Yeah, I've had to modify a lot of Rails endpoints to return more meaningful (and proper) response codes (404, 422, 403, etc) to avoid it. Replacing a lot of `save!`s with `save`, etc.

For update operations, `Model::transaction` provides a little bit of protection: if the transaction gets into error state, the original isn't spoiled, so the user can go back and try again.

--
You received this message because you are subscribed to the Google Groups "batman.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to batmanjs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Zachary Dixon]

Hey Robert,

So this has become a bigger issue than I expected. I want to try to implement the model transactions but I'm not completely sure I understand them. According to the docs it sounds like saving a transaction will still save the original record after the transaction's validations from batman pass, making the original record still arrive at the error state? Unless I'm misunderstanding it, which I definitely could be.

On the other hand, the way you make it sound here is that it tries to save the transaction (actually sending the request to the server), if it passes then it saves the original model? This also brings up another question; does this require 2 requests for every update if it works that way? 

After reading the docs again, it sounds like you can save the transaction, and once returned successfully, you can apply the changes to the original model. Obviously I'm a bit confused :P

[Robert Mosolgo]

Hey Zach,

Great question. I guess transactions could use a proper introduction. I've taken a swing at it here:

http://rmosolgo.github.io/blog/2014/07/19/model-transactions-in-batman-dot-js/

Please let me know if I've left any unanswered questions, I hope I've gotten it all!

robert

[Robert Mosolgo]

Also, circling around to the original subject of this thread, I've opened an issue for that feature (getting records out of error state): https://github.com/batmanjs/batman/issues/1098