Go back to a sequence with the same app_id

[97k]

Is your feature request related to a problem? Please describe.
Currently, going back in time is only supported by fork id, but this requires a new app id to begin with in the first place.

Describe the solution you'd like
reset the current app to provided sequence id enabling us go back in time with the same app_id.

Describe alternatives you've considered
Deleting the record in mongo manually and persisting new record with overwriting the app_id.

Additional context
Discussion in the discord: https://discord.com/channels/1221891403253288970/1361390866983555264/1361854169593549103

[elijahbenizzy]

So given the immutability design goal, I'm wondering if you want a different approach.

1. Keep the app_id as immutable -- create a new one
2. Keep a pointer to "current" (elsewhere) -- this will be something you manually run when forking
3. Use that pointer to load up the latest conversation state

This is effectively the "git" strategy -- when you do a rebase/reset you're not overwriting the commit hash, rather you're
overwriting a tag/pointer to which commit hash is the latest. We could store this notion in the persister, but for now this should be simple to DIY I think.

Thoughts?

[97k]

I really appreciate this approach! The "git strategy" makes a lot of sense, allowing us to revert to any point in time or even perform a hard reset when needed.

Previously, I could only think of using the first option, which involves creating a new app_id and manually updating the database by deleting the previous app_id.

Now that you've mentioned the git strategy, it feels like a much more elegant solution.
Could you please elaborate on the simple DIY you mentioned?

[elijahbenizzy]

I really appreciate this approach! The "git strategy" makes a lot of sense, allowing us to revert to any point in time or even perform a hard reset when needed.

Previously, I could only think of using the first option, which involves creating a new app_id and manually updating the database by deleting the previous app_id.

Now that you've mentioned the git strategy, it feels like a much more elegant solution. Could you please elaborate on the simple DIY you mentioned?

Yeah, so I think you'd want to add something that keeps track of the current application ID. On the "back" button, you would effectively:

1. Create a new application ID using initialize_from
2. Update the "current" pointer to point to that
3. Proceed as usual

I think that should be it? The cool thing is you can build a commit tree from the data you save as well -- E.G. visualize all the forks and load up at any point. Immutability is high value there.

[97k]

This actually seems like a great solution.
I am gonna reiterate to get a green flag that we are on same page.

Under the hood setup | Changes in state

• application_id (this stays immutable)
• current_app_id (this is mutable) (new addition)

New flow (user presses back button)

• create a new application from using forking (initialise_from)
• In the current application, update the current pointer to the new application id
  Now, when loading the app, we want to get the id of current_app and load that app_id instead.

Context:
I was using app_id more like a session_id and then it stored the conversation that is happening in that session.
Now, if in a request, we do get a session_id and there is a non-null value of current_app_id, then I'll redirect to the current_app_id internally.