log-foundry 0.10.2.dev113__tar.gz → 0.10.2.dev114__tar.gz

{log_foundry-0.10.2.dev113 → log_foundry-0.10.2.dev114}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: log-foundry
-Version: 0.10.2.dev113
+Version: 0.10.2.dev114
 Summary: Generate logs for your console and JSON events for downstream consumption.
 License-Expression: MIT
 License-File: LICENSE
@@ -1208,7 +1208,7 @@ Falsy carries a `reason` saying which of these happened, because they need diffe
 | `"retired"` | `shutdown()` was already called. Your lifecycle is wrong, not the sink. |
 | `"thread-died"` | The drain thread is gone; see `health().stopped_reason`. |
 | `"queue-full"` | Backpressure — the queue could not even accept the marker. |
-| `"abandoned"` | A batch was given up on after its retry budget. The destination is broken. |
+| `"abandoned"` | The drain that would have carried those events did not confirm delivery of them. A broken destination is one cause, but not the only one — an expiring bounded `shutdown()` answers waiting calls pessimistically, and the drain may still deliver afterwards. So this is not by itself evidence that anything was lost: `health()` is what says whether it was. |
 | `"sink-flush"` | Everything queued reached the sink, but the sink's own `flush()` raised — a client-side buffer that did not go out. Distinct from `"abandoned"`: the library delivered, the sink did not. |
 
 ```python

{log_foundry-0.10.2.dev113 → log_foundry-0.10.2.dev114}/README.md

@@ -1157,7 +1157,7 @@ Falsy carries a `reason` saying which of these happened, because they need diffe
 | `"retired"` | `shutdown()` was already called. Your lifecycle is wrong, not the sink. |
 | `"thread-died"` | The drain thread is gone; see `health().stopped_reason`. |
 | `"queue-full"` | Backpressure — the queue could not even accept the marker. |
-| `"abandoned"` | A batch was given up on after its retry budget. The destination is broken. |
+| `"abandoned"` | The drain that would have carried those events did not confirm delivery of them. A broken destination is one cause, but not the only one — an expiring bounded `shutdown()` answers waiting calls pessimistically, and the drain may still deliver afterwards. So this is not by itself evidence that anything was lost: `health()` is what says whether it was. |
 | `"sink-flush"` | Everything queued reached the sink, but the sink's own `flush()` raised — a client-side buffer that did not go out. Distinct from `"abandoned"`: the library delivered, the sink did not. |
 
 ```python

{log_foundry-0.10.2.dev113 → log_foundry-0.10.2.dev114}/pyproject.toml

@@ -74,7 +74,7 @@ keywords = [
 # vulnerability-reporting channel. The repository is still named `log-forge` — the ORIGINAL name,
 # which PyPI rejected for the distribution — so these URLs deliberately do not match the package
 # name. See the note on `name` above before "correcting" them.
-version = "0.10.2.dev113"
+version = "0.10.2.dev114"
 
 [project.urls]
 Homepage = "https://github.com/agriffi10/log-forge"