log-foundry 0.10.2.dev56__tar.gz → 0.10.2.dev57__tar.gz

{log_foundry-0.10.2.dev56 → log_foundry-0.10.2.dev57}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: log-foundry
-Version: 0.10.2.dev56
+Version: 0.10.2.dev57
 Summary: Generate logs for your console and JSON events for downstream consumption.
 License-Expression: MIT
 License-File: LICENSE
@@ -525,6 +525,20 @@ A few conventions hold across every sink below:
   The tables show the destination-defining arguments only; sinks that retry also take `max_retries`.
 - **Ownership.** A resource the sink opens itself is closed on `shutdown()`; an injected one is left
   open for you to manage.
+- **Forking.** A forked child repairs the library automatically — it rebuilds the worker so it keeps
+  delivering, re-initialises every lock (without which the child's *first* log call can deadlock),
+  and throws away any buffered bytes it inherited so they are not written twice. What it does **not**
+  do is give the child a sink of its own: the child inherits the same object, so one socket, one
+  SQLite handle or one file is now written by two processes — and *closed* by both, each at its own
+  exit. That is fine for an append-only file or a queue client and wrong for a connection with
+  transaction scope, where a close is protocol-visible. **Under gunicorn, uWSGI or Celery, build a
+  connection-holding sink only in the worker process** — `configure()` from gunicorn's `post_fork`
+  hook, never under preload, and don't log from the master. Reconfiguring in the child is *not* the
+  remedy and is worse than the problem: `configure(sink=...)` closes the sink it replaces, which
+  there is the parent's live connection. A master that must log should use a sink whose `close()`
+  costs nothing to share, such as `StdoutSink` or `FileSink`. A sink you wrote yourself is repaired
+  only if it subclasses `Sink` or a shipped sink; one that satisfies the protocol structurally is
+  outside the repair, along with any third-party client's own locks and buffers.
 - **Never crashes the app.** A broken destination degrades logging and nothing more. A sink that
   delivered *part* of a batch counts what it lost (`.failed`, `.dropped_oversized`,
   `.dropped_unadjudicated`, …) and returns, since retrying would re-deliver what already landed.

{log_foundry-0.10.2.dev56 → log_foundry-0.10.2.dev57}/README.md

@@ -489,6 +489,20 @@ A few conventions hold across every sink below:
   The tables show the destination-defining arguments only; sinks that retry also take `max_retries`.
 - **Ownership.** A resource the sink opens itself is closed on `shutdown()`; an injected one is left
   open for you to manage.
+- **Forking.** A forked child repairs the library automatically — it rebuilds the worker so it keeps
+  delivering, re-initialises every lock (without which the child's *first* log call can deadlock),
+  and throws away any buffered bytes it inherited so they are not written twice. What it does **not**
+  do is give the child a sink of its own: the child inherits the same object, so one socket, one
+  SQLite handle or one file is now written by two processes — and *closed* by both, each at its own
+  exit. That is fine for an append-only file or a queue client and wrong for a connection with
+  transaction scope, where a close is protocol-visible. **Under gunicorn, uWSGI or Celery, build a
+  connection-holding sink only in the worker process** — `configure()` from gunicorn's `post_fork`
+  hook, never under preload, and don't log from the master. Reconfiguring in the child is *not* the
+  remedy and is worse than the problem: `configure(sink=...)` closes the sink it replaces, which
+  there is the parent's live connection. A master that must log should use a sink whose `close()`
+  costs nothing to share, such as `StdoutSink` or `FileSink`. A sink you wrote yourself is repaired
+  only if it subclasses `Sink` or a shipped sink; one that satisfies the protocol structurally is
+  outside the repair, along with any third-party client's own locks and buffers.
 - **Never crashes the app.** A broken destination degrades logging and nothing more. A sink that
   delivered *part* of a batch counts what it lost (`.failed`, `.dropped_oversized`,
   `.dropped_unadjudicated`, …) and returns, since retrying would re-deliver what already landed.

{log_foundry-0.10.2.dev56 → log_foundry-0.10.2.dev57}/pyproject.toml

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