chore: Add additional logs for state transitions #989
Conversation
|
Thinking of adding unit tests to lifecycle, where I just test that the handle_[state] functions do what we expect. This requires importing a LOT of mocked things. Not totally sure what's the cleanest way of doing that. I thought of two ways:
I initially thought to do 1 but now I'm starting to feel 2 might be better? |
coordinator/src/indexer_state.rs
Outdated
| lifecycle_state: if old_state.lifecycle_state == OldLifecycleState::Stopping { | ||
| LifecycleState::Suspending | ||
| } else { | ||
| LifecycleState::Suspended |
There was a problem hiding this comment.
This would set any state that isn't Stopping to Suspended right? We should only set this if it is Stopped. We probably need to map each state specifically since we have two types.
There was a problem hiding this comment.
So I tested this locally, and it actually doesn't reach this part of the function, unless the initial parse fails. So, all the other options ended up getting parsed correctly, and the only ones which went here, were the states which are no longer part of Lifecycle.
I verified this in the below unit test. I have four states to parse: Initializing, Running, Stopping, and Stopped. The redis state set call was only called twice, and they were called with the correct Suspending and Suspended state respectively.
I don't mind being explicit here though.
There was a problem hiding this comment.
Ah you're right, we'd only get here if parsing fails, which would only be for Stopping/Stopped. I'm fine leaving it as is then :)
There was a problem hiding this comment.
Moved the if statement to a separate variable assignment. I'll be able to put some warn logs out if there's an unexpected input.
I added a little bit more logging to the lifecycle state changes, as well as renamed the
Stopping/Stoppedstates toSuspending/Suspendedstates to more accurately capture the intention.