Can one of the repo owners verify this patch?

Thanks Łukasz!
Although I think it would be more awesome if we pursue what @viktorklang mentioned in the original issue - that stay() does not trigger a transition event, whereas /* in A*/ goto(A) does.

I think this PR will trigger on both cases? Would you try to work a bit more no this?
I expect that the DSL needs to be changed a little for this to work.

OK TO TEST

Ok, this version does what we need it to.

I'm thinking if we could implement it without having to change API... Since it's val's we can't really return the same instance "but change the timeout" (this would have allowed us to check prevState eq currentState), but having a var would not be nice, hm hm. Let's sleep over it but in general looks ok.

Thanks for the contribution and organising the hacker garden, I'll ping you tomorrow about this PR :-)

Can one of the repo owners verify this patch?

OK TO TEST
PLS BUILD

If we go with the change of FSM.State we should perhaps put the the extra field a second parameter list, to avoid breaking unapply and equals. That parameter can be private, I think. The user is not supposed to create instances of FSM.State?

@patriknw +1

LGTM otherwise

Ah, of course: this change will also need to be incorporated in the documentation (API docs and reference docs).

+1 though I welcome this change, I think it will likely break a lot of
folks who have done workaround to this, so should be
documented/communicated well.

On Thu, Jun 5, 2014 at 4:12 AM, Roland Kuhn notifications@github.com
wrote:

Ah, of course: this change will also need to be incorporated in the
documentation (API docs and reference docs).

—
Reply to this email directly or view it on GitHub
#15360 (comment).

PLS BUILD

Pull request validation: SUCCESS 👍
Refer to this link for build results: https://jenkins.akka.io/job/pr-validator-per-commit-jenkins/171/

Cool. So this just needs docs in FSM, both java and scala, and the migration guide updated and we can merge it.

the second parameter list looks good

Docs in Internal monitoring should be updated to reflect this change too I think. We only explain it in external monitoring (less often used).

Code is OK, we need improve the docs still a bit though @bambuchaAdm.

Merging manually with typo fixes now, after agreeing to do so with @bambuchaAdm.

Squashed and will merge the fixed up commit in: #15561