log-foundry 0.10.2.dev24__tar.gz → 0.10.2.dev25__tar.gz

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: log-foundry
-Version: 0.10.2.dev24
+Version: 0.10.2.dev25
 Summary: Generate logs for your console and JSON events for downstream consumption.
 License-Expression: MIT
 License-File: LICENSE

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/pyproject.toml

@@ -20,7 +20,7 @@ dependencies = [
 ]
 
 # Optional features. Install with: pip install log-foundry[aws]
-version = "0.10.2.dev24"
+version = "0.10.2.dev25"
 
 [project.optional-dependencies]
 aws = ["boto3>=1.43.61"]              # SQSSink, SNSSink, KinesisSink, FirehoseSink

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/sinks/_socket.py

@@ -111,6 +111,7 @@ class SocketTransport:
         self._counter_lock = threading.Lock()
         self.stop_signal: threading.Event | None = None
         self._lock = threading.Lock()
+        self._closed = False
 
     def send_all(self, messages: list[bytes]) -> None:
         """Sends each pre-framed message, reconnecting on error (FR-005, FR-006).
@@ -119,6 +120,11 @@ class SocketTransport:
         reconnect rebinds, so releasing between messages would let another thread send on a
         socket this one is about to reset (SPEC-028 FR-002).
 
+        A closed transport refuses rather than reconnecting. ``_socket`` opens a connection
+        whenever it holds none and ``close`` only drops the one it has, so without this a single
+        ``log_foundry.info()`` after ``shutdown()`` would open a TCP connection nothing will ever
+        reap — measured, and the same leak ``RabbitMQSink`` had (SPEC-028).
+
         Args:
           messages: The exact bytes to put on the wire, one call per message.
 
@@ -130,14 +136,21 @@ class SocketTransport:
             this transport propagate a dead destination to the worker instead of reporting
             success (SPEC-026 FR-001). A partial send does not raise, because the worker's retry
             would re-send the messages that already landed, and an empty call is a no-op rather
-            than a total failure.
+            than a total failure. Also when the transport is already closed.
         """
+        if not messages:
+            return
         with self._lock:
+            if self._closed:
+                raise SinkDeliveryError(
+                    f"SocketTransport delivered none of {len(messages)} message(s): "
+                    f"the transport is closed"
+                )
             delivered = 0
             for message in messages:
                 if self._send_one(message):
                     delivered += 1
-        if messages and delivered == 0:
+        if delivered == 0:
             raise SinkDeliveryError(
                 f"SocketTransport delivered none of {len(messages)} message(s)"
             )
@@ -175,6 +188,7 @@ class SocketTransport:
           None.
         """
         with self._lock:
+            self._closed = True
             self._reset()
 
     def _send_one(self, message: bytes) -> bool:

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/sinks/clickhouse.py

@@ -41,10 +41,11 @@ class ClickHouseSink:
     sink is write-only, and the worst-case delay (SPEC-027 FR-005) is ``max_retries``
     interruptible waits per chunk, 0.7 s at the defaults.
 
-    The driver requirement satisfied (SPEC-028 FR-002): a ``clickhouse-connect`` client holds
-    per-session state across an insert and the project does not publish it as safe to share
-    between threads, so this sink serializes its use rather than assuming otherwise. A lock is
-    the conservative reading — one client per thread would be the alternative, and that is the
+    The driver requirement satisfied (SPEC-028 FR-002): ``clickhouse-connect`` states that a
+    client is **not** thread-safe when using session ids, and that concurrent queries in one
+    session raise ``ProgrammingError``. This sink calls ``get_client(dsn=...)``, which takes the
+    default auto-generated session, so it is squarely in that case and the lock is required
+    rather than merely prudent. One client per thread would be the alternative, and that is the
     connection-pool design FR-002 puts out of scope.
     """
 
@@ -133,6 +134,10 @@ class ClickHouseSink:
             return
         chunks = inserted = 0
         with self._lock:
+            if self._closed:
+                raise SinkDeliveryError(
+                    f"ClickHouseSink inserted none of {len(batch)} event(s): the sink is closed"
+                )
             for chunk in chunk_list(batch, self._chunk_size):
                 chunks += 1
                 inserted += self._insert([self._row(event) for event in chunk])
@@ -157,9 +162,9 @@ class ClickHouseSink:
         with self._lock:
             if self._closed:
                 return
+            self._closed = True
             if self._owns_client:
                 self.client.close()
-            self._closed = True
 
     def _row(self, event: dict[str, object]) -> list[object]:
         """Builds one row: the extracted columns, then the whole event as JSON.

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/sinks/eventhubs.py

@@ -68,6 +68,8 @@ class AzureEventHubsSink:
         self.failed = 0
         self.dropped_oversized = 0
         self._counter_lock = threading.Lock()
+        self._lock = threading.Lock()
+        self._closed = False
 
     def losses(self) -> SinkLosses:
         """Reports oversized drops and events in a batch abandoned past the bound (FR-002).
@@ -106,6 +108,32 @@ class AzureEventHubsSink:
         """
         if not batch:
             return
+        with self._lock:
+            if self._closed:
+                raise SinkDeliveryError(
+                    f"AzureEventHubsSink sent none of {len(batch)} event(s): the sink is closed"
+                )
+            self._send_batch(batch)
+
+    def _send_batch(self, batch: list[dict[str, object]]) -> None:
+        """Packs and sends the batch, with the emit lock already held.
+
+        Split out so the lock's extent is one line in :meth:`emit`. The driver requirement
+        satisfied (SPEC-028 FR-002): Microsoft affirmatively states that the
+        ``EventHubProducerClient`` is not thread-safe and recommends guarding it with a
+        ``threading.Lock``; the ``EventDataBatch`` this builds up across the loop is single-owner
+        state besides — two threads packing into batches from one producer interleave
+        ``create_batch``/``add``/``send`` on it.
+
+        Args:
+          batch: The events to send, known non-empty.
+
+        Returns:
+          None.
+
+        Raises:
+          SinkDeliveryError: When every attempted send failed.
+        """
         event_data_cls = _event_data_cls()
         current = self.producer.create_batch()
         attempted = delivered = 0
@@ -132,6 +160,9 @@ class AzureEventHubsSink:
     def close(self) -> None:
         """Closes the producer (FR-009).
 
+        Idempotent, and takes the emit lock so the producer is never closed out from under an
+        in-flight send (SPEC-028 FR-002).
+
         Args:
           None.
 
@@ -141,7 +172,11 @@ class AzureEventHubsSink:
         Raises:
           Exception: Whatever the producer raises on close.
         """
-        self.producer.close()
+        with self._lock:
+            if self._closed:
+                return
+            self._closed = True
+            self.producer.close()
 
     def _send(self, event_batch: Any) -> int:
         """Sends one ``EventDataBatch``, retrying failures (FR-009, FR-011).

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/sinks/file.py

@@ -8,6 +8,8 @@ import threading
 import time
 from typing import TextIO
 
+from log_foundry.sinks.base import SinkDeliveryError
+
 __all__ = ["FileSink", "RotatingFileSink"]
 
 _WHEN_SECONDS = {
@@ -71,7 +73,13 @@ class FileSink:
         Raises:
           OSError: If the write or flush fails (FR-001).
         """
+        if not batch:
+            return
         with self._lock:
+            if self._closed:
+                raise SinkDeliveryError(
+                    f"FileSink wrote none of {len(batch)} event(s): the sink is closed"
+                )
             for event in batch:
                 self._stream.write(json.dumps(event) + "\n")
             self._stream.flush()
@@ -94,9 +102,9 @@ class FileSink:
         with self._lock:
             if self._closed:
                 return
+            self._closed = True
             self._stream.flush()
             self._stream.close()
-            self._closed = True
 
 
 class RotatingFileSink:
@@ -176,7 +184,13 @@ class RotatingFileSink:
         Raises:
           OSError: If a write, flush or rotation fails.
         """
+        if not batch:
+            return
         with self._lock:
+            if self._closed:
+                raise SinkDeliveryError(
+                    f"RotatingFileSink wrote none of {len(batch)} event(s): the sink is closed"
+                )
             for event in batch:
                 line = json.dumps(event) + "\n"
                 data = len(line.encode(self._encoding))
@@ -205,9 +219,9 @@ class RotatingFileSink:
         with self._lock:
             if self._closed:
                 return
+            self._closed = True
             self._stream.flush()
             self._stream.close()
-            self._closed = True
 
     @staticmethod
     def _rollover_seconds(when: str | None, interval: int) -> float | None:

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/sinks/firehose.py

@@ -32,6 +32,10 @@ class FirehoseSink:
         the chunk sent, so none could be paired to an outcome. A non-zero count means those
         records were abandoned without the stream ever confirming them — treat it as loss, and
         as a sign the client is not AWS-shaped.
+
+    The driver requirement satisfied (SPEC-028 FR-002): this sink takes **no** transport
+    lock. ``boto3`` clients are documented thread-safe, this one is built once in
+    ``__init__``, and the sink rebinds nothing after construction.
     """
 
     MAX_RECORDS = 500

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/sinks/kafka.py

@@ -24,6 +24,10 @@ class KafkaSink:
       failed: Messages whose delivery callback reported an error.
       rejected: Messages ``produce()`` itself refused — a full local queue, a serialization fault
         — which never reached the producer's batch at all.
+
+    The driver requirement satisfied (SPEC-028 FR-002): this sink takes **no** transport
+    lock. ``confluent-kafka`` documents its ``Producer`` as thread-safe, and this sink adds no state
+    of its own to guard — ``produce()`` is a local hand-off into the client's internal queue.
     """
 
     def __init__(

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/sinks/kinesis.py

@@ -32,6 +32,10 @@ class KinesisSink:
         describe the chunk sent, so none could be paired to an outcome. A non-zero count means
         those records were abandoned without the stream ever confirming them — treat it as loss,
         and as a sign the client is not AWS-shaped.
+
+    The driver requirement satisfied (SPEC-028 FR-002): this sink takes **no** transport
+    lock. ``boto3`` clients are documented thread-safe, this one is built once in
+    ``__init__``, and the sink rebinds nothing after construction.
     """
 
     MAX_RECORDS = 500

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/sinks/mongodb.py

@@ -76,6 +76,7 @@ class MongoDBSink:
         self.dropped_oversized = 0
         self._closed = False
         self._counter_lock = threading.Lock()
+        self._close_lock = threading.Lock()
 
     def losses(self) -> SinkLosses:
         """Reports oversized drops and documents the server rejected or never took (FR-002).
@@ -109,12 +110,20 @@ class MongoDBSink:
           None.
 
         Raises:
-          SinkDeliveryError: When nothing was inserted (SPEC-026 FR-001) — a connection error
+          SinkDeliveryError: When the sink is already closed, since ``pymongo`` raises
+            ``InvalidOperation`` on any use of a closed client and the library has its own word
+            for "none of this was delivered". Also when nothing was inserted (SPEC-026 FR-001) — a connection error
             past the retry bound, or a bulk write every one of whose documents the server
             rejected. A bulk write that stored some is partial and never raises. A batch of
             nothing but oversized documents does not raise either: they can never fit, so there
             is nothing to retry, and they are reported through :meth:`losses`.
         """
+        if not batch:
+            return
+        if self._closed:
+            raise SinkDeliveryError(
+                f"MongoDBSink inserted none of {len(batch)} document(s): the sink is closed"
+            )
         documents = self._documents(batch)
         if not documents:
             return
@@ -157,7 +166,18 @@ class MongoDBSink:
     def close(self) -> None:
         """Closes the client only if the sink owns it (FR-005).
 
-        Idempotent.
+        Idempotent, with the flag set under a lock so two concurrent ``close()`` calls cannot
+        both reach ``client.close()`` — ``atexit`` racing user code is the documented case.
+
+        The lock does **not** make a close wait for an in-flight ``insert_many``, and saying so
+        plainly matters: ``emit`` takes no lock here because ``pymongo``'s client is thread-safe,
+        and a close that waited would have to serialize against every insert, which is the
+        parallelism SPEC-028 FR-002 declines to remove. What covers the overlap instead is
+        :meth:`emit`'s own ``_closed`` check, which refuses the batch in the library's
+        vocabulary rather than letting it reach a closed client — pymongo raises
+        ``InvalidOperation`` on any use after close. An insert that passes the check and is
+        still in flight when the close lands can still see that error; it is counted as a failed
+        batch like any other, which is a reported loss at process exit rather than a silent one.
 
         Args:
           None.
@@ -168,11 +188,12 @@ class MongoDBSink:
         Raises:
           Exception: Whatever the client raises on close.
         """
-        if self._closed:
-            return
-        if self._owns_client:
-            self._client.close()
-        self._closed = True
+        with self._close_lock:
+            if self._closed:
+                return
+            self._closed = True
+            if self._owns_client:
+                self._client.close()
 
     def _documents(self, batch: list[dict[str, object]]) -> list[dict[str, object]]:
         """Copies each event and drops any document too large to ever fit.

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/sinks/nats.py

@@ -51,6 +51,7 @@ class NATSSink:
         self._loop = asyncio.new_event_loop()
         self.failed = 0
         self._counter_lock = threading.Lock()
+        self._lock = threading.Lock()
         if client is None:
             import nats  # type: ignore[import-not-found]
 
@@ -62,6 +63,13 @@ class NATSSink:
     def emit(self, batch: list[dict[str, object]]) -> None:
         """Drives the async publishes to completion on the managed loop (FR-007).
 
+        The driver requirement satisfied (SPEC-028 FR-002): an ``asyncio`` event loop is
+        single-entry. A second thread calling ``run_until_complete`` on a loop that is already
+        running raises ``RuntimeError``, and can leave the loop's task machinery in a state where
+        a thread never returns from ``emit`` at all — measured as a permanently hung application
+        thread on the orphan path, which is the one outcome this library must never produce. The
+        lock makes the loop what the sink already assumed it was: entered by one caller at a time.
+
         Args:
           batch: The events to publish. An empty batch is a no-op.
 
@@ -73,7 +81,12 @@ class NATSSink:
         """
         if not batch:
             return
-        self._loop.run_until_complete(self._publish_all(batch))
+        with self._lock:
+            if self._loop.is_closed():
+                raise SinkDeliveryError(
+                    f"NATSSink published none of {len(batch)} event(s): the sink is closed"
+                )
+            self._loop.run_until_complete(self._publish_all(batch))
 
     def losses(self) -> SinkLosses:
         """Reports events whose publish raised (SPEC-026 FR-002).
@@ -102,12 +115,13 @@ class NATSSink:
         Raises:
           Exception: Whatever draining raises; the loop is closed regardless.
         """
-        if self._loop.is_closed():
-            return
-        try:
-            self._loop.run_until_complete(self._drain())
-        finally:
-            self._loop.close()
+        with self._lock:
+            if self._loop.is_closed():
+                return
+            try:
+                self._loop.run_until_complete(self._drain())
+            finally:
+                self._loop.close()
 
     async def _publish_all(self, batch: list[dict[str, object]]) -> None:
         """Publishes each event, isolating a per-event failure.

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/sinks/postgres.py

@@ -125,6 +125,10 @@ class PostgresSink:
         if not batch:
             return
         with self._lock:
+            if self._closed:
+                raise SinkDeliveryError(
+                    f"PostgresSink inserted none of {len(batch)} event(s): the sink is closed"
+                )
             self._insert_batch(batch)
 
     def _insert_batch(self, batch: list[dict[str, object]]) -> None:
@@ -183,10 +187,10 @@ class PostgresSink:
         with self._lock:
             if self._closed:
                 return
+            self._closed = True
             self._conn.commit()
             if self._owns_connection:
                 self._conn.close()
-            self._closed = True
 
     def _row(self, event: dict[str, object]) -> tuple[object, ...]:
         """Builds one row: the extracted columns, then the whole event as JSON.

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/sinks/pubsub.py

@@ -18,6 +18,15 @@ class GooglePubSubSink:
     This is a durable-buffer sink on ``google-cloud-pubsub``, the optional ``gcp-pubsub`` extra,
     imported lazily. ``publish()`` returns a future that resolves asynchronously, so the sink
     accumulates the batch's futures and resolves them on :meth:`close`.
+
+    The driver requirement satisfied (SPEC-028 FR-002): this sink takes **no** transport lock —
+    the publisher client owns its own batching and threading, and ``publish()`` is a local
+    hand-off. What it does hold is the pending-futures list, which is genuinely shared between
+    ``emit`` (appending) and ``close`` (resolving), so that list has its own small lock and
+    ``close`` swaps it out rather than iterating and clearing. Without the swap, a future
+    appended after the loop passed its index was dropped unresolved: an unconfirmed publish
+    never counted in ``failed`` and never reported by :meth:`losses`, which is precisely the
+    silent loss SPEC-026 exists to end.
     """
 
     def __init__(self, topic: str, *, client: Any = None) -> None:
@@ -42,6 +51,7 @@ class GooglePubSubSink:
         self.failed = 0
         self.rejected = 0
         self._counter_lock = threading.Lock()
+        self._futures_lock = threading.Lock()
         self._futures: list[Any] = []
 
     def losses(self) -> SinkLosses:
@@ -88,7 +98,8 @@ class GooglePubSubSink:
                     self.rejected += 1
                 _diag.lost("event", 1, f"GooglePubSubSink refused the publish, {type(err).__name__}")
                 continue
-            self._futures.append(future)
+            with self._futures_lock:
+                self._futures.append(future)
             published += 1
         if batch and not published:
             raise SinkDeliveryError(
@@ -98,7 +109,12 @@ class GooglePubSubSink:
     def close(self) -> None:
         """Resolves all pending publish futures, counting and logging errors (FR-008).
 
-        Idempotent.
+        Idempotent. The pending list is swapped out under a lock rather than iterated and then
+        cleared (SPEC-028 FR-002): ``emit`` appends to it from any thread, so the old
+        iterate-then-``clear()`` discarded any future appended after the loop passed its index —
+        an unconfirmed publish whose ``result()`` was never called, never counted in ``failed``
+        and never reported by ``losses()``. That is the silent loss SPEC-026 exists to end,
+        reached through the one piece of shared state this sink has.
 
         Args:
           None.
@@ -110,7 +126,9 @@ class GooglePubSubSink:
           None. This is an isolation boundary: an unresolved future must never crash the worker
             (FR-011).
         """
-        for future in self._futures:
+        with self._futures_lock:
+            pending, self._futures = self._futures, []
+        for future in pending:
             try:
                 future.result()
             except Exception as err:
@@ -119,4 +137,3 @@ class GooglePubSubSink:
                 _diag.lost(
                     "event", 1, f"GooglePubSubSink publish unconfirmed, {type(err).__name__}"
                 )
-        self._futures.clear()

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/sinks/rabbitmq.py

@@ -73,6 +73,8 @@ class RabbitMQSink:
         self._properties: Any = None
         self.failed = 0
         self._counter_lock = threading.Lock()
+        self._lock = threading.Lock()
+        self._closed = False
 
     def losses(self) -> SinkLosses:
         """Reports messages abandoned past the reconnect-retry bound (SPEC-026 FR-002).
@@ -95,6 +97,12 @@ class RabbitMQSink:
         A partial publish is counted and left alone: retrying it would re-publish the messages
         already on the exchange.
 
+        The driver requirement satisfied (SPEC-028 FR-002): ``pika`` states that one connection
+        must not be shared across threads, and this sink shares one connection, one channel, and
+        *rebinds* both — ``_reset`` closes and nulls the channel another thread may be mid-publish
+        on. It is structurally the same sink as ``SocketTransport``, one AMQP frame stream over
+        one socket, so it takes the same lock.
+
         Args:
           batch: The events to publish.
 
@@ -103,12 +111,23 @@ class RabbitMQSink:
 
         Raises:
           SinkDeliveryError: When no message reached the broker (SPEC-026 FR-001) — a down broker
-            is the case the worker's retry and ``failed_batches`` exist for.
+            is the case the worker's retry and ``failed_batches`` exist for. Also when the sink
+            is already closed, which is not fussiness: ``_active_channel`` reopens a connection
+            whenever it finds none, and ``close`` is now idempotent, so an emit arriving after a
+            shutdown would open an AMQP connection that nothing will ever reap. One
+            ``log_foundry.info()`` after ``shutdown()`` reaches this on the caller's own thread.
         """
+        if not batch:
+            return
         published = 0
-        for event in batch:
-            if self._publish(json.dumps(event).encode("utf-8")):
-                published += 1
+        with self._lock:
+            if self._closed:
+                raise SinkDeliveryError(
+                    f"RabbitMQSink published none of {len(batch)} message(s): the sink is closed"
+                )
+            for event in batch:
+                if self._publish(json.dumps(event).encode("utf-8")):
+                    published += 1
         if batch and not published:
             raise SinkDeliveryError(f"RabbitMQSink published none of {len(batch)} message(s)")
 
@@ -126,12 +145,16 @@ class RabbitMQSink:
         Raises:
           None.
         """
-        if self._channel is not None:
-            _safe_close(self._channel)
-            self._channel = None
-        if self._connection is not None:
-            _safe_close(self._connection)
-            self._connection = None
+        with self._lock:
+            if self._closed:
+                return
+            self._closed = True
+            if self._channel is not None:
+                _safe_close(self._channel)
+                self._channel = None
+            if self._connection is not None:
+                _safe_close(self._connection)
+                self._connection = None
 
     def _publish(self, body: bytes) -> bool:
         """Publishes one message within the retry bound.

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/sinks/redis.py

@@ -21,6 +21,13 @@ class _RedisSink:
     The module is named ``redis`` to match the extra and imports the driver lazily, so it never
     shadows or requires the real package at import time. The worst-case delay (SPEC-027 FR-005)
     is ``max_retries`` interruptible waits per batch, 0.7 s at the defaults.
+
+    The driver requirement satisfied (SPEC-028 FR-002): this sink takes **no** transport
+    lock. ``redis-py`` documents that a client may be shared between threads — a
+    connection is taken from its pool only for the duration of a command, and command
+    execution never mutates the client. Its documented exceptions are ``PubSub`` and
+    ``Pipeline`` objects, which must not be passed between threads — which is why the pipeline
+    here is built and executed inside a single ``emit`` call and never stored on the instance.
     """
 
     def __init__(self, *, client: Any, url: str | None, max_retries: int) -> None:

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/sinks/sentry.py

@@ -33,6 +33,11 @@ class SentrySink:
       skipped: Events below the minimum level, or without a usable level, that were not sent.
       transport_errors: Events whose send raised something other than an already-counted
         abandonment — an SDK fault, or a response error ``HTTPSink`` does not retry.
+
+    The driver requirement satisfied (SPEC-028 FR-002): this sink takes **no** transport
+    lock. This sink owns no transport: it delegates to a ``sentry_sdk`` built for capture from any
+    thread, or to an ``HTTPSink`` that builds a fresh request per call and rebinds nothing.
+    Its counters take the counter lock like every other sink's.
     """
 
     def __init__(

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/sinks/sns.py

@@ -25,6 +25,10 @@ class SNSSink:
 
     The worst-case delay (SPEC-027 FR-005) is ``max_retries`` waits per chunk, 0.7 s at the
     defaults. The waits are interruptible, so ``shutdown()`` cuts one short.
+
+    The driver requirement satisfied (SPEC-028 FR-002): this sink takes **no** transport
+    lock. ``boto3`` clients are documented thread-safe, this one is built once in
+    ``__init__``, and the sink rebinds nothing after construction.
     """
 
     MAX_BATCH = 10

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/sinks/sqlite.py

@@ -7,6 +7,7 @@ import sqlite3
 import threading
 
 from log_foundry.sinks._chunk import valid_identifier
+from log_foundry.sinks.base import SinkDeliveryError
 
 __all__ = ["SQLiteSink"]
 
@@ -78,8 +79,9 @@ class SQLiteSink:
 
         ``with connection`` opens a transaction and commits on success or rolls back on error,
         so the whole batch lands atomically. The lock holds that transaction to one thread
-        (SPEC-028 FR-002); the row-building above it needs no protection, but sits inside for
-        simplicity and costs nothing an uncontended lock does not.
+        (SPEC-028 FR-002). Row-building is deliberately *outside* it: those lines touch nothing
+        shared, so serializing the ``json.dumps`` of a whole batch would lengthen the critical
+        section for no gain.
 
         Args:
           batch: The events to insert.
@@ -89,13 +91,44 @@ class SQLiteSink:
 
         Raises:
           sqlite3.Error: If the insert fails.
+          SinkDeliveryError: If the sink is closed — whether the close landed while this call
+            was building its rows, or long before it. Either way the batch would otherwise reach
+            the driver as "Cannot operate on a closed database", and the library has a word of
+            its own for "none of this was delivered" (SPEC-026 FR-001). What the library should
+            *signal* about logging after a completed shutdown is a separate question, and
+            SPEC-030's; this only keeps driver internals out of the answer.
         """
+        if not batch:
+            return
         rows = [
             (*(event.get(col) for col in _COLUMNS), json.dumps(event)) for event in batch
         ]
         placeholders = ", ".join("?" * (len(_COLUMNS) + 1))
         columns = ", ".join((*_COLUMNS, "event"))
-        with self._lock, self._conn:
+        with self._lock:
+            if self._closed:
+                raise SinkDeliveryError(
+                    f"SQLiteSink inserted none of {len(batch)} event(s): the sink is closed"
+                )
+            self._insert(rows, columns, placeholders)
+
+    def _insert(
+        self, rows: list[tuple[object, ...]], columns: str, placeholders: str
+    ) -> None:
+        """Runs the insert transaction, with the emit lock already held.
+
+        Args:
+          rows: The prepared row tuples.
+          columns: The comma-separated column list.
+          placeholders: The matching parameter placeholders.
+
+        Returns:
+          None.
+
+        Raises:
+          sqlite3.Error: If the insert fails.
+        """
+        with self._conn:
             self._conn.executemany(
                 f'INSERT INTO "{self._table}" ({columns}) VALUES ({placeholders})', rows
             )
@@ -118,10 +151,10 @@ class SQLiteSink:
         with self._lock:
             if self._closed:
                 return
+            self._closed = True
             self._conn.commit()
             if self._owns_connection:
                 self._conn.close()
-            self._closed = True
 
     def _ensure_schema(self) -> None:
         """Idempotently creates the target table.

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/sinks/sqs.py

@@ -84,6 +84,13 @@ class SQSSink:
 
     The worst-case delay (SPEC-027 FR-005) is ``max_retries`` waits per chunk, 0.7 s at the
     defaults. The waits are interruptible, so ``shutdown()`` cuts one short.
+
+    The driver requirement satisfied (SPEC-028 FR-002): this sink takes **no** transport
+    lock. ``boto3`` documents that clients — unlike Sessions and Resources — are
+    thread-safe, and this sink builds its client once in ``__init__`` rather than inside
+    ``emit`` — which is what keeps it clear of the documented caveat that calling
+    ``boto3.client()`` concurrently can produce response-ordering faults. Nothing else here is
+    rebound after construction.
     """
 
     MAX_BATCH = 10

{log_foundry-0.10.2.dev24 → log_foundry-0.10.2.dev25}/src/log_foundry/worker.py

@@ -395,9 +395,22 @@ class Worker:
         it, and ``atexit`` plus user code calling it at once is documented as normal.
 
         ``is_alive()`` is the safety condition rather than a heuristic: it reads ``False`` only
-        after ``_run`` has returned, so the sink is provably out of use. The close itself runs
-        outside the lock, because it can reach ``_diag`` and a wedged console must not stall a
-        lock :meth:`submit` also takes.
+        after ``_run`` has returned, so the sink is provably out of use *by the worker*.
+
+        The close runs to completion, inline, and is deliberately **not** bounded — which leaves
+        one honest gap. SPEC-028 made ``close()`` take the sink's emit lock, so an application
+        thread on the orphan path can hold that lock inside a driver call with no timeout of its
+        own and delay this past ``shutdown``'s budget. Running the close on a joinable daemon
+        thread was tried and reverted: at interpreter exit the daemon is killed wherever it has
+        reached, which for ``SQLiteSink`` is between ``commit()`` and ``close()`` — turning the
+        leaked handle SPEC-027 FR-004 accepts into the partial write it was avoiding. It also
+        could not tell a slow-but-successful close from a stuck one, so it reported
+        ``ShutdownTimeout`` and "left open" for closes that had in fact completed, latching
+        SPEC-019's alert term on a healthy shutdown. A wrong signal is worse than a slow one.
+        The residual delay is recorded in ``architecture.md`` §13 rather than papered over.
+
+        The close runs outside the lock, because it can reach ``_diag`` and a wedged console must
+        not stall a lock :meth:`submit` also takes.
 
         Args:
           None.
@@ -406,7 +419,9 @@ class Worker:
           None.
 
         Raises:
-          None.
+          BaseException: Whatever the sink's ``close`` raised that is not an ``Exception``.
+            ``_close_sink`` absorbs ``Exception`` but lets a ``KeyboardInterrupt`` or
+            ``SystemExit`` through to the caller (SPEC-025 FR-004).
         """
         with self._lock:
             if self._sink_closed or self._thread.is_alive():