log-foundry 0.10.2.dev26__tar.gz → 0.10.2.dev28__tar.gz

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: log-foundry
-Version: 0.10.2.dev26
+Version: 0.10.2.dev28
 Summary: Generate logs for your console and JSON events for downstream consumption.
 License-Expression: MIT
 License-File: LICENSE
@@ -696,7 +696,7 @@ in `CallbackSink`.
 
 #### Writing your own sink
 
-`Sink` is two required methods, `emit(batch)` and `close()`, plus two rules about *how* `emit`
+`Sink` is two required methods, `emit(batch)` and `close()`, plus three rules about *how* `emit`
 fails and one about *when* it is called. They are not stylistic — the library's whole
 loss-reporting apparatus is built on them:
 
@@ -716,6 +716,15 @@ loss-reporting apparatus is built on them:
 - **Do not raise when you delivered some of it.** The worker retries whole batches, so raising on a
   partial success re-delivers the records that already arrived, and duplicates downstream are worse
   than a counted loss.
+- **Raise after your own `close()`, if `close()` released anything.** A batch handed to a
+  released transport has delivered nothing, so it is the first rule again by another route — and
+  it is easy to miss, because the sink looks like it worked. Three of the shipped sinks got this
+  wrong for four releases: one accepted a produce into a client buffer nothing would flush again,
+  one appended a delivery future nothing would resolve, and one transparently *reconnected*,
+  leaking a connection nothing would reap. Set the flag before you release, and read it in `emit`.
+  If your `close()` releases nothing — you open a fresh connection per request, or the client is
+  the caller's — then **keep accepting**: refusing a batch you would have delivered is loss you
+  invented. `emit([])` stays a no-op either way.
 
 A sink that absorbs a total failure and returns normally is a sink the worker believes: the retry
 never engages, `failed_batches` stays at zero, and `flush()` returns `True` while every event is
@@ -732,12 +741,19 @@ from log_foundry.sinks.base import SinkDeliveryError, SinkLosses
 class MySink:
     def __init__(self) -> None:
         self._dropped = self._failed = 0
+        self._closed = False
         self._lock = threading.Lock()          # transport state
         self._counter_lock = threading.Lock()  # counters only, never held across I/O
 
     def emit(self, batch: list[dict[str, object]]) -> None:
+        if not batch:
+            return
         delivered = 0
         with self._lock:                       # your connection, socket or stream
+            if self._closed:                   # refuse: nothing here can deliver it
+                raise SinkDeliveryError(
+                    f"MySink delivered none of {len(batch)} event(s): the sink is closed"
+                )
             for chunk in self._chunks(batch):
                 if self._send(chunk):          # your own bounded retry
                     delivered += len(chunk)
@@ -753,6 +769,9 @@ class MySink:
 
     def close(self) -> None:
         with self._lock:                       # never release under an active writer
+            if self._closed:                   # idempotent: atexit races your own cleanup
+                return
+            self._closed = True                # set the flag, *then* release
             ...
 ```
 

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/README.md

@@ -660,7 +660,7 @@ in `CallbackSink`.
 
 #### Writing your own sink
 
-`Sink` is two required methods, `emit(batch)` and `close()`, plus two rules about *how* `emit`
+`Sink` is two required methods, `emit(batch)` and `close()`, plus three rules about *how* `emit`
 fails and one about *when* it is called. They are not stylistic — the library's whole
 loss-reporting apparatus is built on them:
 
@@ -680,6 +680,15 @@ loss-reporting apparatus is built on them:
 - **Do not raise when you delivered some of it.** The worker retries whole batches, so raising on a
   partial success re-delivers the records that already arrived, and duplicates downstream are worse
   than a counted loss.
+- **Raise after your own `close()`, if `close()` released anything.** A batch handed to a
+  released transport has delivered nothing, so it is the first rule again by another route — and
+  it is easy to miss, because the sink looks like it worked. Three of the shipped sinks got this
+  wrong for four releases: one accepted a produce into a client buffer nothing would flush again,
+  one appended a delivery future nothing would resolve, and one transparently *reconnected*,
+  leaking a connection nothing would reap. Set the flag before you release, and read it in `emit`.
+  If your `close()` releases nothing — you open a fresh connection per request, or the client is
+  the caller's — then **keep accepting**: refusing a batch you would have delivered is loss you
+  invented. `emit([])` stays a no-op either way.
 
 A sink that absorbs a total failure and returns normally is a sink the worker believes: the retry
 never engages, `failed_batches` stays at zero, and `flush()` returns `True` while every event is
@@ -696,12 +705,19 @@ from log_foundry.sinks.base import SinkDeliveryError, SinkLosses
 class MySink:
     def __init__(self) -> None:
         self._dropped = self._failed = 0
+        self._closed = False
         self._lock = threading.Lock()          # transport state
         self._counter_lock = threading.Lock()  # counters only, never held across I/O
 
     def emit(self, batch: list[dict[str, object]]) -> None:
+        if not batch:
+            return
         delivered = 0
         with self._lock:                       # your connection, socket or stream
+            if self._closed:                   # refuse: nothing here can deliver it
+                raise SinkDeliveryError(
+                    f"MySink delivered none of {len(batch)} event(s): the sink is closed"
+                )
             for chunk in self._chunks(batch):
                 if self._send(chunk):          # your own bounded retry
                     delivered += len(chunk)
@@ -717,6 +733,9 @@ class MySink:
 
     def close(self) -> None:
         with self._lock:                       # never release under an active writer
+            if self._closed:                   # idempotent: atexit races your own cleanup
+                return
+            self._closed = True                # set the flag, *then* release
             ...
 ```
 

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/pyproject.toml

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

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/base.py

@@ -94,9 +94,25 @@ class Sink(Protocol):
         re-delivered wholesale by the worker's retry, and duplicates downstream are worse than
         the counted loss (SPEC-017 FR-004, SPEC-018). Report that through ``losses()`` instead.
 
+        **After ``close()`` has released or invalidated something, raise rather than absorb**
+        (SPEC-032 FR-002). This is the same obligation applied to the sink's own lifecycle
+        rather than the destination's: an absorbed batch is one the worker believes, so the
+        retry never engages, ``failed_batches`` stays at zero and ``flush()`` returns True while
+        the events are gone — reached not through a destination that is down but through a
+        transport the library itself has already let go. Three shipped sinks failed this rule
+        for four specs, in three different ways: a produce into a batch nothing would flush
+        again, a future nothing would resolve, and a client that quietly reconnected.
+
+        The converse is equally binding: a sink holding nothing to release **keeps accepting**.
+        ``close()`` on a sink that opens a fresh connection per request, or whose client belongs
+        to the caller, has invalidated nothing, so a later batch still delivers and refusing it
+        would be loss the library invented rather than loss it reported. Which of the two
+        applies is a property of the sink, so each shipped sink records its answer in its class
+        docstring and a test holds it to it.
+
         Args:
           batch: The events to ship. ``emit([])`` is a no-op and never raises, since an empty
-            batch has not failed to deliver.
+            batch has not failed to deliver — closed or not.
 
         Returns:
           None.
@@ -116,6 +132,12 @@ class Sink(Protocol):
         succeeding. Taking the same lock ``emit`` takes satisfies this; so does an idempotent
         guard checked under that lock.
 
+        The flag this sets is the one a later :meth:`emit` reads, so the two are one decision
+        rather than two (SPEC-032 FR-002). Set it *before* releasing anything: an emit arriving
+        during a release must be refused rather than handed a half-released transport. Make the
+        release idempotent for the same reason a second ``close()`` is expected at all —
+        ``atexit`` racing a caller's own cleanup is the documented case.
+
         Args:
           None.
 

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/callback.py

@@ -17,6 +17,11 @@ class CallbackSink:
     function, without writing a ``Sink`` implementation. Attributes are internal; the observable
     contract is that ``emit`` hands the batch to the callable unchanged and ``close`` invokes
     the close hook once when one was supplied.
+
+    It takes **no** transport lock (SPEC-028 FR-002) and **adds no post-close guard**
+    (SPEC-032 FR-003). Both decisions belong to the callable: this class holds nothing, and what
+    a hook releases is not knowable from here — a callable needing either guarantee must provide
+    it, exactly as a hand-written ``Sink`` implementation would.
     """
 
     def __init__(

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/datadog.py

@@ -16,6 +16,10 @@ class DatadogSink(HTTPSink):
 
     The batch goes as a JSON array to the region-specific intake with a ``DD-API-KEY`` header,
     each entry enriched with ``ddsource``, ``service`` and ``ddtags``.
+
+    It takes **no** transport lock (SPEC-028 FR-002) and **adds no post-close guard**
+    (SPEC-032 FR-003), for the reasons :class:`~log_foundry.sinks.http.HTTPSink` records: there
+    is no transport held and ``close()`` releases nothing.
     """
 
     def __init__(

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/elasticsearch.py

@@ -25,6 +25,10 @@ class ElasticsearchSink(HTTPSink):
       dropped_unadjudicated: Events whose outcome a ``_bulk`` response did not describe, because
         its ``items`` array did not line up with the batch sent. Abandoned rather than retried,
         for SPEC-018's reason: the request succeeded, so re-sending would duplicate what landed.
+
+    It takes **no** transport lock (SPEC-028 FR-002) and **adds no post-close guard**
+    (SPEC-032 FR-003), for the reasons :class:`~log_foundry.sinks.http.HTTPSink` records: there
+    is no transport held and ``close()`` releases nothing.
     """
 
     def __init__(self, url: str, *, index: str, auth: str | tuple[str, str] | None = None,

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/filtering.py

@@ -24,6 +24,10 @@ class FilteringSink:
     This is a static, emit-time filter in front of an inner sink, not the reserved
     tail-sampling ``should_send`` seam (arch §10) — that stays deferred and owns rate policy at
     span-decision time, while this only reshapes an already-built batch on its way to a sink.
+
+    It takes **no** transport lock (SPEC-028 FR-002) and **adds no post-close guard**
+    (SPEC-032 FR-003): it holds no transport and its ``close()`` only forwards, so both decisions
+    belong to the inner sink. A guard here would refuse batches the inner sink would have taken.
     """
 
     def __init__(

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/firehose.py

@@ -36,6 +36,10 @@ class FirehoseSink:
     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.
+
+    It also **adds no post-close guard** (SPEC-032 FR-003): ``close()`` is a documented no-op,
+    because the client is the caller's to release or the SDK's to reap, so a batch emitted
+    afterwards still reaches the delivery stream.
     """
 
     MAX_RECORDS = 500

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/honeycomb.py

@@ -14,6 +14,10 @@ class HoneycombSink(HTTPSink):
 
     The request goes to ``/1/batch/<dataset>`` with an ``X-Honeycomb-Team`` header, in
     Honeycomb's ``[{"data": <event>}, ...]`` batch shape.
+
+    It takes **no** transport lock (SPEC-028 FR-002) and **adds no post-close guard**
+    (SPEC-032 FR-003), for the reasons :class:`~log_foundry.sinks.http.HTTPSink` records: there
+    is no transport held and ``close()`` releases nothing.
     """
 
     def __init__(

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/http.py

@@ -74,6 +74,13 @@ class HTTPSink:
       failed: Requests abandoned past the retry bound.
       dropped_oversized: Events dropped for exceeding a destination's hard size limit, used by
         subclasses that enforce one; the generic core imposes no universal limit.
+
+    The two lifecycle decisions this class records, inherited by every platform subclass. It
+    takes **no** transport lock (SPEC-028 FR-002): there is no transport to guard, since
+    ``urllib`` opens a fresh connection per request and nothing is rebound after construction.
+    And it **adds no post-close guard** (SPEC-032 FR-003), because ``close()`` releases nothing —
+    a batch emitted afterwards still reaches the endpoint, and refusing it would be loss the
+    library invented rather than loss it reported.
     """
 
     def __init__(

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/kafka.py

@@ -28,6 +28,12 @@ class KafkaSink:
     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.
+
+    It refuses an emit after :meth:`close` (SPEC-032 FR-001), which is not the housekeeping it
+    looks like: ``flush()`` is the only thing that drains the producer's local batch and services
+    its delivery callbacks, so a message produced after it dies with the process — accepted,
+    uncounted, and never the subject of a callback. ``emit`` returning normally is what made that
+    silent, since the worker then never retried and ``flush()`` reported success.
     """
 
     def __init__(
@@ -67,6 +73,8 @@ class KafkaSink:
         self.failed = 0
         self.rejected = 0
         self._counter_lock = threading.Lock()
+        self._closed = False
+        self._close_lock = threading.Lock()
 
     def losses(self) -> SinkLosses:
         """Reports refused and undelivered messages (SPEC-026 FR-002).
@@ -98,6 +106,15 @@ class KafkaSink:
         observe (FR-002). A partial refusal is counted and left alone, since the messages that
         were accepted are already on their way.
 
+        A closed sink refuses the batch before touching the producer (SPEC-032 FR-001). Refusing
+        is not a loss this sink absorbed, so it moves no counter here: it is a failure reported
+        to the worker, which records it in ``health().failed_batches``. The check is an unlocked
+        read of a write-once flag rather than a lock held across the produce loop, which would
+        serialize a client ``confluent-kafka`` documents as thread-safe. A close landing between
+        the check and the produce therefore still loses that message, exactly as ``MongoDBSink``
+        documents for its own check; what the flag ends is the far larger case of a sink closed
+        long before, which is every log written after ``shutdown()``.
+
         Args:
           batch: The events to produce.
 
@@ -105,9 +122,16 @@ class KafkaSink:
           None.
 
         Raises:
-          SinkDeliveryError: When every message was refused, so the batch reached nothing —
-            the total failure the worker's retry exists for (SPEC-026 FR-001).
+          SinkDeliveryError: When the sink is closed, or when every message was refused so the
+            batch reached nothing — the total failure the worker's retry exists for
+            (SPEC-026 FR-001).
         """
+        if not batch:
+            return
+        if self._closed:
+            raise SinkDeliveryError(
+                f"KafkaSink produced none of {len(batch)} message(s): the sink is closed"
+            )
         accepted = 0
         for event in batch:
             body = json.dumps(event).encode("utf-8")
@@ -127,6 +151,17 @@ class KafkaSink:
     def close(self) -> None:
         """Flushes the producer so buffered messages are delivered before exit (FR-002).
 
+        Idempotent, and the lock is held *across* the flush rather than only around the flag, as
+        every other guarded sink holds its own (SPEC-032 FR-001). Releasing it early would let a
+        second concurrent ``close()`` return while the first is still draining, so a caller would
+        believe the producer was flushed when it was not — and ``atexit`` racing user cleanup is
+        the documented case for a second call. The cost is that a second close waits on an
+        unreachable broker, which is the ``architecture.md`` §13 constraint that already applies
+        to every sink here.
+
+        The flag is set *before* the flush rather than after, so an emit arriving during a flush
+        is refused rather than producing into a batch the flush has already walked past.
+
         Args:
           None.
 
@@ -136,7 +171,11 @@ class KafkaSink:
         Raises:
           Exception: Whatever the producer raises on flush.
         """
-        self.producer.flush()
+        with self._close_lock:
+            if self._closed:
+                return
+            self._closed = True
+            self.producer.flush()
 
     def _key(self, event: dict[str, object]) -> bytes | None:
         """Derives one message's partition key from the configured field.

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/kinesis.py

@@ -36,6 +36,10 @@ class KinesisSink:
     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.
+
+    It also **adds no post-close guard** (SPEC-032 FR-003): ``close()`` is a documented no-op,
+    because the client is the caller's to release or the SDK's to reap, so a batch emitted
+    afterwards still reaches the stream.
     """
 
     MAX_RECORDS = 500

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/logging_sink.py

@@ -36,6 +36,11 @@ class LoggingSink:
     no new dependency. The sink only emits into that pipeline: it never configures loggers,
     handlers or formatters, and never tears the framework down. The module is named
     ``logging_sink`` so it never shadows the stdlib module.
+
+    It takes **no** transport lock (SPEC-028 FR-002): ``logging`` serializes its own handlers,
+    and this sink holds nothing else. And it **adds no post-close guard** (SPEC-032 FR-003) —
+    ``close()`` is a no-op by design, since tearing down handlers this sink did not configure is
+    not its to do, so a later batch still reaches the framework.
     """
 
     def __init__(

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/logstash.py

@@ -23,6 +23,14 @@ class LogstashSink:
     one newline-terminated line over a raw TCP or UDP socket, reusing
     :class:`~log_foundry.sinks._socket.SocketTransport`. Either backend handles its own bounded
     retry and raises on total failure of its own accord, so ``emit`` needs no rule of its own.
+
+    It takes **no** transport lock (SPEC-028 FR-002) of its own: whichever backend it built owns
+    that decision — ``SocketTransport`` locks its sends, ``HTTPSink`` holds no transport to
+    guard. The post-close rule follows the same split (SPEC-032 FR-004), and the two modes
+    genuinely differ: in socket mode a batch after ``close()`` is refused with
+    ``SinkDeliveryError`` and reopens nothing, while in HTTP mode ``close()`` released nothing
+    and the batch still ships. Both are the backend's answer, correctly, rather than one this
+    class invents on top.
     """
 
     def __init__(

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/loki.py

@@ -18,6 +18,10 @@ class LokiSink(HTTPSink):
     Events are grouped into streams by a configurable set of label keys, each stream carrying
     values of ``[<nanosecond_timestamp_str>, <log_line>]``. Timestamps are derived by parsing the
     event's ISO-8601 ``timestamp``, falling back to emit-time now.
+
+    It takes **no** transport lock (SPEC-028 FR-002) and **adds no post-close guard**
+    (SPEC-032 FR-003), for the reasons :class:`~log_foundry.sinks.http.HTTPSink` records: there
+    is no transport held and ``close()`` releases nothing.
     """
 
     def __init__(self, url: str, *, labels: tuple[str, ...] = ("service", "env", "level"),

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/multi.py

@@ -29,6 +29,13 @@ class MultiSink:
         batch, so one batch against an all-down fan-out of *n* children increments this by *n*
         per attempt, with a stderr line each. That is the visible cost of the loss no longer
         being silent.
+
+    It takes **no** transport lock (SPEC-028 FR-002) — it holds no transport, and a lock spanning
+    a child's ``emit`` would serialize every destination behind the slowest one. And it
+    **adds no post-close guard** (SPEC-032 FR-003), because the post-close rule is each child's:
+    ``close()`` here only forwards, so a guard added at this level would refuse batches the
+    children would have taken, while a child that must refuse already does and is counted here
+    like any other failure.
     """
 
     def __init__(self, *sinks: Sink) -> None:

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/pubsub.py

@@ -27,6 +27,11 @@ class GooglePubSubSink:
     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.
+
+    That same loss was reachable from *outside* ``close`` until SPEC-032 FR-001: nothing stopped
+    a later ``emit`` appending to the fresh list, and nothing would ever call ``result()`` on
+    it. The sink now refuses a batch once closed, and the append re-checks under the futures
+    lock, so a publish cannot land on a list the swap has already taken.
     """
 
     def __init__(self, topic: str, *, client: Any = None) -> None:
@@ -53,6 +58,7 @@ class GooglePubSubSink:
         self._counter_lock = threading.Lock()
         self._futures_lock = threading.Lock()
         self._futures: list[Any] = []
+        self._closed = False
 
     def losses(self) -> SinkLosses:
         """Reports refused publishes and futures that resolved to an error (FR-002).
@@ -80,6 +86,26 @@ class GooglePubSubSink:
         the retry would duplicate them. The stderr line names which counter moved, since
         "refused" and "unconfirmed" mean different things.
 
+        A closed sink refuses the batch before touching the client (SPEC-032 FR-001), because
+        nothing will resolve a future appended after :meth:`close` swapped the list out.
+        Refusing moves no counter here: it is a failure reported to the worker, which records it
+        in ``health().failed_batches``, not loss this sink absorbed. The flag is read twice on
+        purpose — once for the batch, and again under ``_futures_lock`` for each append, which
+        is the lock ``close`` swaps under. Without the second read a close landing mid-loop
+        would leave exactly the orphaned future this guard exists to prevent, and the read costs
+        nothing because the append already takes that lock. Only the read happens under it: the
+        counter bump and the stderr line are taken *after* the lock is released, because
+        ``close`` waits on the same lock and a blocked stderr would otherwise hold it — an I/O
+        call inside a transport lock is what SPEC-028's two-lock decision exists to avoid.
+
+        A close that lands mid-batch does **not** raise, even when it catches every event. Each
+        one had ``publish()`` called on it and may well land, so raising would have the worker
+        re-send them and duplicate whatever did — the SPEC-018 rule that only a *provable*
+        non-delivery may be retried. They are counted as unconfirmed instead, which is exactly
+        what they are. That is why the total-failure raise below tests the refusals rather than
+        the successes: "nothing was published" and "nothing was confirmed" are different claims,
+        and only the first is safe to retry.
+
         Args:
           batch: The events to publish.
 
@@ -87,21 +113,36 @@ class GooglePubSubSink:
           None.
 
         Raises:
-          SinkDeliveryError: When every event was refused (SPEC-026 FR-001).
+          SinkDeliveryError: When the sink was already closed on entry, or when every event was
+            refused (SPEC-026 FR-001).
         """
-        published = 0
+        if not batch:
+            return
+        if self._closed:
+            raise SinkDeliveryError(
+                f"GooglePubSubSink published none of {len(batch)} event(s): the sink is closed"
+            )
+        refused = 0
         for event in batch:
             try:
                 future = self.client.publish(self.topic, data=json.dumps(event).encode("utf-8"))
             except Exception as err:
+                refused += 1
                 with self._counter_lock:
                     self.rejected += 1
                 _diag.lost("event", 1, f"GooglePubSubSink refused the publish, {type(err).__name__}")
                 continue
             with self._futures_lock:
-                self._futures.append(future)
-            published += 1
-        if batch and not published:
+                orphaned = self._closed
+                if not orphaned:
+                    self._futures.append(future)
+            if orphaned:
+                with self._counter_lock:
+                    self.failed += 1
+                _diag.lost(
+                    "event", 1, "GooglePubSubSink publish unconfirmed, the sink closed mid-batch"
+                )
+        if refused == len(batch):
             raise SinkDeliveryError(
                 f"GooglePubSubSink published none of {len(batch)} event(s)"
             )
@@ -116,6 +157,12 @@ class GooglePubSubSink:
         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.
 
+        The closed flag is set in the same critical section as the swap (SPEC-032 FR-001), which
+        is what makes :meth:`emit`'s second check exact: an append winning the lock before this
+        point is resolved by the loop below, and one arriving after sees the flag. The futures
+        are resolved outside the lock, so a slow ``result()`` never blocks an emit that is about
+        to be refused anyway.
+
         Args:
           None.
 
@@ -127,6 +174,7 @@ class GooglePubSubSink:
             (FR-011).
         """
         with self._futures_lock:
+            self._closed = True
             pending, self._futures = self._futures, []
         for future in pending:
             try:

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/redis.py

@@ -28,6 +28,12 @@ class _RedisSink:
     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.
+
+    It refuses an emit after :meth:`close` (SPEC-032 FR-001). Left unguarded this sink did not
+    fail after close, it *succeeded*: ``redis-py``'s pool reconnects transparently on the next
+    command, so a batch emitted after ``shutdown()`` opened a connection nothing would ever
+    reap — the same leak SPEC-028's review found in ``RabbitMQSink``, whose ``_active_channel``
+    reopened whatever ``close()`` had released.
     """
 
     def __init__(self, *, client: Any, url: str | None, max_retries: int) -> None:
@@ -56,6 +62,8 @@ class _RedisSink:
         self.stop_signal: threading.Event | None = None
         self.failed = 0
         self._counter_lock = threading.Lock()
+        self._closed = False
+        self._close_lock = threading.Lock()
 
     def losses(self) -> SinkLosses:
         """Reports events abandoned past the retry bound (SPEC-026 FR-002).
@@ -75,6 +83,13 @@ class _RedisSink:
     def emit(self, batch: list[dict[str, object]]) -> None:
         """Pipelines the whole batch into one round trip, retrying on error (FR-005).
 
+        A closed sink refuses the batch before asking for a pipeline (SPEC-032 FR-001), since
+        asking would silently reopen the connection ``close()`` released. The refusal does not
+        depend on whether the sink owned the client: a borrowed client surviving its sink is the
+        caller's business, and is not permission to keep writing through a sink that has been
+        released. Refusing moves no counter here — it is a failure reported to the worker, which
+        records it in ``health().failed_batches``, not loss this sink absorbed.
+
         Args:
           batch: The events to buffer. An empty batch is a no-op.
 
@@ -82,13 +97,18 @@ class _RedisSink:
           None.
 
         Raises:
-          SinkDeliveryError: When the retry bound is spent. The batch travels as one pipeline,
-            so such a failure delivered nothing: it is counted and then raised, giving the worker
-            its retry and ``health()`` the loss (SPEC-026 FR-001). There is no partial case to
-            protect, because the pipeline is all or nothing.
+          SinkDeliveryError: When the sink is closed. Also when the retry bound is spent: the
+            batch travels as one pipeline, so such a failure delivered nothing: it is counted and
+            then raised, giving the worker its retry and ``health()`` the loss (SPEC-026 FR-001).
+            There is no partial case to protect, because the pipeline is all or nothing.
         """
         if not batch:
             return
+        if self._closed:
+            raise SinkDeliveryError(
+                f"{type(self).__name__} delivered none of {len(batch)} event(s): "
+                "the sink is closed"
+            )
         for attempt in range(self.max_retries + 1):
             try:
                 pipe = self.client.pipeline()
@@ -114,6 +134,11 @@ class _RedisSink:
     def close(self) -> None:
         """Closes the connection only if the sink owns it (FR-005).
 
+        Idempotent, with the flag set under a lock so two concurrent calls cannot both reach
+        ``client.close()`` — ``atexit`` racing user code is the documented case. The flag is set
+        whether or not the client is owned, because it marks *this sink* as released rather than
+        the connection (SPEC-032 FR-001).
+
         Args:
           None.
 
@@ -123,8 +148,12 @@ class _RedisSink:
         Raises:
           Exception: Whatever the client raises on close.
         """
-        if self._owns_client:
-            self.client.close()
+        with self._close_lock:
+            if self._closed:
+                return
+            self._closed = True
+            if self._owns_client:
+                self.client.close()
 
     def _stage(self, pipe: Any, event: dict[str, object]) -> None:
         """Stages one event onto the pipeline, in whatever form the subclass writes.

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/sentry.py

@@ -38,6 +38,9 @@ class SentrySink:
     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.
+
+    It also **adds no post-close guard** (SPEC-032 FR-003), for the same reason: neither backend
+    holds anything ``close()`` releases, so a batch emitted afterwards still reaches Sentry.
     """
 
     def __init__(
@@ -120,9 +123,12 @@ class SentrySink:
             )
 
     def close(self) -> None:
-        """Releases the HTTP fallback resource, if any (FR-012).
+        """Forwards to the HTTP fallback, whose own close releases nothing (FR-012).
 
-        Idempotent.
+        Idempotent, and it releases nothing — which is why the class docstring's post-close claim
+        holds despite this method calling a ``close()``. ``HTTPSink.close`` is a documented no-op,
+        since ``urllib`` builds a fresh connection per request; the forward exists so a future
+        ``HTTPSink`` that *did* hold a pool would be released here rather than leaked.
 
         Args:
           None.

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/sns.py

@@ -29,6 +29,10 @@ class SNSSink:
     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.
+
+    It also **adds no post-close guard** (SPEC-032 FR-003): ``close()`` is a documented no-op,
+    because the client is the caller's to release or the SDK's to reap, so a batch emitted
+    afterwards still reaches the topic.
     """
 
     MAX_BATCH = 10

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/splunk.py

@@ -17,6 +17,10 @@ class SplunkHECSink(HTTPSink):
     concatenated-JSON-objects body with an ``Authorization: Splunk <token>`` header. The
     envelope's epoch-seconds ``time`` is parsed from the event's ISO-8601 ``timestamp``, falling
     back to emit-time now.
+
+    It takes **no** transport lock (SPEC-028 FR-002) and **adds no post-close guard**
+    (SPEC-032 FR-003), for the reasons :class:`~log_foundry.sinks.http.HTTPSink` records: there
+    is no transport held and ``close()`` releases nothing.
     """
 
     def __init__(

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/sqs.py

@@ -91,6 +91,10 @@ class SQSSink:
     ``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.
+
+    It also **adds no post-close guard** (SPEC-032 FR-003): ``close()`` is a documented no-op,
+    because the client is the caller's to release or the SDK's to reap, so a batch emitted
+    afterwards still reaches the queue.
     """
 
     MAX_BATCH = 10

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/stdout.py

@@ -14,6 +14,18 @@ class StdoutSink:
 
     This is the zero-dependency default sink, for local dev and container log scraping. Like
     every sink it receives already-built event dicts and knows nothing about spans or context.
+
+    It takes **no** transport lock (SPEC-028 FR-002), and the honest reason is that locking it
+    was out of scope there rather than that it needs none: ``emit`` writes one line per event, so
+    two threads' *batches* do interleave, exactly as they did in ``FileSink`` before its lock.
+    Individual lines survive — ``TextIOWrapper.write`` holds its own lock — but line integrity is
+    not the guarantee at stake, as ``test_file_sink_keeps_each_batch_contiguous_under_concurrent
+    _emitters`` records. Interleaved batches are harmless in a line-oriented stream that a
+    scraper reads per line, which is what this sink is for; a caller needing contiguity should
+    use ``FileSink``.
+
+    It **adds no post-close guard** (SPEC-032 FR-003), because ``close()`` only flushes — the
+    stream belongs to the process, not to this sink, so a later batch still lands.
     """
 
     def __init__(self, stream: TextIO | None = None) -> None:

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/syslog.py

@@ -33,6 +33,12 @@ class SyslogSink:
     Each event becomes an RFC 5424 message whose ``PRI`` is derived from a configurable facility
     and a severity mapped from the event's level. UDP sends one datagram per event, TCP uses
     octet-counted framing (RFC 6587), and the whole sink is dependency-free.
+
+    It takes **no** transport lock (SPEC-028 FR-002) of its own: the socket it holds is a
+    :class:`~log_foundry.sinks._socket.SocketTransport`, which locks its own sends. Its
+    post-close refusal comes from there too (SPEC-032 FR-004) — a batch emitted after
+    ``close()`` reaches ``send_all`` and is refused with ``SinkDeliveryError`` without the
+    socket being reopened, so a guard here would only duplicate one that already holds.
     """
 
     def __init__(

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/transform.py

@@ -23,6 +23,10 @@ class TransformSink:
     rename keys — and returning ``None`` drops that event. The caller's batch and event dicts
     are never mutated in place: only the function's return values are forwarded, so a transform
     must copy before mutating.
+
+    It takes **no** transport lock (SPEC-028 FR-002) and **adds no post-close guard**
+    (SPEC-032 FR-003): it holds no transport and its ``close()`` only forwards, so both decisions
+    belong to the inner sink. A guard here would refuse batches the inner sink would have taken.
     """
 
     def __init__(

{log_foundry-0.10.2.dev26 → log_foundry-0.10.2.dev28}/src/log_foundry/sinks/util.py

@@ -43,6 +43,10 @@ class NullSink:
     what this sink is for, and reporting it as loss would make ``health()``'s alert idiom fire
     on every batch for anyone who chose this sink to turn logging off. The counter stays
     readable on the instance.
+
+    It takes **no** transport lock (SPEC-028 FR-002) and **adds no post-close guard**
+    (SPEC-032 FR-003): there is no transport and ``close()`` releases nothing, so discarding a
+    batch after close is the same operation as discarding one before it.
     """
 
     def __init__(self) -> None:
@@ -96,6 +100,10 @@ class MemorySink:
     eyeballing in a notebook. With ``maxlen`` set it behaves as a bounded ring, keeping only the
     most recent events; the list object identity is stable, so a held reference keeps seeing
     updates.
+
+    It takes **no** transport lock (SPEC-028 FR-002) and **adds no post-close guard**
+    (SPEC-032 FR-003): there is no transport, and ``close()`` releases nothing — a test that
+    closes the sink and then asserts on a later batch still sees it in ``.events``.
     """
 
     def __init__(self, maxlen: int | None = None) -> None: