chore(deps): update dependency karafka to v2.6.1

[coipond-renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
karafka (source, changelog)	2.6.0 → 2.6.1

---

Release Notes

karafka/karafka (karafka)

v2.6.1

Compare Source

• [Feature] [Pro] Add an opt-in envelope encryption mode for Messages At Rest encryption (config.encryption.mode = :envelope, requires the openssl gem >= 3.0). It removes the RSA payload size ceiling of the default :direct mode (~245 bytes for 2048-bit keys) by encrypting each message with a one-time RSA-wrapped AES-256-GCM key. Both formats are recognized automatically on decryption, so data already at rest stays readable with no migration. Deployment: upgrade all consuming processes before enabling - older versions cannot decrypt envelope payloads, while upgraded consumers read both formats and keep producing :direct until switched, so the rollout can be staged safely. The default will switch to :envelope in a future release with prior notice; the :direct format stays decryptable indefinitely as data at rest never expires. Cipher key material is now pre-parsed (warmed) during setup - this introduces no new boot failure modes, as the configuration contract has always parsed and validated all configured keys at boot.
• [Fix] [Pro] Add a missing comma in the filtering strategy's unsupported-action guard so it raises Karafka::Errors::UnsupportedCaseError instead of a NoMethodError.
• [Fix] [Pro] Evict scheduled messages from the daily buffer per confirmed flush chunk instead of only after the whole flush. A broker error partway through a multi-chunk flush left the already-produced chunks in the buffer, re-dispatching them on the next tick (a duplicate window for non-transactional producers). Chunk size is now rounded up to even before shifting off the buffer, so a message's target and its own tombstone (always buffered as an adjacent pair) can no longer land in different chunks - with an odd or 1 flush_batch_size, the target's chunk could confirm and evict the key before the tombstone chunk ran, leaving the schedule non-tombstoned in Kafka (and re-dispatched after a restart/reload) if that later chunk then failed.
• [Fix] Prevent the Karafka::Server#stop specs from leaking a sub-second shutdown_timeout into the global config. The #stop examples mutate Karafka::App.config.shutdown_timeout (down to 500 ms, below the default max_wait_time of 1_000 ms) but never restored it, so with a random run order the invalid value bled into unrelated specs and made them fail contract validation with shutdown_timeout must be more than max_wait_time. The original value is now captured and restored (and the memoized class-level value cleared) in the example teardown.
• [Fix] [Pro] Reject a schedule_target_epoch set implausibly far in the future (e.g. a milliseconds value passed as seconds) at publish time instead of silently dropping it on the consumer.
• [Fix] [Pro] Raise Karafka::Errors::UnsupportedCaseError instead of a NameError (wrong constant namespace) when a custom DLQ strategy returns an unsupported flow, in both the default and virtual-partitions DLQ strategies.
• [Enhancement] Support named Karafka::Constraints registered in two phases: :load (require time) and :config (during setup, after contract validation), so feature-specific environment requirements are verified in one place.
• [Fix] Message key and headers deserialization results were not cached when the deserializer returned nil or false (e.g. keyless messages), re-running the deserializer on every access. Falsy results are now cached like truthy ones, matching the payload behavior and the documented contract.
• [Fix] [Pro] Reset the Pro::Iterator stored-offsets latch between runs. #mark_as_consumed set an internal @stored_offsets flag that was never cleared, so once a reused iterator marked anything, the teardown guard fired a spurious blocking sync commit_offsets on the end of every subsequent #each - each running on a brand-new consumer with no stored offsets. The flag is now reset alongside the other per-run state in the #each ensure block, so it reflects only the current run's marking activity (benign no-op commit removed; no correctness impact).
• [Fix] [Pro] Deduplicate runtime pattern discovery under multiplexing. Multiplexed subscription groups share a single consumer group but each runs its own listener thread and independently discovers the same topic; ConsumerGroup#topic= appended unconditionally, so the shared consumer group accumulated up to multiplex_factor duplicate Topic objects per discovered topic (polluting the routing tree and slowing linear topic scans, though the per-subscription-group consume path stayed correct). The detector now registers each discovered topic in the shared group only once (under its existing mutex) while still giving every subscription group its own Topic instance, mirroring how the multiplexing subscription groups builder dups topics per group at boot.
• [Fix] Fix sub-second shutdown_timeout values collapsing to a zero-iteration supervision loop. The graceful-shutdown wait computed its iteration count with integer division (shutdown_timeout / 1_000), so any configured shutdown_timeout below 1000ms (valid config, as long as it exceeds max_wait_time) floored to zero iterations, skipping the grace period entirely and forcing an immediate forceful shutdown (killing in-flight jobs before their offset commits). The count is now computed with float math and ceil, guaranteeing at least one supervision check for any positive timeout. The swarm supervisor shared the same formula (masked by the added grace period) and was fixed the same way.
• [Fix] Remove the backwards-compatible forwarding shim that kept the pre-nesting config.internal.processing.* paths (coordinator_class, errors_tracker_class, partitioner_class, strategy_selector, expansions_selector, executor_class, jobs_builder) resolving after the 2.6.0 move to config.internal.processing.consumer_groups.*. The shim was shipped by accident; the nesting was announced as having no backward compatibility. Use the nested config.internal.processing.consumer_groups.* paths instead. Requires karafka-testing >= 2.6.2, which reads these settings from their nested location.
• [Fix] Stop PausesManager#@pauses from growing unbounded across rebalances. CoordinatorsBuffer#revoke reset the pause tracker's retry attempt count on revocation but never removed it, and nothing else pruned the hash outside of critical-error recovery, so a Pause (and its Mutex) was retained forever for every distinct topic-partition ever assigned - harmless for static routing (Topic objects are stable and get reused on reassignment) but unbounded under regex pattern subscriptions with ephemeral, per-discovery topic names. #revoke now removes a tracker outright when it is not currently paused (added PausesManager#delete), since it carries no state worth preserving; a tracker that is paused is still reset-and-kept, unchanged, because its remaining backoff may need to be honoured again if the same partition is reclaimed (routine under eager rebalancing, where every previously owned partition is revoked and reassigned even when nothing has actually changed for it).
• [Fix] Allow-list the benign auto-create TOPIC_ALREADY_EXISTS broker warning in unexpected_patterns_loop_spec.rb, the same pre-existing broker-side race already allow-listed for other pattern-matched-topic specs, unrelated to this release's other fixes.
• [Fix] [Pro] Fix unbounded memory growth from Pro::Processing::JobsQueue's per-group semaphore accumulating unconsumed #tick signals under non-blocking/LRJ and async-locking workloads.
• [Fix] [Pro] Stop Pro::Processing::JobsQueue#unlock from decrementing @statistics[:waiting] before confirming the job was actually tracked. It unconditionally decremented first and only afterwards checked whether the job was still present in @in_waiting, so a job unlocked after its subscription group had already been reset via #clear (which decrements waiting itself as part of recovery) both over-decremented the counter a second time and raised JobsQueueSynchronizationError - the counter corruption was silent while the (still legitimate) synchronization error masked it. #unlock now only decrements when the job is found, mirroring #unlock_async's existing check-then-act pattern; both raise consistently when the group has already been cleared.
• [Fix] Swarm::Node#signal (used by #stop/#terminate/#quiet) could send a signal to a reaped node's stale @pid, which the OS may have already reassigned to an unrelated process. It now returns false without signaling if the node is already known to be dead.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate CLI.