karafka 2.6.0.beta1 → 2.6.0.rc2

data/lib/karafka/pro/swarm/liveness_listener.rb

@@ -47,28 +47,50 @@ module Karafka
       #   - 1 - polling ttl exceeded
       #   - 2 - consuming ttl exceeded
       #   - 3 - memory limit exceeded
+      #   - 4 - stability ttl exceeded (stuck in non-steady librdkafka join state)
       #
       # @note This listener should not break anything if subscribed in the supervisor prior to
       #   forking as it relies on server events for operations.
       class LivenessListener < Karafka::Swarm::LivenessListener
+        # Default time in ms after which we consider consumption hanging (5 minutes)
+        DEFAULT_CONSUMING_TTL = 5 * 60 * 1_000
+        # Default max time in ms between polls before the node is considered dead (5 minutes)
+        DEFAULT_POLLING_TTL = 5 * 60 * 1_000
+        # Multiplier applied to max.poll.interval.ms when deriving the default stability_ttl.
+        STABILITY_TTL_MAX_POLL_MULTIPLIER = 2
+
+        private_constant(
+          :DEFAULT_CONSUMING_TTL,
+          :DEFAULT_POLLING_TTL,
+          :STABILITY_TTL_MAX_POLL_MULTIPLIER
+        )
+
         # @param memory_limit [Integer] max memory in MB for this process to be considered healthy
-        # @param consuming_ttl [Integer] time in ms after which we consider consumption hanging.
-        #   It allows us to define max consumption time after which supervisor should consider
-        #   given process as hanging
-        # @param polling_ttl [Integer] max time in ms for polling. If polling (any) does not
-        #   happen that often, process should be considered dead.
-        # @note The default TTL matches the default `max.poll.interval.ms`
+        # @param consuming_ttl [Integer] see Kubernetes::LivenessListener for full documentation.
+        # @param polling_ttl [Integer] see Kubernetes::LivenessListener for full documentation.
+        # @param stability_ttl [Integer, nil] see Kubernetes::LivenessListener for full
+        #   documentation, including the derivation rules (max `max.poll.interval.ms` across
+        #   all active subscription groups, times 2, resolved lazily on first health
+        #   evaluation). Same semantics apply here; the node is reported unhealthy with
+        #   status code 4 instead of returning HTTP 500.
         def initialize(
           memory_limit: Float::INFINITY,
-          consuming_ttl: 5 * 60 * 1_000,
-          polling_ttl: 5 * 60 * 1_000
+          consuming_ttl: DEFAULT_CONSUMING_TTL,
+          polling_ttl: DEFAULT_POLLING_TTL,
+          stability_ttl: nil
         )
           @polling_ttl = polling_ttl
           @consuming_ttl = consuming_ttl
+          # When nil, resolved lazily via #stability_ttl on first health evaluation because
+          # the default derives from the routing subscription groups, which may not be drawn
+          # yet when the listener is constructed in karafka.rb
+          @stability_ttl = stability_ttl
           # We cast it just in case someone would provide '10MB' or something similar
           @memory_limit = memory_limit.is_a?(String) ? memory_limit.to_i : memory_limit
           @pollings = {}
           @consumptions = {}
+          @join_states = {}
+          @instabilities = {}
 
           super()
         end
@@ -117,6 +139,27 @@ module Karafka
           RUBY
         end
 
+        # @see Karafka::Instrumentation::Vendors::Kubernetes::LivenessListener#on_statistics_emitted
+        # @param event [Karafka::Core::Monitoring::Event]
+        def on_statistics_emitted(event)
+          cgrp = event[:statistics]&.dig("cgrp")
+          return unless cgrp
+
+          sg_id = event[:subscription_group_id]
+          join_state = cgrp["join_state"]
+          return unless join_state
+
+          synchronize do
+            if join_state == "steady" || join_state == "init" || join_state == "wait-metadata"
+              @instabilities.delete(sg_id)
+              @join_states.delete(sg_id)
+            elsif @join_states[sg_id] != join_state
+              @join_states[sg_id] = join_state
+              @instabilities[sg_id] = monotonic_now
+            end
+          end
+        end
+
         # @param _event [Karafka::Core::Monitoring::Event]
         def on_error_occurred(_event)
           clear_consumption_tick
@@ -143,6 +186,13 @@ module Karafka
           clear_polling_tick
         end
 
+        # @see Karafka::Instrumentation::Vendors::Kubernetes::LivenessListener
+        #   #on_connection_listener_after_fetch_loop
+        # @param event [Karafka::Core::Monitoring::Event]
+        def on_connection_listener_after_fetch_loop(event)
+          clear_instability_tracking(event[:subscription_group])
+        end
+
         private
 
         # Reports the current status to the supervisor periodically
@@ -158,10 +208,21 @@ module Karafka
           end
         end
 
-        # @return [Integer] object id of the current fiber
-        # @note We use fiber object id instead of thread object id to ensure fiber-safety.
-        #   Multiple fibers can run on the same thread, and using thread id would cause them
-        #   to overwrite each other's timestamps.
+        # @see Karafka::Instrumentation::Vendors::Kubernetes::LivenessListener
+        #   #clear_instability_tracking
+        # @param subscription_group [Karafka::Routing::SubscriptionGroup, nil]
+        def clear_instability_tracking(subscription_group)
+          return unless subscription_group
+
+          sg_id = subscription_group.id
+
+          synchronize do
+            @instabilities.delete(sg_id)
+            @join_states.delete(sg_id)
+          end
+        end
+
+        # @see Karafka::Instrumentation::Vendors::Kubernetes::LivenessListener#fiber_id
         def fiber_id
           Fiber.current.object_id
         end
@@ -195,17 +256,61 @@ module Karafka
         end
 
         # Did we exceed any of the ttls
-        # @return [String] 204 string if ok, 500 otherwise
+        # @return [Integer] 0 if healthy, positive error code otherwise:
+        #   1 - polling TTL exceeded
+        #   2 - consuming TTL exceeded
+        #   3 - memory limit exceeded
+        #   4 - stability TTL exceeded (stuck in non-steady join state)
+        # @note Reads `@pollings`, `@consumptions` and `@instabilities` without acquiring the
+        #   mutex. This is intentional and consistent across all three: `status` is called from
+        #   inside `periodically`, which already holds `@mutex` for scheduling, so re-entering
+        #   `synchronize` here would deadlock. Concurrent writes from `mark_*` / `clear_*` /
+        #   `on_statistics_emitted` are safe to observe partially on MRI (GVL atomises Hash ops).
+        #   This is the asymmetry vs `Kubernetes::LivenessListener`, which can lock its reads
+        #   because it has no equivalent periodic-scheduling lock. Do not "fix" this without
+        #   resolving the periodic-scheduling lock first - JRuby is not a supported runtime.
         def status
           time = monotonic_now
 
           return 1 if @pollings.values.any? { |tick| (time - tick) > @polling_ttl }
           return 2 if @consumptions.values.any? { |tick| (time - tick) > @consuming_ttl }
           return 3 if rss_mb > @memory_limit
+          return 4 if @instabilities.values.any? { |start| (time - start) > stability_ttl }
 
           0
         end
 
+        # @return [Integer] effective stability ttl in ms. Resolved lazily (instead of in
+        #   `#initialize`) because the default derives from the routing subscription groups,
+        #   which may not be drawn yet when the listener is constructed in karafka.rb. By the
+        #   time status is evaluated, routing is final.
+        def stability_ttl
+          @stability_ttl ||= default_stability_ttl
+        end
+
+        # @return [Integer] default stability_ttl derived from the configured
+        #   max.poll.interval.ms, multiplied by 2 for headroom above the slowest legitimate
+        #   rebalance phase. Uses the maximum value across all active subscription groups
+        #   (their kafka configs already have librdkafka defaults injected), so per
+        #   subscription group overrides set via the routing DSL are respected. Falls back to
+        #   the root kafka config when no subscription groups are available.
+        def default_stability_ttl
+          max_poll_interval = Karafka::App
+            .subscription_groups
+            .values
+            .flatten
+            .map { |sg| sg.kafka.fetch(:"max.poll.interval.ms") }
+            .max
+
+          max_poll_interval ||= begin
+            kafka_config = Karafka::App.config.kafka.dup
+            Karafka::Setup::DefaultsInjector.consumer(kafka_config)
+            kafka_config.fetch(:"max.poll.interval.ms")
+          end
+
+          max_poll_interval * STABILITY_TTL_MAX_POLL_MULTIPLIER
+        end
+
         # @return [Integer] RSS in MB for the current process
         def rss_mb
           RUBY_PLATFORM.include?("linux") ? rss_mb_linux : rss_mb_macos

data/lib/karafka/pro.rb

@@ -1,11 +1,5 @@
 # frozen_string_literal: true
 
-# This Karafka component is a Pro component.
-# All of the commercial components are present in the lib/karafka/pro directory of this repository
-# and their usage requires commercial license agreement.
-#
-# Karafka has also commercial-friendly license, commercial support and commercial components.
-#
 module Karafka
   # Namespace for pro components, licensed under the commercial license agreement.
   module Pro

data/lib/karafka/processing/consumer_groups/coordinator.rb

@@ -2,16 +2,14 @@
 
 module Karafka
   module Processing
-    # Consumer-group-specific processing components (driven by rebalance callbacks and partition
-    # ticks). Parallel `ShareGroups` will live next to this namespace once KIP-932 lands.
     module ConsumerGroups
       # Basic coordinator that allows us to provide coordination objects into consumers.
       #
       # This is a wrapping layer to simplify management of work to be handled around consumption.
       #
       # @note This coordinator needs to be thread safe. Some operations are performed only in the
-      #   listener thread, but we go with thread-safe by default for all not to worry about potential
-      #   future mistakes.
+      #   listener thread, but we go with thread-safe by default for all not to worry about
+      #   potential future mistakes.
       class Coordinator
         extend Forwardable
         include Core::Helpers::Time
@@ -29,7 +27,8 @@ module Karafka
 
         # @param topic [Karafka::Routing::Topic]
         # @param partition [Integer]
-        # @param pause_tracker [Karafka::TimeTrackers::Pause] pause tracker for given topic partition
+        # @param pause_tracker [Karafka::TimeTrackers::Pause] pause tracker for given topic
+        #   partition
         def initialize(topic, partition, pause_tracker)
           @topic = topic
           @partition = partition

data/lib/karafka/processing/consumer_groups/coordinators_buffer.rb

@@ -2,8 +2,6 @@
 
 module Karafka
   module Processing
-    # Consumer-group-specific processing components (driven by rebalance callbacks and partition
-    # ticks). Parallel `ShareGroups` will live next to this namespace once KIP-932 lands.
     module ConsumerGroups
       # Coordinators builder used to build coordinators per topic partition
       #
@@ -50,6 +48,12 @@ module Karafka
         def revoke(topic_name, partition)
           return unless @coordinators[topic_name].key?(partition)
 
+          # Reset the partition's pause tracker attempt count. The tracker lives in the pauses
+          # manager keyed by topic-partition and would otherwise be reused as-is if we reclaim this
+          # partition, carrying a stale retry attempt count across the rebalance (which, with DLQ,
+          # would send the next failure straight to the dead letter queue, skipping the retries)
+          @pauses_manager.revoke(@topics.find(topic_name), partition)
+
           # The fact that we delete here does not change the fact that the executor still holds the
           # reference to this coordinator. We delete it here, as we will no longer process any
           # new stuff with it and we may need a new coordinator if we regain this partition, but the

data/lib/karafka/processing/consumer_groups/executor.rb

@@ -7,8 +7,8 @@ module Karafka
     # ticks). Parallel `ShareGroups` will live next to this namespace once KIP-932 lands.
     module ConsumerGroups
       # Executors:
-      # - run consumers code (for `#call`) or run given preparation / teardown operations when needed
-      #   from separate threads.
+      # - run consumers code (for `#call`) or run given preparation / teardown operations when
+      #   needed from separate threads.
       # - they re-create consumer instances in case of partitions that were revoked and assigned
       #   back.
       #
@@ -54,8 +54,8 @@ module Karafka
           @coordinator = coordinator
         end
 
-        # Allows us to prepare the consumer in the listener thread prior to the job being send to
-        # be scheduled. It also allows to run some code that is time sensitive and cannot wait in the
+        # Allows us to prepare the consumer in the listener thread prior to the job being send to be
+        # scheduled. It also allows to run some code that is time sensitive and cannot wait in the
         # queue as it could cause starvation.
         #
         # @param messages [Array<Karafka::Messages::Message>]

data/lib/karafka/processing/consumer_groups/executors_buffer.rb

@@ -2,8 +2,6 @@
 
 module Karafka
   module Processing
-    # Consumer-group-specific processing components (driven by rebalance callbacks and partition
-    # ticks). Parallel `ShareGroups` will live next to this namespace once KIP-932 lands.
     module ConsumerGroups
       # Buffer for executors of a given subscription group. It wraps around the concept of building
       # and caching them, so we can re-use them instead of creating new each time.
@@ -63,8 +61,8 @@ module Karafka
         #
         # @param topic [String] topic name
         # @param partition [Integer] partition number
-        # @return [Array<Executor, Pro::Processing::ConsumerGroups::Executor>] executors in use for this
-        #   topic + partition
+        # @return [Array<Executor, Pro::Processing::ConsumerGroups::Executor>] executors in use for
+        #   this topic + partition
         def find_all(topic, partition)
           @buffer[topic][partition].values
         end

data/lib/karafka/processing/consumer_groups/expansions_selector.rb

@@ -2,8 +2,6 @@
 
 module Karafka
   module Processing
-    # Consumer-group-specific processing components (driven by rebalance callbacks and partition
-    # ticks). Parallel `ShareGroups` will live next to this namespace once KIP-932 lands.
     module ConsumerGroups
       # Selector of appropriate topic setup based features enhancements.
       #

data/lib/karafka/processing/consumer_groups/inline_insights/consumer.rb

@@ -2,8 +2,6 @@
 
 module Karafka
   module Processing
-    # Consumer-group-specific processing components (driven by rebalance callbacks and partition
-    # ticks). Parallel `ShareGroups` will live next to this namespace once KIP-932 lands.
     module ConsumerGroups
       # Namespace of the Inline Insights feature "non routing" related components
       #

data/lib/karafka/processing/consumer_groups/inline_insights/listener.rb

@@ -2,8 +2,6 @@
 
 module Karafka
   module Processing
-    # Consumer-group-specific processing components (driven by rebalance callbacks and partition
-    # ticks). Parallel `ShareGroups` will live next to this namespace once KIP-932 lands.
     module ConsumerGroups
       module InlineInsights
         # Listener that adds statistics to our inline tracker

data/lib/karafka/processing/consumer_groups/inline_insights/tracker.rb

@@ -2,31 +2,29 @@
 
 module Karafka
   module Processing
-    # Consumer-group-specific processing components (driven by rebalance callbacks and partition
-    # ticks). Parallel `ShareGroups` will live next to this namespace once KIP-932 lands.
     module ConsumerGroups
       module InlineInsights
         # Object used to track statistics coming from librdkafka in a way that can be accessible by
         # the consumers
         #
-        # We use a single tracker because we do not need state management here as our consumer groups
-        # clients identified by statistics name value are unique. On top of that, having a per
-        # process one that is a singleton allows us to use tracker easily also from other places like
-        # filtering API etc.
+        # We use a single tracker because we do not need state management here as our consumer
+        # groups clients identified by statistics name value are unique. On top of that, having a
+        # per process one that is a singleton allows us to use tracker easily also from other places
+        # like filtering API etc.
         #
         # @note We include cache of 5 minutes for revoked partitions to compensate for cases where
-        #   when using LRJ a lost partition data would not be present anymore, however we would still
-        #   be in the processing phase. Since those metrics are published with each `poll`, regular
-        #   processing is not a subject of this issue. For LRJ we keep the reference. The only case
-        #   where this could be switched midway is when LRJ is running for an extended period of time
-        #   after the involuntary revocation. Having a time based cache instead of tracking
-        #   simplifies the design as we do not have to deal with state tracking, especially since
-        #   we would have to track also operations running in a revoked state.
+        #   when using LRJ a lost partition data would not be present anymore, however we would
+        #   still be in the processing phase. Since those metrics are published with each `poll`,
+        #   regular processing is not a subject of this issue. For LRJ we keep the reference. The
+        #   only case where this could be switched midway is when LRJ is running for an extended
+        #   period of time after the involuntary revocation. Having a time based cache instead of
+        #   tracking simplifies the design as we do not have to deal with state tracking, especially
+        #   since we would have to track also operations running in a revoked state.
         #
         # @note This tracker keeps in memory data about all topics and partitions that it encounters
-        #   because in case of routing patterns, we may start getting statistics prior to registering
-        #   given topic via dynamic routing expansions. In such case we would not have insights
-        #   where they were actually available for us to use.
+        #   because in case of routing patterns, we may start getting statistics prior to
+        #   registering given topic via dynamic routing expansions. In such case we would not have
+        #   insights where they were actually available for us to use.
         #
         # @note Memory usage is negligible as long as we can evict expired data. Single metrics set
         #   for a single partition contains around 4KB of data. This means, that in case of an

data/lib/karafka/processing/consumer_groups/jobs/consume.rb

@@ -2,10 +2,7 @@
 
 module Karafka
   module Processing
-    # Consumer-group-specific processing components (driven by rebalance callbacks and partition
-    # ticks). Parallel `ShareGroups` will live next to this namespace once KIP-932 lands.
     module ConsumerGroups
-      # Consumer-group-specific job types
       module Jobs
         # The main job type. It runs the executor that triggers given topic partition messages
         # processing in an underlying consumer instance.
@@ -15,8 +12,8 @@ module Karafka
 
           self.action = :consume
 
-          # @param executor [Karafka::Processing::ConsumerGroups::Executor] executor that is suppose to run a given
-          #   job
+          # @param executor [Karafka::Processing::ConsumerGroups::Executor] executor that is suppose
+          #   to run a given job
           # @param messages [Karafka::Messages::Messages] karafka messages batch
           # @return [Consume]
           def initialize(executor, messages)

data/lib/karafka/processing/consumer_groups/jobs/eofed.rb

@@ -2,8 +2,6 @@
 
 module Karafka
   module Processing
-    # Consumer-group-specific processing components (driven by rebalance callbacks and partition
-    # ticks). Parallel `ShareGroups` will live next to this namespace once KIP-932 lands.
     module ConsumerGroups
       # Consumer-group-specific job types
       module Jobs
@@ -11,7 +9,8 @@ module Karafka
         class Eofed < ::Karafka::Processing::Jobs::Base
           self.action = :eofed
 
-          # @param executor [Karafka::Processing::ConsumerGroups::Executor] executor that is supposed to run the job
+          # @param executor [Karafka::Processing::ConsumerGroups::Executor] executor that is
+          #   supposed to run the job
           # @return [Eofed]
           def initialize(executor)
             @executor = executor

data/lib/karafka/processing/consumer_groups/jobs/idle.rb

@@ -9,8 +9,8 @@ module Karafka
         class Idle < ::Karafka::Processing::Jobs::Base
           self.action = :idle
 
-          # @param executor [Karafka::Processing::ConsumerGroups::Executor] executor that is supposed to run a given
-          #   job on an active consumer
+          # @param executor [Karafka::Processing::ConsumerGroups::Executor] executor that is
+          #   supposed to run a given job on an active consumer
           # @return [Idle]
           def initialize(executor)
             @executor = executor

data/lib/karafka/processing/consumer_groups/jobs/revoked.rb

@@ -2,16 +2,14 @@
 
 module Karafka
   module Processing
-    # Consumer-group-specific processing components (driven by rebalance callbacks and partition
-    # ticks). Parallel `ShareGroups` will live next to this namespace once KIP-932 lands.
     module ConsumerGroups
-      # Consumer-group-specific job types
       module Jobs
         # Job that runs the revoked operation when we lose a partition on a consumer that lost it.
         class Revoked < ::Karafka::Processing::Jobs::Base
           self.action = :revoked
 
-          # @param executor [Karafka::Processing::ConsumerGroups::Executor] executor that is supposed to run the job
+          # @param executor [Karafka::Processing::ConsumerGroups::Executor] executor that is
+          #   supposed to run the job
           # @return [Revoked]
           def initialize(executor)
             @executor = executor

data/lib/karafka/processing/consumer_groups/jobs/shutdown.rb

@@ -8,8 +8,8 @@ module Karafka
         class Shutdown < ::Karafka::Processing::Jobs::Base
           self.action = :shutdown
 
-          # @param executor [Karafka::Processing::ConsumerGroups::Executor] executor that is supposed to run a given
-          #   job on an active consumer
+          # @param executor [Karafka::Processing::ConsumerGroups::Executor] executor that is
+          #   supposed to run a given job on an active consumer
           # @return [Shutdown]
           def initialize(executor)
             @executor = executor

data/lib/karafka/processing/consumer_groups/partitioner.rb

@@ -2,11 +2,8 @@
 
 module Karafka
   module Processing
-    # Consumer-group-specific processing components (driven by rebalance callbacks and partition
-    # ticks). Parallel `ShareGroups` will live next to this namespace once KIP-932 lands.
     module ConsumerGroups
-      # Basic partitioner for work division
-      # It does not divide any work.
+      # Basic partitioner for work division. It does not divide any work.
       class Partitioner
         # @param subscription_group [Karafka::Routing::SubscriptionGroup] subscription group
         def initialize(subscription_group)
@@ -15,8 +12,8 @@ module Karafka
 
         # @param _topic [String] topic name
         # @param messages [Array<Karafka::Messages::Message>] karafka messages
-        # @param _coordinator [Karafka::Processing::ConsumerGroups::Coordinator] processing coordinator that will
-        #   be used with those messages
+        # @param _coordinator [Karafka::Processing::ConsumerGroups::Coordinator] processing
+        #   coordinator that will be used with those messages
         # @yieldparam [Integer] group id
         # @yieldparam [Array<Karafka::Messages::Message>] karafka messages
         def call(_topic, messages, _coordinator)

data/lib/karafka/processing/consumer_groups/strategies/aj_dlq_mom.rb

@@ -2,8 +2,6 @@
 
 module Karafka
   module Processing
-    # Consumer-group-specific processing components (driven by rebalance callbacks and partition
-    # ticks). Parallel `ShareGroups` will live next to this namespace once KIP-932 lands.
     module ConsumerGroups
       module Strategies
         # ActiveJob strategy to cooperate with the DLQ.
@@ -28,6 +26,11 @@ module Karafka
             if coordinator.success?
               # Do NOT commit offsets, they are comitted after each job in the AJ consumer.
               coordinator.pause_tracker.reset
+            # Process-critical errors are never dispatched to the DLQ regardless of the retries
+            # state: the retry pause protects the partition during the critical shutdown and
+            # the failed batch is redelivered after the restart
+            elsif critical_error?(coordinator.consumption(self).cause)
+              retry_after_pause
             elsif coordinator.pause_tracker.attempt <= topic.dead_letter_queue.max_retries
               retry_after_pause
             else

data/lib/karafka/processing/consumer_groups/strategies/aj_mom.rb

@@ -2,12 +2,10 @@
 
 module Karafka
   module Processing
-    # Consumer-group-specific processing components (driven by rebalance callbacks and partition
-    # ticks). Parallel `ShareGroups` will live next to this namespace once KIP-932 lands.
     module ConsumerGroups
       module Strategies
-        # ActiveJob enabled
-        # Manual offset management enabled
+        # - ActiveJob enabled
+        # - Manual offset management enabled
         #
         # This is the default AJ strategy since AJ cannot be used without MOM
         module AjMom

data/lib/karafka/processing/consumer_groups/strategies/base.rb

@@ -2,12 +2,10 @@
 
 module Karafka
   module Processing
-    # Consumer-group-specific processing components (driven by rebalance callbacks and partition
-    # ticks). Parallel `ShareGroups` will live next to this namespace once KIP-932 lands.
     module ConsumerGroups
-      # Our processing patterns differ depending on various features configurations
-      # In this namespace we collect strategies for particular feature combinations to simplify the
-      # design. Based on features combinations we can then select handling strategy for a given case.
+      # Our processing patterns differ depending on various features configurations. In this
+      # namespace we collect strategies for particular feature combinations to simplify the design.
+      # Based on features combinations we can then select handling strategy for a given case.
       #
       # @note The lack of common code here is intentional. It would get complex if there would be
       #   any type of composition, so each strategy is expected to be self-sufficient

data/lib/karafka/processing/consumer_groups/strategies/default.rb

@@ -2,13 +2,12 @@
 
 module Karafka
   module Processing
-    # Consumer-group-specific processing components (driven by rebalance callbacks and partition
-    # ticks). Parallel `ShareGroups` will live next to this namespace once KIP-932 lands.
     module ConsumerGroups
       module Strategies
-        # No features enabled.
-        # No manual offset management
-        # No long running jobs
+        # No features enabled:
+        # - No manual offset management
+        # - No long running jobs
+        #
         # Nothing. Just standard, automatic flow
         module Default
           include Base
@@ -59,9 +58,18 @@ module Karafka
             # In case like this we ignore marking
             return true if seek_offset.nil?
             # Ignore double markings of the same offset
+            # Only this exact re-mark is skipped - marking genuinely older offsets is intentionally
+            # allowed and rewinds the seek offset for reprocessing (see #2432)
             return true if (seek_offset - 1) == message.offset
             return false if revoked?
-            return revoked? unless client.mark_as_consumed(message)
+            unless client.mark_as_consumed(message)
+              # Evaluate ownership for its coordinator-revoking side effect - all marking
+              # failure causes are ownership related. The failure itself always reports false:
+              # the offset was not stored, regardless of the current ownership state
+              revoked?
+
+              return false
+            end
 
             self.seek_offset = message.offset + 1
 
@@ -78,10 +86,19 @@ module Karafka
             # In case like this we ignore marking
             return true if seek_offset.nil?
             # Ignore double markings of the same offset
+            # Only this exact re-mark is skipped - marking genuinely older offsets is intentionally
+            # allowed and rewinds the seek offset for reprocessing (see #2432)
             return true if (seek_offset - 1) == message.offset
             return false if revoked?
 
-            return revoked? unless client.mark_as_consumed!(message)
+            unless client.mark_as_consumed!(message)
+              # Evaluate ownership for its coordinator-revoking side effect - all marking
+              # failure causes are ownership related. The failure itself always reports false:
+              # the offset was not committed, regardless of the current ownership state
+              revoked?
+
+              return false
+            end
 
             self.seek_offset = message.offset + 1
 
@@ -91,17 +108,27 @@ module Karafka
           # Triggers an async offset commit
           #
           # @param async [Boolean] should we use async (default) or sync commit
-          # @return [Boolean] true if we still own the partition.
+          # @return [Boolean] true if the commit went through and we still owned the partition
+          #   at that time, false otherwise. False means the offsets were not committed - the
+          #   caller can retry (the offsets stay stored client-side) or treat the partition as
+          #   fenced.
           # @note Due to its async nature, this may not fully represent the offset state in some
           #   edge cases (like for example going beyond max.poll.interval)
+          # @note A commit with no offsets pending is a client-side no-op reported as success
+          #   without broker validation - the marking result is the fence for that case.
           def commit_offsets(async: true)
             # Do not commit if we already lost the assignment
             return false if revoked?
             return true if client.commit_offsets(async: async)
 
-            # This will once more check the librdkafka revocation status and will revoke the
-            # coordinator in case it was not revoked
+            # Evaluate ownership once more for its coordinator-revoking side effect: all
+            # commit failure causes the client reports as false are ownership related. The
+            # failed commit itself always reports false - its value must not depend on the
+            # revocation state, which may not yet be locally visible (or may indicate a
+            # retained partition under a cooperative rebalance generation bump)
             revoked?
+
+            false
           end
 
           # Triggers a synchronous offsets commit to Kafka
@@ -138,7 +165,10 @@ module Karafka
 
             # Mark job as successful
             coordinator.success!(self)
-          rescue => e
+          # Failure recording must be class-agnostic: an unrecorded non-StandardError would
+          # leave the consumption result in its default (successful) state and the after-consume
+          # flow would mark the failed batch as consumed instead of engaging the retry
+          rescue Exception => e
             coordinator.failure!(self, e)
 
             # Re-raise so reported in the consumer
@@ -187,8 +217,8 @@ module Karafka
           end
 
           # We need to always un-pause the processing in case we have lost a given partition.
-          # Otherwise the underlying librdkafka would not know we may want to continue processing and
-          # the pause could in theory last forever
+          # Otherwise the underlying librdkafka would not know we may want to continue processing
+          # and the pause could in theory last forever
           def handle_revoked
             resume