This is actually a problem in our scripts it seems, we down the docker container containing postgres

Hey @U0C8489U6 ! So you're expecting the node to be able to resume seamlessly somehow? Doing it naively wouldn't be safe if you are actually modifying tx_events out-of-band - like if you wipe the table then start submitting new transactions you're going to get into a pretty funky state

ah, so you really want to wipe the local node state (index-store) also - is cycling the node(s) not possible?

yeah cause in dev that's a common flow for us

dropping containers for now it is not working - that's on us, tech debt

well, I have considered pushing the team for a dev-time-only drop! API before but we've never spec'd it out or decided that it's definitely a bad idea - in lieu of that I'm struggling to think of other options

another good use case for that for us is for E2E testing, we reset postgres before re-seeding with the data we need (hitting the apis)

back to the original question more directly, I suspect it would be non-trivial for a node to somehow know for sure that it should 'reset' itself based on a wiped/modified tx_events - at least without introducing a new coordination mechanism (e.g. store some UUID at the beginning of the log that tracks such epoch changes)

assuming you're embedding XT nodes in your own code anyway I guess you can at least hack something together for this in userspace

I am thinking maybe restarting the XTDB component might work? given we wipe that table plus all the checkpointing dirs?

if there are no checkpoints and you haven't configured a durable kv store (Rocks / LMDB) then yep you should be okay to restart your component

right, didn't think about the kv store...

well I have definitely successfully used clojure.java.shell/sh to rm -rf the directories before :)