Join GitHub today
[reliable payments] router payment state machine #2761
This PR introduces a persistent state machine to the
This was referenced
Mar 12, 2019
Roasbeef left a comment
I really dig this approach! With the state machine, I find it much easier to follow than the prior attempts at a solution to this problem. I've completed an initial pass so far, and the main question in my mind is the size of the overlap between this new state machine and the existing control tower in the switch. At one point the control tower addressed a need within the codebase, but it seems like this new state machine can eventually subsume the responsibilities of the control tower.
referenced this pull request
Mar 19, 2019
joostjager left a comment
I am, as always, worried about the persistence and the work and inflexibility it may cause us in the future. Tried to mainly analyze this part of the PR.
Why don't you merge the switch pr first btw, work bottom up? Or will we have with just this PR already good working resumes of payments?
cfromknecht left a comment •
nice refactor of the router/switch interactions, this should make the whole payment flow much tighter!
one question i have with new state introduced in the control tower, will we just treat all payments that are currently grounded as started but never attempted? an alternative would be to rename grounded payments as failed, and introduce a new state for initiated. not sure which is better atm