Flush before exit! so a job's last log lines are not discarded

[facundofarias]

Problem

The forked child ends with exit!(0):

result = perform_job(incoming_message.params)
result_handler = Leveret::ResultHandler.new(incoming_message)
result_handler.handle(result)                   # logs "Job returned ...", then acks

log.info "[...] Exiting child process #{pid}"
exit!(0)                                        # skips at_exit -- every buffer discarded

exit! is deliberate: it skips at_exit handlers registered in the parent and inherited across the fork, which must not run once per job. But it skips all of them, and every buffered write goes with them.

That silently discards the last lines a job writes — which are exactly the lines saying whether the job succeeded.

Evidence

This gem loses its own diagnostics. On one production host over two days:

line	written by	count
Forked to child ...	parent (exits normally, flushes)	4,769
Job returned ...	child (microseconds before exit!)	14

0.3%. log_file defaults to STDOUT, and a redirected STDOUT is block-buffered, so the child's lines are almost never written out. The log cannot answer the question it is most often asked — did that job succeed? — for virtually any job this gem has run.

That is also what makes the defect self-concealing: the missing lines are precisely the ones you go looking for.

It bites host applications the same way. A nightly sweep in our app logged its start and its every-2,000-records progress lines, but its completion line appeared once in thirty hours across thirteen runs. It was written up as a job that never finishes. It had been finishing all along. The false signal cost about two days of investigation and produced a written conclusion that was simply wrong.

Fix

Two changes, both immediately before exit!:

1. Configuration#before_child_exit — a hook mirroring the existing after_fork, so a host application can flush its own sinks (an HTTP log shipper, a metrics client):

Leveret.configure do |config|
  config.before_child_exit = proc { MyLogSink.flush! }
end

2. #flush_own_log — flushes this gem's own logger. This is plain IO buffering, reproducible with the default STDOUT configuration and no host application involvement, so it is fixed here rather than delegated to the hook.

Deliberate properties:

• Both run after the acknowledgement, so a hook that hangs can never cause redelivery.
• The hook is bounded by Worker::CHILD_EXIT_HOOK_TIMEOUT (5s) and rescued. An unreachable sink must never stop a child exiting, or forks accumulate until the host runs out of processes. A failed flush costs log lines; a wedged child costs the worker.
• The hook rescues Exception, not StandardError. Timeout::Error does not descend from StandardError on the rubies this gem supports, so a bare rescue StandardError would let precisely the timeout case escape and defeat the bound.
• flush_own_log runs last, so it also flushes whatever the hook logged, and rescues without reporting — reporting is what has just failed.

Default hook is proc {}, so behaviour is unchanged for anyone who does not set one.

Scope note — an unrelated one-line fix included

lib/leveret.rb now also requires forwardable and timeout.

Queue, Worker and DelayQueue all extend Forwardable, but nothing ever required it — so the gem's own spec suite could not load standalone (uninitialized constant Leveret::DelayQueue::Forwardable). Under Rails it only worked because ActiveSupport requires forwardable first.

I'd normally split this out, but the suite could not be run at all to verify the actual fix without it. Flagging it rather than burying it. timeout is required by the fix itself.

Testing

9 new examples: the hook is called; the default is a no-op; a raising hook is swallowed; a non-StandardError raising hook is swallowed; a hanging hook is abandoned rather than blocking the exit; our own log is still flushed when the hook blows up; the logger's IO is flushed; no raise when the logger exposes no flushable device; no raise when the flush itself fails.

spec/worker_spec.rb spec/configuration_spec.rb    12 examples, 0 failures

Full suite unchanged: 14 pre-existing failures before, 14 after (verified by stashing). Those are unrelated gem rot on modern RSpec/Ruby.

Backward compatibility

Additive. New config attribute with a no-op default; no existing behaviour changes. The only observable difference is that log lines which were previously discarded now appear.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Added a configurable hook that runs in worker child processes immediately before they exit.
  • Hook execution is limited to five seconds; errors are logged while allowing the worker to exit safely.
  • Worker log output is flushed before child processes exit when supported.

• Bug Fixes

  • Improved standalone loading by ensuring required runtime dependencies are available.

• Chores

  • Added automated testing through GitHub Actions across supported Ruby environments.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Essentials

Run ID: 6a98a3f3-c47e-41e0-a29c-1a41a9f68889

📥 Commits

Reviewing files that changed from the base of the PR and between 5c56b21 and c6fbb17.

📒 Files selected for processing (3)

• .github/workflows/ci.yml
• .travis.yml
• spec/spec_helper.rb

💤 Files with no reviewable changes (1)

• .travis.yml

Included review availability: 3 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 4 reviews per hour.

---

Walkthrough

The library now loads required dependencies explicitly. Configuration exposes a before_child_exit hook. Workers run the hook with a five-second timeout, rescue failures, flush logs, and then exit. CI now runs RSpec through GitHub Actions with RabbitMQ.

Changes

Child exit hook and CI

Layer / File(s)	Summary
Hook configuration and loading lib/leveret.rb, lib/leveret/configuration.rb, spec/configuration_spec.rb	The library requires forwardable and timeout. Leveret::Configuration exposes before_child_exit and defaults it to an empty Proc.
Child hook execution and validation lib/leveret/worker.rb, spec/worker_spec.rb	Worker runs the hook after acknowledgment, limits it to five seconds, rescues failures, flushes its logger when supported, and exits. Specs cover normal, failing, timing-out, and unsupported flush behavior.
CI and test environment updates .github/workflows/ci.yml, .travis.yml, spec/spec_helper.rb	GitHub Actions runs RSpec on Ruby 2.7 and Ruby 3.4 with RabbitMQ. The AMQP URL can come from LEVERET_AMQP_URL, and the Travis configuration is removed.

Priority: ⬇️ Low

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix

Sequence Diagram(s)

sequenceDiagram
  participant Worker
  participant Configuration
  participant before_child_exit
  participant Logger
  Worker->>Configuration: Read before_child_exit
  Worker->>before_child_exit: Run hook after acknowledgment
  before_child_exit-->>Worker: Complete or raise
  Worker->>Logger: Log rescued failure
  Worker->>Logger: Flush logger device
  Worker->>Worker: exit!(0)

Loading

Merge Risk: ⚪ Minimal · up to c6fbb

The CI broker credentials and AMQP configuration match the test setup, with no remaining merge-blocking issue identified.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: flushing worker output before child exit to prevent the final job log lines from being discarded.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/flush-before-child-exit

Warning

Git: CodeRabbit could not clone the repository, so clone-backed analysis was skipped and this review may be incomplete. Verify repository clone access, such as SSH credentials, before requesting another full review. If clone access is intentionally unavailable, use path_filters to narrow the review scope.

---

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-16T06:32:37.661927Z	e4643c7	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e4643c7ccc

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[thdurante]

Good catch!