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

Reaching invalid state by dispatching continuosly #469

Closed
shakdwipeea opened this issue May 22, 2018 · 4 comments
Closed

Reaching invalid state by dispatching continuosly #469

shakdwipeea opened this issue May 22, 2018 · 4 comments

Comments

@shakdwipeea
Copy link

I am trying to run re-frame on clojure. I am running into a invalid route when I dispatch continuosly.
The error msg I get is:

Exception in thread "pool-1-thread-1" clojure.lang.ExceptionInfo: re-frame: router state transition not found. :scheduled :finish-run {:fsm-state :scheduled, :trigger :finish-run}

I have created a repo to reproduce this:
https://github.com/shakdwipeea/reframe-state-transition-bug

@danielcompton
Copy link
Contributor

It looks like there may be a race condition here in the Clojure (note, not ClojureScript) code. I could reproduce this as well. After looking at the code for a few minutes, my best guess is that an event is dispatched while the executor is running and the FSM is in the :running state. The executor tries to run the :finish-run trigger, but underneath it, the FSM was moved back to the :scheduled state.

scgilardi added a commit to scgilardi/re-frame that referenced this issue May 28, 2018
- re: day8#469
- -fsm-trigger reads from and writes to volatile state
- it works fine in cljs because that's single-threaded
- jvm clojure interop creates a single threaded executor, but that
  coexists with the main thread for a total thread count of 2
- adding `locking` on the EventQueue object avoids the race for clojure
  and is a no-op for clojurescript.
scgilardi added a commit to scgilardi/re-frame that referenced this issue May 28, 2018
- re: day8#469
- `-fsm-trigger` reads from and writes to volatile state
- it works fine in cljs because that's single-threaded
- jvm clojure interop creates a single threaded executor, but that
  coexists with the main thread for a total thread count of 2
- adding `locking` on the `EventQueue` object avoids the race for
  clojure and is a no-op for clojurescript.
scgilardi added a commit to scgilardi/re-frame that referenced this issue May 28, 2018
- re: day8#469
- `-fsm-trigger` reads from and writes to volatile state
- it works fine in cljs because that's single-threaded
- jvm clojure interop creates a single threaded executor, but that
  coexists with the main thread for a total thread count of 2
- adding `locking` on the `EventQueue` object avoids the race for
  clojure and is a no-op for clojurescript.
@danielcompton
Copy link
Contributor

Fixed in #471

@piotr-yuxuan
Copy link
Contributor

That feeling when I've been stumbling upon a weird error for some hours, finally I get convinced that nothing obvious in my code is responsible for it, I find this issue which has exactly the same symptoms and at the end of it I can read « Fixed » ❤️

@piotr-yuxuan
Copy link
Contributor

@scgilardi and @danielcompton thanks a lot for your work in #471. However, might I suggest you to release it? ^^ looks like it's currently in master, but latest release comes from February.

piotr-yuxuan added a commit to piotr-yuxuan/choose-a-new-phone that referenced this issue Aug 23, 2018
It fixes a clj runtime race condition. day8/re-frame#469 is on master
but hasn't been released yet.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants