u/Cadnerak

Hey everyone! I’m relatively new to the plant game, and was gifted a spider plant as a housewarming gift. I have it in a nursery pot inside a decorative pot, water it only when the soil is quite dry until fully saturate, and a bit of water comes out of the bottom. I have it in a NE facing window (windows only face NE in my apartment) and it is right on the sill. The plant had new growth, however it also seems to have brown small holes and crease marks causing the leaves to flop over, and sometimes “close” in on themselves. Additionally the color is not as dark green as I have seen other spider plants. Is something wrong? The new growth seems to indicate not, but the browning is throwing me off

Looking for some advice on how to make this feel more refined. It feels a bit empty, and am open to any feedback or beginner advice. Been cooking for some time now, but just getting into plating

Hi everyone,

I'm working on implementing a MFA login flow utilizing a finite state machine, and have a question about persisting the state machine to a database in order to survive an API crash. Lets say I have the following states, which are a subset of the overall machine

1. Send OTP SMS
2. Wait For OTP Input
3. Mint Session

Directly after the "Send OTP SMS" state, we automatically transition into the "Wait For OTP Input" state. On invalid input, we stay in that state, and on valid input, we go to "Mint Session" state. Now that the machine is defined, let me explain. my issue with persistence

In order to persist a state machine state, it is typically advised that the "work" done by a state must be done in a database transaction alongside the persistence of the FSM so that there are no data inconsistencies. Redhat advises this in this article, outlined in the first bullet underneath "Implementing State Machines". I have interpreted this to mean that the state machine should persist the state the machine is transitioning into, because upon completion of the database transaction the current state is completed. Once it is completed if the application crashes, we want to restore it in the state we would have transitioned into.

In order to persist the state machine and send the SMS OTP atomically, we will have to use the transactional outbox pattern to write a message to the database for sending the OTP SMS. In the "Send OTP SMS" state, we will open a database transaction, write the outbox message and the "Wait For OTP Input" state, and commit the transaction. The state machine will then transition into the "Wait For OTP Input" state, and all is good. The only issue with this is that the state "Send OTP SMS" itself is determining, outside of the rules of the state machine, that the next state will be "Wait For OTP Input" by writing this to the database. From the literature that I've read, it seems as though states themselves should not have context of what the state-to-be is, but rather should be isolated and focus on any tasks that must be completed in the state itself. If this is the case, how can we achieve full atomicity with the persistence of a state machine and the completion of work in such a way that we can consistently restore state machines from the database during a crash at any point in time?

If it helps, I'm particularly looking at using XState as the state machine implementation to drive the process. Thank you in advance