without-durability-sqlite 0.0.7__tar.gz → 0.0.9__tar.gz

{without_durability_sqlite-0.0.7 → without_durability_sqlite-0.0.9}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: without-durability-sqlite
-Version: 0.0.7
+Version: 0.0.9
 Summary: A without-durability checkpoint store and queue backed by one SQLite file, with no server and no third-party driver.
 Author: Josh Karpel
 Author-email: Josh Karpel <josh.karpel@gmail.com>
@@ -14,8 +14,8 @@ Classifier: Programming Language :: Python :: 3 :: Only
 Classifier: Programming Language :: Python :: 3.14
 Classifier: Topic :: Software Development :: Libraries
 Classifier: Typing :: Typed
-Requires-Dist: without-async==0.0.7
-Requires-Dist: without-durability==0.0.7
+Requires-Dist: without-async==0.0.9
+Requires-Dist: without-durability==0.0.9
 Requires-Python: >=3.14
 Description-Content-Type: text/markdown
 
@@ -42,8 +42,8 @@ a cluster, a database server, or a dependency.
 Two questions the other stores have to answer carefully settle themselves here.
 There is one writer at a time by construction, so `BEGIN IMMEDIATE` takes the
 write lock for the whole transaction and the fence check and the write it guards
-cannot be interleaved: Postgres needs `FOR UPDATE` on the claim row to get that
-and Redis needs a Lua script, while here the transaction *is* the exclusion. And
+cannot be interleaved: Postgres needs a row lock on the claim to get that and
+Redis needs a Lua script, while here the transaction *is* the exclusion. And
 there is nothing to co-locate, because the datastore is a file, so `transact`,
 `arrive`, and `deliver` reach every table an application keeps in it. That last one is the same
 guarantee DBOS gets from Postgres, for an application that never needed Postgres.

{without_durability_sqlite-0.0.7 → without_durability_sqlite-0.0.9}/README.md

@@ -21,8 +21,8 @@ a cluster, a database server, or a dependency.
 Two questions the other stores have to answer carefully settle themselves here.
 There is one writer at a time by construction, so `BEGIN IMMEDIATE` takes the
 write lock for the whole transaction and the fence check and the write it guards
-cannot be interleaved: Postgres needs `FOR UPDATE` on the claim row to get that
-and Redis needs a Lua script, while here the transaction *is* the exclusion. And
+cannot be interleaved: Postgres needs a row lock on the claim to get that and
+Redis needs a Lua script, while here the transaction *is* the exclusion. And
 there is nothing to co-locate, because the datastore is a file, so `transact`,
 `arrive`, and `deliver` reach every table an application keeps in it. That last one is the same
 guarantee DBOS gets from Postgres, for an application that never needed Postgres.

{without_durability_sqlite-0.0.7 → without_durability_sqlite-0.0.9}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "uv_build"
 
 [project]
 name = "without-durability-sqlite"
-version = "0.0.7"
+version = "0.0.9"
 description = "A without-durability checkpoint store and queue backed by one SQLite file, with no server and no third-party driver."
 readme = "README.md"
 license = "MIT"
@@ -21,8 +21,8 @@ classifiers = [
     "Typing :: Typed",
 ]
 dependencies = [
-    "without-async==0.0.7",
-    "without-durability==0.0.7",
+    "without-async==0.0.9",
+    "without-durability==0.0.9",
 ]
 
 [[project.authors]]

{without_durability_sqlite-0.0.7 → without_durability_sqlite-0.0.9}/pyproject.toml.orig

@@ -4,7 +4,7 @@ build-backend = "uv_build"
 
 [project]
 name = "without-durability-sqlite"
-version = "0.0.7"
+version = "0.0.9"
 description = "A without-durability checkpoint store and queue backed by one SQLite file, with no server and no third-party driver."
 readme = "README.md"
 license = "MIT"
@@ -24,8 +24,8 @@ classifiers = [
     "Typing :: Typed",
 ]
 dependencies = [
-    "without-async==0.0.7",
-    "without-durability==0.0.7",
+    "without-async==0.0.9",
+    "without-durability==0.0.9",
 ]
 
 [tool.uv.sources]

{without_durability_sqlite-0.0.7 → without_durability_sqlite-0.0.9}/src/without_durability_sqlite/store.py

@@ -8,9 +8,9 @@
 #
 #   - There is one writer at a time, by construction. `BEGIN IMMEDIATE` takes the write
 #     lock for the whole transaction, so the fence check and the write it guards cannot
-#     be interleaved with anything. Postgres needs `FOR UPDATE` on the claim row to get
-#     that, because there readers and writers run concurrently and a statement's snapshot
-#     can be stale; Redis needs a Lua script. Here the transaction *is* the exclusion.
+#     be interleaved with anything. Postgres needs a row lock on the claim to get that,
+#     because there readers and writers run concurrently and a statement's snapshot can
+#     be stale; Redis needs a Lua script. Here the transaction *is* the exclusion.
 #   - There is nothing to co-locate. `transact`, `arrive`, and `deliver` reach the whole datastore
 #     because the datastore is a file, so the question the other two stores have to keep
 #     asking (are these two writes in one local commit?) has one answer and it is yes.
@@ -59,6 +59,7 @@ from collections.abc import Callable
 from contextlib import closing
 from dataclasses import dataclass
 from dataclasses import field
+from datetime import UTC
 from datetime import datetime
 from datetime import timedelta
 from pathlib import Path
@@ -76,6 +77,7 @@ from without_durability.interfaces import Entry
 from without_durability.interfaces import Fenced
 from without_durability.interfaces import Pass
 from without_durability.interfaces import Recorded
+from without_durability.interfaces import Written
 from without_durability.interfaces import check_duration
 from without_durability.stepwise import now_utc
 
@@ -112,6 +114,13 @@ BUSY_TIMEOUT = Milliseconds(5_000)
 # invites any tool to open, so the guarantee would otherwise rest on a promise SQLite
 # declines to make. Declaring the column is what puts this table outside that sentence.
 #
+# `written_at` is what `history` reads, and its `DEFAULT` does the same work `seq` does:
+# evaluated on insert, and left alone by every conflict update below, so a losing write
+# moves the value, the position, and the time equally not at all. The clock is SQL's for
+# the reason the claim's is, which here is consistency with the other two stores rather
+# than a guarantee: SQLite *is* the caller's machine, so there are no two clocks to
+# disagree.
+#
 # `(workflow, step)` is `UNIQUE` rather than the primary key because a table gets one
 # primary key and `seq` is now it. Nothing else changes: both columns are `NOT NULL`, so
 # the constraint admits exactly the rows the primary key did, and it is still what the
@@ -125,13 +134,22 @@ CREATE TABLE IF NOT EXISTS workflow_checkpoint (
     workflow TEXT NOT NULL,
     step TEXT NOT NULL,
     value TEXT NOT NULL,
+    written_at REAL NOT NULL DEFAULT (unixepoch('now', 'subsec')),
     UNIQUE (workflow, step)
 );
 
 CREATE TABLE IF NOT EXISTS workflow_claim (
     workflow TEXT PRIMARY KEY,
     token INTEGER NOT NULL,
-    held_until REAL NOT NULL
+    -- The budget: the latest this claim can lapse at, whatever its holder does.
+    held_until REAL NOT NULL,
+    -- When it lapses if nothing more is heard, which is what `CLAIM` tests. Every write of
+    -- it is a `MIN` against `held_until`, so a sign of life cannot carry a pass past its
+    -- budget or take a workflow back after a `RELEASE`.
+    alive_until REAL NOT NULL,
+    -- What one sign of life is worth, carried here because `RECORD` is one and is not told:
+    -- the statement making a write has only the workflow to go on.
+    alive_for REAL NOT NULL
 ) WITHOUT ROWID;
 
 CREATE TABLE IF NOT EXISTS workflow_queue (
@@ -155,18 +173,62 @@ CREATE INDEX IF NOT EXISTS workflow_queue_visible_at ON workflow_queue (namespac
 # between the two. SQLite *is* the caller's machine, so that argument does not apply;
 # keeping the clock in SQL anyway costs nothing and keeps the three stores reading alike.
 CLAIM = """
-INSERT INTO workflow_claim (workflow, token, held_until)
-VALUES (:workflow, 1, unixepoch('now', 'subsec') + :lease)
+INSERT INTO workflow_claim (workflow, token, held_until, alive_until, alive_for)
+VALUES (
+    :workflow, 1,
+    unixepoch('now', 'subsec') + :budget,
+    unixepoch('now', 'subsec') + MIN(:alive, :budget),
+    :alive
+)
 ON CONFLICT (workflow) DO UPDATE
-    SET token = workflow_claim.token + 1, held_until = unixepoch('now', 'subsec') + :lease
-    WHERE workflow_claim.held_until <= unixepoch('now', 'subsec')
+    SET token = workflow_claim.token + 1,
+        held_until = unixepoch('now', 'subsec') + :budget,
+        alive_until = unixepoch('now', 'subsec') + MIN(:alive, :budget),
+        alive_for = :alive
+    WHERE workflow_claim.alive_until <= unixepoch('now', 'subsec')
 RETURNING token
 """
 
-# The fenced, conditional write, as one statement. The Postgres version wraps its fence
-# read in a `FOR UPDATE` CTE so a claim committing mid-statement cannot go unseen; here
-# the statement is its own transaction and SQLite admits one writer, so selecting the
-# claim row inline is already serialized against every other write.
+# A fresh budget and a sign of life with it: what a step that declared a `within` spends
+# before running its effect. Conditional on the token rather than on the deadline, since a
+# claim that has lapsed without being taken is still this pass's to stretch. The `MAX`
+# against the budget already standing is what keeps a short window from taking time away
+# from the unannotated steps behind it: a budget can only ever be too generous from here.
+EXTEND = """
+UPDATE workflow_claim
+SET held_until = MAX(held_until, unixepoch('now', 'subsec') + :budget),
+    alive_until = MIN(unixepoch('now', 'subsec') + :alive, MAX(held_until, unixepoch('now', 'subsec') + :budget)),
+    alive_for = :alive
+WHERE workflow = :workflow AND token <= :token
+"""
+
+# A sign of life and nothing else: the worker's tick. The `MIN` against the budget is what
+# makes "this does not buy more time" true rather than merely intended, and refusing once
+# the budget has run out is what makes the worker act on it: a renewal that reported
+# success on a lapsed claim would keep a hung pass running for as long as nothing else
+# happened to take its workflow.
+RENEW = """
+UPDATE workflow_claim
+SET alive_until = MIN(unixepoch('now', 'subsec') + :alive, held_until), alive_for = :alive
+WHERE workflow = :workflow AND token <= :token AND held_until > unixepoch('now', 'subsec')
+"""
+
+# A write is a sign of life, so `record` and `transact` note one in the same transaction
+# they write in. Postgres folds this into the fence CTE its `RECORD` already locks with;
+# SQLite admits one writer at a time, so a second statement inside the same transaction is
+# the same atomicity by a plainer route. Conditional on the token for the reason the
+# Postgres CTE is: a write refused at the fence must renew nobody, or a superseded pass's
+# stray writes would keep the winner's claim alive after the winner had died.
+WROTE = """
+UPDATE workflow_claim
+SET alive_until = MIN(unixepoch('now', 'subsec') + alive_for, held_until)
+WHERE workflow = :workflow AND token <= :token
+"""
+
+# The fenced, conditional write, as one statement. The Postgres version locks the claim row
+# in a data-modifying CTE so a claim committing mid-statement cannot go unseen; here the
+# statement runs under `BEGIN IMMEDIATE` beside `WROTE` and SQLite admits one writer, so
+# selecting the claim row inline is already serialized against every other write.
 #
 # `DO UPDATE SET value = the value already there` is a write that changes nothing and
 # therefore returns the row that was already stored, which is how a caller that lost the
@@ -224,9 +286,38 @@ WRITE = "INSERT INTO workflow_checkpoint (workflow, step, value) VALUES (?, ?, ?
 # than a formality: `WHERE workflow = ?` is served by the unique index on
 # `(workflow, step)`, so without it the rows come back sorted by step name.
 LOAD = "SELECT step, value FROM workflow_checkpoint WHERE workflow = ? ORDER BY seq"
+HISTORY = "SELECT step, value, written_at FROM workflow_checkpoint WHERE workflow = ? ORDER BY seq"
 # Hand the workflow back early, but keep the token, so the next claim gets the next
 # number up and a pass that comes back from the dead still loses.
-RELEASE = "UPDATE workflow_claim SET held_until = unixepoch('now', 'subsec') WHERE workflow = ? AND token = ?"
+# Both deadlines, and the budget is the load-bearing one: a write this pass had already
+# started is entitled to land, since releasing keeps the token, and bringing `held_until`
+# down to now is what stops that write's own `WROTE` from claiming the workflow straight
+# back, since every renewal is a `MIN` against it.
+RELEASE = """
+UPDATE workflow_claim
+SET held_until = unixepoch('now', 'subsec'), alive_until = unixepoch('now', 'subsec')
+WHERE workflow = ? AND token = ?
+"""
+
+# Forget every record a workflow has. Paired with `SUPERSEDE` below and never run without
+# it, which is what the transaction in `discard` is for.
+DISCARD = "DELETE FROM workflow_checkpoint WHERE workflow = ?"
+
+# Take the fencing token *up*, so a pass still holding one is refused at its next write.
+#
+# An `UPDATE` rather than the upsert `CLAIM` is, and the difference is what it declines to
+# do: a workflow with no claim row has no `Pass` outstanding, since a `Pass` is only ever
+# handed out by a `claim` that wrote one, so there is nothing to fence and a row minted
+# here would be a tombstone for a workflow nobody ever claimed. The deadline is moved to
+# now at the same time, so the workflow is claimable again immediately: what is kept is the
+# ordering, not the claim.
+SUPERSEDE = """
+UPDATE workflow_claim
+SET token = token + 1,
+    held_until = unixepoch('now', 'subsec'),
+    alive_until = unixepoch('now', 'subsec')
+WHERE workflow = ?
+"""
 
 # Take the oldest visible workflow and push it a lease into the future. There is no
 # `SKIP LOCKED` here and none is wanted: it exists so one poller does not queue behind
@@ -255,6 +346,11 @@ ON CONFLICT (namespace, workflow) DO UPDATE SET visible_at = excluded.visible_at
 # different `visible_at`, so the equality is the whole check.
 FINISH = "DELETE FROM workflow_queue WHERE namespace = ? AND workflow = ? AND visible_at = ?"
 
+# Withdraw the workflow's right to run, whatever its row currently means. Unconditional
+# where `FINISH` compares the receipt, which is the difference between finishing a pass
+# (leave anything that asked for another) and cancelling the workflow (leave nothing).
+CANCEL = "DELETE FROM workflow_queue WHERE namespace = ? AND workflow = ?"
+
 # Suspend until a deadline, under the same comparison and for the same reason. A workflow
 # holds one row here, so writing the deadline unconditionally would land on top of a
 # `make_ready` that arrived while the pass was ending and push a confirmation out to a
@@ -262,6 +358,19 @@ FINISH = "DELETE FROM workflow_queue WHERE namespace = ? AND workflow = ? AND vi
 # pass that runs sooner writes it again.
 SUSPEND = "UPDATE workflow_queue SET visible_at = ? WHERE namespace = ? AND workflow = ? AND visible_at = ?"
 
+# Keep a delivery this worker's for another `within`, under the same comparison as `SUSPEND`
+# and for the same reason: a `make_ready` that landed since wrote a different `visible_at`,
+# and pushing the visibility out on top of it would bury a wakeup that already arrived.
+#
+# The new visibility is returned because it *is* the new receipt, which is the price of the
+# trick that makes this table a queue: a worker still holding the old one would find its own
+# `FINISH` refused by that equality and the workflow redelivered for nothing.
+RENEW_DELIVERY = """
+UPDATE workflow_queue SET visible_at = unixepoch('now', 'subsec') + :within
+WHERE namespace = :namespace AND workflow = :workflow AND visible_at = :receipt
+RETURNING visible_at
+"""
+
 # What an effect is for a store whose datastore is a SQLite file: a callback handed a
 # cursor already inside `transact`'s transaction.
 #
@@ -467,30 +576,73 @@ class SqliteCheckpointer:
         rows = await self.database.run(lambda connection: connection.execute(LOAD, (workflow,)).fetchall())
         return {step: self.codec.decode(encoded) for step, encoded in rows}
 
-    async def claim(self, workflow: str, lease: timedelta) -> Pass | None:
+    async def history(self, workflow: str) -> dict[str, Written]:
+        """The same records `load` returns, each with the moment it was written."""
+        rows = await self.database.run(lambda connection: connection.execute(HISTORY, (workflow,)).fetchall())
+        return {
+            step: Written(value=self.codec.decode(encoded), at=datetime.fromtimestamp(written_at, UTC))
+            for step, encoded, written_at in rows
+        }
+
+    async def claim(self, workflow: str, budget: timedelta, alive: timedelta) -> Pass | None:
         taken = await self.database.run(
             lambda connection: connection.execute(
                 CLAIM,
-                {"workflow": workflow, "lease": lease.total_seconds()},
+                {
+                    "workflow": workflow,
+                    "budget": budget.total_seconds(),
+                    "alive": alive.total_seconds(),
+                },
             ).fetchone()
         )
         if taken is None:
             return None
         return Pass(workflow=workflow, token=int(taken[0]))
 
+    async def extend(self, holder: Pass, budget: timedelta, alive: timedelta) -> bool:
+        changed = await self.database.run(
+            lambda connection: (
+                connection.execute(
+                    EXTEND,
+                    {
+                        "workflow": holder.workflow,
+                        "token": holder.token,
+                        "budget": budget.total_seconds(),
+                        "alive": alive.total_seconds(),
+                    },
+                ).rowcount
+            )
+        )
+        # No row touched means the `WHERE` refused the token, which is the only way this
+        # misses: a `Pass` exists because a `claim` wrote the row it names.
+        return changed == 1
+
+    async def renew(self, holder: Pass, alive: timedelta) -> bool:
+        changed = await self.database.run(
+            lambda connection: (
+                connection.execute(
+                    RENEW,
+                    {"workflow": holder.workflow, "token": holder.token, "alive": alive.total_seconds()},
+                ).rowcount
+            )
+        )
+        return changed == 1
+
     async def record(self, holder: Pass, key: str, value: object) -> Recorded:
         encoded = self.codec.encode(value)
-        stored = await self.database.run(
-            lambda connection: connection.execute(
+
+        # The encoding stored, and whether it is this call's, which SQLite answers with 0/1.
+        def write(cursor: sqlite3.Cursor) -> tuple[str, int] | None:
+            # The write and the sign of life it counts as, in one transaction, so a crash
+            # between them cannot leave a record whose writer looks dead.
+            stored = cursor.execute(
                 RECORD,
-                {
-                    "workflow": holder.workflow,
-                    "step": key,
-                    "value": encoded,
-                    "token": holder.token,
-                },
+                {"workflow": holder.workflow, "step": key, "value": encoded, "token": holder.token},
             ).fetchone()
-        )
+            cursor.execute(WROTE, {"workflow": holder.workflow, "token": holder.token})
+            return stored
+
+        stored = await self.database.run(lambda connection: transacted(connection, write))
         if stored is None:
             # The statement wrote nothing, which happens for exactly one reason: the
             # `WHERE` that guards the insert compared this pass's token against the fence
@@ -512,6 +664,14 @@ class SqliteCheckpointer:
 
         The effect's result is written and read back through the codec rather than
         returned as it came, so it round-trips exactly as a later pass will see it.
+
+        What the write lock costs is stated rather than hidden: it is the connection's,
+        and there is one connection, so nothing else in this process reaches the store
+        until the effect returns, the worker's own renewal included. The claim is safe
+        regardless, since the sign of life at the end of the transaction lands before any
+        queued `claim` runs; what a long effect does lose is its delivery, which is not
+        renewed meanwhile and is redelivered after a `lease` to a pass that finds the
+        workflow held. Keep effects short, or accept that redelivery.
         """
 
         def one_commit(cursor: sqlite3.Cursor) -> object:
@@ -523,6 +683,7 @@ class SqliteCheckpointer:
                 return self.codec.decode(recorded[0])
             written = self.codec.encode(effect(cursor))
             cursor.execute(WRITE, (holder.workflow, key, written))
+            cursor.execute(WROTE, {"workflow": holder.workflow, "token": holder.token})
             return self.codec.decode(written)
 
         return await self.database.run(lambda connection: transacted(connection, one_commit))
@@ -547,6 +708,26 @@ class SqliteCheckpointer:
         key, encoded = cast(tuple[str, str], stored)
         return Entry(key=key, value=self.codec.decode(encoded))
 
+    async def discard(self, workflow: str) -> int:
+        """
+        Forget every record this workflow has, and raise its fence, in one transaction.
+
+        One commit rather than two statements, because the two are only right together: a
+        crash between them either leaves the records deleted with the fence unraised, so
+        the pass that was mid-flight writes them back one at a time, or the reverse, which
+        fences a live pass for a deletion that never happened.
+
+        What is left behind is one claim row carrying a number. Nothing here sweeps it, in
+        keeping with the rest of this store, where nothing expires and tidying the file is
+        the deployment's homework.
+        """
+
+        def one_commit(cursor: sqlite3.Cursor) -> int:
+            cursor.execute(SUPERSEDE, (workflow,))
+            return cursor.execute(DISCARD, (workflow,)).rowcount
+
+        return await self.database.run(lambda connection: transacted(connection, one_commit))
+
     async def release(self, holder: Pass) -> None:
         await self.database.run(lambda connection: connection.execute(RELEASE, (holder.workflow, holder.token)))
 
@@ -655,6 +836,50 @@ class SqliteScheduler:
         """Nothing to take over by hand: an abandoned workflow becomes visible on its own."""
         return None
 
+    async def extend(self, delivery: Delivery, within: timedelta) -> Delivery:
+        """
+        Push this delivery's visibility out, and say what it is called now.
+
+        The new visibility is the new receipt, since this table's receipt *is* its
+        visibility, so the caller is handed a delivery to use from here rather than left to
+        discover that the one it holds has been renamed.
+
+        No row means this delivery is no longer this worker's: cancelled, or rescheduled by
+        a wakeup that arrived mid-pass, either of which wrote a `visible_at` that is not the
+        one it took. The answer to both is to hand back what came in, exactly as `wake_at`
+        and `done` already do.
+        """
+        renewed = await self.database.run(
+            lambda connection: connection.execute(
+                RENEW_DELIVERY,
+                {
+                    "namespace": self.namespace,
+                    "workflow": delivery.workflow,
+                    "receipt": float(delivery.receipt),
+                    "within": within.total_seconds(),
+                },
+            ).fetchone()
+        )
+        if renewed is None:
+            return delivery
+        return Delivery(workflow=delivery.workflow, receipt=repr(float(renewed[0])))
+
+    async def cancel(self, workflow: str) -> None:
+        """
+        Drop the workflow's row, whichever of the three things its `visible_at` means.
+
+        One `DELETE` covers queued, sleeping, and out with a worker, because this table
+        holds one row per workflow and the visibility is the only thing that differs
+        between them. That is the same collapse that leaves `wake_due` and `reclaim` with
+        nothing to do.
+
+        The half of `cancel` a queue sweep cannot reach comes free with it: a pass still in
+        flight answers with `wake_at`, which is an `UPDATE` conditional on the visibility
+        still being the one it took, and a deleted row has none. So the deadline it was
+        about to write updates nothing and a deleted workflow is not put back to sleep.
+        """
+        await self.database.run(lambda connection: connection.execute(CANCEL, (self.namespace, workflow)))
+
     async def done(self, delivery: Delivery) -> None:
         """
         Drop the workflow, unless something asked for another pass while this one ran.
@@ -724,3 +949,21 @@ class SqliteDurable:
             return Entry(key=key, value=self.checkpointer.codec.decode(encoded))
 
         return await self.checkpointer.database.run(lambda connection: transacted(connection, one_commit))
+
+    async def delete(self, workflow: str) -> int:
+        """
+        Cancel the workflow's wakeups and forget its records, together or not at all.
+
+        Three statements in one commit, so the ordering `SplitDurable` has to reason about
+        does not arise: there is no window in which the records are gone and a wakeup is
+        not, and none in which the fence has been raised for a deletion that did not
+        happen. Which is the same thing `arrive` gets from this store and for the same
+        reason, one file.
+        """
+
+        def one_commit(cursor: sqlite3.Cursor) -> int:
+            cursor.execute(CANCEL, (self.scheduler.namespace, workflow))
+            cursor.execute(SUPERSEDE, (workflow,))
+            return cursor.execute(DISCARD, (workflow,)).rowcount
+
+        return await self.checkpointer.database.run(lambda connection: transacted(connection, one_commit))