karafka 2.6.0.beta1 → 2.6.0.rc1

data/lib/karafka/pro/processing/consumer_groups/strategies/aj/mom_vp.rb

@@ -31,15 +31,12 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           module Aj
-            # ActiveJob enabled
-            # Manual offset management enabled
-            # Virtual Partitions enabled
+            # - ActiveJob enabled
+            # - Manual offset management enabled
+            # - Virtual Partitions enabled
             module MomVp
               include Strategies::Default
               include Strategies::Vp::Default

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

@@ -31,9 +31,6 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro processing components (driven by rebalance callbacks and
-      # partition ticks). Parallel `ShareGroups` will live next to this namespace once KIP-932
-      # lands.
       module ConsumerGroups
         # Pro processing strategies namespace
         module Strategies

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

@@ -31,15 +31,13 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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 virtual partitions
+          # No features enabled:
+          # - No manual offset management
+          # - No long running jobs
+          # - No virtual partitions
+          #
           # Nothing. Just standard, automatic flow
           module Default
             include Base
@@ -70,10 +68,10 @@ module Karafka
             # @return [Boolean] true if we were able to mark the offset, false otherwise.
             #   False indicates that we were not able and that we have lost the partition.
             #
-            # @note We keep track of this offset in case we would mark as consumed and got error when
-            #   processing another message. In case like this we do not pause on the message we've
-            #   already processed but rather at the next one. This applies to both sync and async
-            #   versions of this method.
+            # @note We keep track of this offset in case we would mark as consumed and got error
+            #   when processing another message. In case like this we do not pause on the message
+            #   we've already processed but rather at the next one. This applies to both sync and
+            #   async versions of this method.
             def mark_as_consumed(message, offset_metadata = @_current_offset_metadata)
               # If we are inside a transaction than we can just mark as consumed within it
               if @_in_transaction
@@ -88,6 +86,8 @@ module Karafka
                 # We ignore second marking because it changes nothing and in case of people using
                 # metadata storage but with automatic offset marking, this would cause metadata to be
                 # erased by automatic marking
+                # 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?
 
@@ -101,7 +101,14 @@ module Karafka
                   client.mark_as_consumed(message, offset_metadata)
                 end
 
-                return revoked? unless stored
+                unless stored
+                  # 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 ownership state
+                  revoked?
+
+                  return false
+                end
 
                 self.seek_offset = message.offset + 1
               end
@@ -130,6 +137,8 @@ module Karafka
                 # We ignore second marking because it changes nothing and in case of people using
                 # metadata storage but with automatic offset marking, this would cause metadata to be
                 # erased by automatic marking
+                # 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?
 
@@ -143,7 +152,14 @@ module Karafka
                   client.mark_as_consumed!(message, offset_metadata)
                 end
 
-                return revoked? unless stored
+                unless stored
+                  # 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 ownership state
+                  revoked?
+
+                  return false
+                end
 
                 self.seek_offset = message.offset + 1
               end
@@ -162,8 +178,8 @@ module Karafka
             #
             # @param active_producer [WaterDrop::Producer] alternative producer instance we may want
             #   to use. It is useful when we have connection pool or any other selective engine for
-            #   managing multiple producers. If not provided, default producer taken from `#producer`
-            #   will be used.
+            #   managing multiple producers. If not provided, default producer taken from
+            #   `#producer` will be used.
             #
             # @yield code that we want to run in a transaction
             #
@@ -212,23 +228,23 @@ module Karafka
                 # This offset is already stored in transaction but we set it here anyhow because we
                 # want to make sure our internal in-memory state is aligned with the transaction
                 #
-                # @note We never need to use the blocking `#mark_as_consumed!` here because the
-                #   offset anyhow was already stored during the transaction
+                # We never need to use the blocking `#mark_as_consumed!` here because the offset
+                # anyhow was already stored during the transaction
                 #
-                # @note Since the offset could have been already stored in Kafka (could have because
-                #   you can have transactions without marking), we use the `@_in_transaction_marked`
-                #   state to decide if we need to dispatch the offset via client at all
-                #   (if post transaction, then we do not have to)
+                # Since the offset could have been already stored in Kafka (could have because you
+                # can have transactions without marking), we use the `@_in_transaction_marked` state
+                # to decide if we need to dispatch the offset via client at all (if post
+                # transaction, then we do not have to)
                 #
-                # @note In theory we could only keep reference to the most recent marking and reject
-                #   others. We however do not do it for two reasons:
-                #   - User may have non standard flow relying on some alternative order and we want
-                #     to mimic this
-                #   - Complex strategies like VPs can use this in VPs to mark in parallel without
-                #     having to redefine the transactional flow completely
+                # In theory we could only keep reference to the most recent marking and reject
+                # others. We however do not do it for two reasons:
+                # - User may have non standard flow relying on some alternative order and we want
+                #   to mimic this
+                # - Complex strategies like VPs can use this in VPs to mark in parallel without
+                #   having to redefine the transactional flow completely
                 #
-                # @note This should be applied only if transaction did not error and if it was not
-                #   aborted.
+                # This should be applied only if transaction did not error and if it was not
+                # aborted.
                 if transaction_completed
                   @_transaction_marked.each do |marking|
                     marking.pop ? mark_as_consumed(*marking) : mark_as_consumed!(*marking)
@@ -301,7 +317,8 @@ module Karafka
             # Marks the current state only in memory as the offset marking has already happened
             # using the producer transaction
             # @param message [Messages::Message] last successfully processed message.
-            # @return [Boolean] true if all good, false if we lost assignment and no point in marking
+            # @return [Boolean] true if all good, false if we lost assignment and no point in
+            #   marking
             def mark_in_memory(message)
               # seek offset can be nil only in case `#seek` was invoked with offset reset request
               # In case like this we ignore marking
@@ -310,6 +327,8 @@ module Karafka
               # We ignore second marking because it changes nothing and in case of people using
               # metadata storage but with automatic offset marking, this would cause metadata to be
               # erased by automatic marking
+              # 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?
 
@@ -328,8 +347,8 @@ module Karafka
               nil
             end
 
-            # Increment number of attempts per one "full" job. For all VP on a single topic partition
-            # this also should run once.
+            # Increment number of attempts per one "full" job. For all VP on a single topic
+            # partition this also should run once.
             def handle_before_consume
               coordinator.on_started do
                 coordinator.pause_tracker.increment
@@ -350,7 +369,11 @@ 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
               # If failed, mark as failed
               coordinator.failure!(self, e)
 

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

@@ -31,9 +31,6 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           # Namespace for all the strategies starting with DLQ
@@ -49,8 +46,8 @@ module Karafka
 
               # Override of the standard `#mark_as_consumed` in order to handle the pause tracker
               # reset in case DLQ is marked as fully independent. When DLQ is marked independent,
-              # any offset marking causes the pause count tracker to reset. This is useful when
-              # the error is not due to the collective batch operations state but due to intermediate
+              # any offset marking causes the pause count tracker to reset. This is useful when the
+              # error is not due to the collective batch operations state but due to intermediate
               # "crawling" errors that move with it
               #
               # @see `Strategies::Default#mark_as_consumed` for more details
@@ -68,8 +65,8 @@ module Karafka
                 @_current_offset_metadata = nil
               end
 
-              # Override of the standard `#mark_as_consumed!`. Resets the pause tracker count in case
-              # DLQ was configured with the `independent` flag.
+              # Override of the standard `#mark_as_consumed!`. Resets the pause tracker count in
+              # case DLQ was configured with the `independent` flag.
               #
               # @see `Strategies::Default#mark_as_consumed!` for more details
               # @param message [Messages::Message]
@@ -147,8 +144,8 @@ module Karafka
                 )
               end
 
-              # Dispatches the message to the DLQ (when needed and when applicable based on settings)
-              #   and marks this message as consumed for non MOM flows.
+              # Dispatches the message to the DLQ (when needed and when applicable based on
+              # settings) and marks this message as consumed for non MOM flows.
               #
               # If producer is transactional and config allows, uses transaction to do that
               def dispatch_if_needed_and_mark_as_consumed
@@ -157,11 +154,7 @@ module Karafka
                 dispatch = lambda do
                   dispatch_to_dlq(skippable_message) if dispatch_to_dlq?
 
-                  if mark_after_dispatch?
-                    mark_dispatched_to_dlq(skippable_message)
-                  else
-                    self.seek_offset = skippable_message.offset + 1
-                  end
+                  mark_dispatched_to_dlq(skippable_message) if mark_after_dispatch?
                 end
 
                 if dispatch_in_a_transaction?
@@ -169,6 +162,12 @@ module Karafka
                 else
                   dispatch.call
                 end
+
+                # When not marking after dispatch, the seek offset is advanced manually. This must
+                # happen only after the dispatch (and its transaction) succeeded - advancing it
+                # inside the transaction would let the mutation survive an abort, skipping the
+                # broken message which would then be neither in the DLQ nor reprocessed
+                self.seek_offset = skippable_message.offset + 1 unless mark_after_dispatch?
               end
 
               # @param skippable_message [Array<Karafka::Messages::Message>]
@@ -235,6 +234,20 @@ module Karafka
               # In case of `:skip` and `:dispatch` will run the exact flow provided in a block
               # In case of `:retry` always `#retry_after_pause` is applied
               def apply_dlq_flow
+                # Process-critical errors are never dispatched or skipped regardless of the
+                # strategy outcome: the retry pause protects the partition during the critical
+                # shutdown and the failed batch is redelivered after the restart.
+                # We consult `errors_tracker.last` (not the per-consumer consumption cause used
+                # by the OSS strategies, which have no tracker) because it is exactly what the
+                # DLQ strategy callable below receives - this guard judges the same evidence as
+                # the strategy it overrides. The tracker is cleared at attempt zero, so `last`
+                # is always the most recent failure of the current failure streak
+                if critical_error?(errors_tracker.last)
+                  retry_after_pause
+
+                  return
+                end
+
                 flow, target_topic = topic.dead_letter_queue.strategy.call(errors_tracker, attempt)
 
                 case flow

data/lib/karafka/pro/processing/consumer_groups/strategies/dlq/ftr.rb

@@ -31,9 +31,6 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           module Dlq

data/lib/karafka/pro/processing/consumer_groups/strategies/dlq/ftr_lrj.rb

@@ -31,15 +31,12 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           module Dlq
-            # Dead-Letter Queue enabled
-            # Filtering enabled
-            # Long-Running Job enabled
+            # - Dead-Letter Queue enabled
+            # - Filtering enabled
+            # - Long-Running Job enabled
             module FtrLrj
               include Strategies::Dlq::Lrj
               include Strategies::Lrj::Ftr
@@ -71,7 +68,7 @@ module Karafka
 
                       # :seek and :pause are fully handled by handle_post_filtering
                       # For :skip we still need to resume the LRJ MAX_PAUSE_TIME pause
-                      return unless coordinator.filter.action == :skip
+                      return unless coordinator.filter.skip?
                     elsif !revoked? && !coordinator.manual_seek?
                       seek(seek_offset, false, reset_offset: false)
                     end

data/lib/karafka/pro/processing/consumer_groups/strategies/dlq/ftr_lrj_mom.rb

@@ -31,16 +31,13 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           module Dlq
-            # DLQ enabled
-            # Ftr enabled
-            # LRJ enabled
-            # MoM enabled
+            # - DLQ enabled
+            # - Ftr enabled
+            # - LRJ enabled
+            # - MoM enabled
             module FtrLrjMom
               include Strategies::Ftr::Default
               include Strategies::Dlq::LrjMom
@@ -66,7 +63,7 @@ module Karafka
 
                       # :seek and :pause are fully handled by handle_post_filtering
                       # For :skip we still need to resume the LRJ MAX_PAUSE_TIME pause
-                      return unless coordinator.filter.action == :skip
+                      return unless coordinator.filter.skip?
                     elsif !revoked? && !coordinator.manual_seek?
                       seek(last_group_message.offset + 1, false, reset_offset: false)
                     end

data/lib/karafka/pro/processing/consumer_groups/strategies/dlq/ftr_lrj_mom_vp.rb

@@ -31,17 +31,14 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           module Dlq
-            # DLQ enabled
-            # Ftr enabled
-            # LRJ enabled
-            # MoM enabled
-            # VP enabled
+            # - DLQ enabled
+            # - Ftr enabled
+            # - LRJ enabled
+            # - MoM enabled
+            # - VP enabled
             module FtrLrjMomVp
               include Strategies::Vp::Default
               include Strategies::Dlq::Vp

data/lib/karafka/pro/processing/consumer_groups/strategies/dlq/ftr_lrj_vp.rb

@@ -31,16 +31,12 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           module Dlq
-            # Dead-Letter Queue enabled
-            # Filtering enabled
-            # Long-Running Job enabled
-            # Virtual Partitions
+            # - Dead-Letter Queue enabled
+            # - Filtering enabled
+            # - Long-Running Job enabled
             module FtrLrjVp
               include Strategies::Vp::Default
               include Strategies::Dlq::Vp

data/lib/karafka/pro/processing/consumer_groups/strategies/dlq/ftr_mom.rb

@@ -31,9 +31,6 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           module Dlq

data/lib/karafka/pro/processing/consumer_groups/strategies/dlq/ftr_mom_vp.rb

@@ -31,9 +31,6 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           module Dlq

data/lib/karafka/pro/processing/consumer_groups/strategies/dlq/ftr_vp.rb

@@ -31,9 +31,6 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           module Dlq

data/lib/karafka/pro/processing/consumer_groups/strategies/dlq/lrj.rb

@@ -31,14 +31,11 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           module Dlq
-            # DLQ enabled
-            # Long-Running Job enabled
+            # - DLQ enabled
+            # - Long-Running Job enabled
             module Lrj
               # Order here matters, lrj needs to be second
               include Strategies::Dlq::Default

data/lib/karafka/pro/processing/consumer_groups/strategies/dlq/lrj_mom.rb

@@ -31,9 +31,6 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           module Dlq

data/lib/karafka/pro/processing/consumer_groups/strategies/dlq/lrj_mom_vp.rb

@@ -31,9 +31,6 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           module Dlq

data/lib/karafka/pro/processing/consumer_groups/strategies/dlq/lrj_vp.rb

@@ -31,15 +31,12 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           module Dlq
-            # Dead-Letter Queue enabled
-            # Long-Running Job enabled
-            # Virtual Partitions enabled
+            # - Dead-Letter Queue enabled
+            # - Long-Running Job enabled
+            # - Virtual Partitions enabled
             module LrjVp
               # Same flow as the Dlq Lrj because VP collapses on errors, so DlqLrj can kick in
               include Strategies::Vp::Default

data/lib/karafka/pro/processing/consumer_groups/strategies/dlq/mom.rb

@@ -31,9 +31,6 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           module Dlq

data/lib/karafka/pro/processing/consumer_groups/strategies/dlq/mom_vp.rb

@@ -31,15 +31,12 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           module Dlq
-            # Dead-Letter Queue enabled
-            # MoM enabled
-            # Virtual Partitions enabled
+            # - Dead-Letter Queue enabled
+            # - MoM enabled
+            # - Virtual Partitions enabled
             module MomVp
               include Strategies::Dlq::Vp
               include Strategies::Dlq::Mom

data/lib/karafka/pro/processing/consumer_groups/strategies/dlq/vp.rb

@@ -31,18 +31,15 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           module Dlq
-            # Dead Letter Queue enabled
-            # Virtual Partitions enabled
+            # - Dead Letter Queue enabled
+            # - Virtual Partitions enabled
             #
-            # In general because we collapse processing in virtual partitions to one on errors, there
-            # is no special action that needs to be taken because we warranty that even with VPs
-            # on errors a retry collapses into a single state and from this single state we can
+            # In general because we collapse processing in virtual partitions to one on errors,
+            # there is no special action that needs to be taken because we warranty that even with
+            # VPson errors a retry collapses into a single state and from this single state we can
             # mark as consumed the message that we are moving to the DLQ.
             module Vp
               # Features for this strategy
@@ -53,6 +50,66 @@ module Karafka
 
               include Strategies::Dlq::Default
               include Strategies::Vp::Default
+
+              # Runs the DLQ strategy and based on it it performs certain operations
+              #
+              # In case of `:skip` and `:dispatch` will run the exact flow provided in a block
+              # In case of `:retry` always `#retry_after_pause` is applied
+              def apply_dlq_flow
+                # Process-critical errors are never dispatched or skipped regardless of the
+                # strategy outcome: the retry pause protects the partition during the critical
+                # shutdown and the failed batch is redelivered after the restart.
+                # We consult `errors_tracker.last` (not the per-consumer consumption cause used
+                # by the OSS strategies, which have no tracker) because it is exactly what the
+                # DLQ strategy callable below receives - this guard judges the same evidence as
+                # the strategy it overrides. The tracker is cleared at attempt zero, so `last`
+                # is always the most recent failure of the current failure streak
+                if critical_error?(errors_tracker.last)
+                  retry_after_pause
+
+                  return
+                end
+
+                # With virtual partitions, a dispatch/skip decision is never made on a
+                # non-collapsed (parallel) run. The deciding consumer operates only on its own
+                # virtual partition subset there: the skippable message would be selected from
+                # an arbitrary subset and the dispatch marking would commit offsets of messages
+                # other virtual partitions never processed. The failure already requested a
+                # collapse, so we retry and let the decision happen on the collapsed, linear
+                # flow where it is deterministic
+                if topic.virtual_partitions? && !collapsed?
+                  retry_after_pause
+
+                  return
+                end
+
+                flow, target_topic = topic.dead_letter_queue.strategy.call(errors_tracker, attempt)
+
+                case flow
+                when :retry
+                  retry_after_pause
+
+                  return
+                when :skip
+                  @_dispatch_to_dlq = false
+                when :dispatch
+                  @_dispatch_to_dlq = true
+                  # Use custom topic if it was returned from the strategy
+                  @_dispatch_to_dlq_topic = target_topic || topic.dead_letter_queue.topic
+                else
+                  raise Karafka::UnsupportedCaseError, flow
+                end
+
+                yield
+
+                # We reset the pause to indicate we will now consider it as "ok".
+                coordinator.pause_tracker.reset
+
+                # Always backoff after DLQ dispatch even on skip to prevent overloads on errors
+                pause(seek_offset, nil, false)
+              ensure
+                @_dispatch_to_dlq_topic = nil
+              end
             end
           end
         end

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

@@ -31,12 +31,8 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
-          # Filtering related init strategies
           module Ftr
             # Only filtering enabled
             module Default

data/lib/karafka/pro/processing/consumer_groups/strategies/ftr/vp.rb

@@ -31,15 +31,12 @@
 module Karafka
   module Pro
     module Processing
-      # Consumer-group-specific Pro 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
           # Filtering related init strategies
           module Ftr
-            # Filtering enabled
-            # VPs enabled
+            # - Filtering enabled
+            # - VPs enabled
             #
             # VPs should operate without any problems with filtering because virtual partitioning
             # happens on the limited set of messages and collective filtering applies the same