|
421 | 421 | | `pausing/with_manual_pause_same_message_loop_spec.rb` | We should be able pause on a message we've already seen from the batch and should always start from it after resuming. This will mean, we just process same message over and over again. | |
422 | 422 | | `pausing/with_pause_and_resume_after_reclaim_spec.rb` | We can pause and after revocation and re-claim we should continue processing like pause did not happen. We should not keep the pause after a rebalance. Messages that were consumed by another process should not be re-consumed. | |
423 | 423 | | `pausing/with_pause_and_resume_spec.rb` | We should be able to do things like pausing and resume in the same consumer flow. This should not break the ordering | |
| 424 | +| `pro/admin/recovery/affected_groups_spec.rb` | When scanning a __consumer_offsets partition for affected groups, we should discover all consumer groups that have committed offsets on that partition. | |
| 425 | +| `pro/admin/recovery/affected_partitions_spec.rb` | When querying affected partitions for a broker, we should get back all __consumer_offsets partitions led by that broker. | |
| 426 | +| `pro/admin/recovery/coordinator_for_spec.rb` | When looking up the coordinator for a consumer group, we should get back valid broker information matching the real cluster. | |
| 427 | +| `pro/admin/recovery/migrate_consumer_group_partial_partitions_spec.rb` | Demonstrates the two-step migration workflow when the source group has committed offsets for only some partitions. The target group should receive only those partitions. | |
| 428 | +| `pro/admin/recovery/migrate_consumer_group_spec.rb` | Demonstrates the two-step consumer group migration workflow using Recovery to read offsets and ConsumerGroups.seek to write them to the target group. | |
| 429 | +| `pro/admin/recovery/offsets_partition_for_spec.rb` | offsets_partition_for should return a valid partition number for the __consumer_offsets topic, be deterministic for the same input, and produce different results for different inputs. | |
| 430 | +| `pro/admin/recovery/read_committed_offsets_cross_group_isolation_spec.rb` | When two different consumer groups have committed offsets for the same topic, Recovery should only return offsets for the requested group and not leak offsets from other groups. | |
| 431 | +| `pro/admin/recovery/read_committed_offsets_large_offset_spec.rb` | When a consumer group has committed very large offsets, Recovery should return them correctly without integer overflow or truncation issues. | |
| 432 | +| `pro/admin/recovery/read_committed_offsets_latest_wins_spec.rb` | When a consumer group commits offsets multiple times, Recovery should return the latest committed offset (last write wins). | |
| 433 | +| `pro/admin/recovery/read_committed_offsets_lookback_window_spec.rb` | When reading committed offsets with last_committed_at set to now, commits that happened before it should not be returned. This verifies the last_committed_at parameter works correctly. | |
| 434 | +| `pro/admin/recovery/read_committed_offsets_no_offsets_spec.rb` | When a consumer group has never committed any offsets, Recovery should return an empty hash. | |
| 435 | +| `pro/admin/recovery/read_committed_offsets_partial_partitions_spec.rb` | When a consumer group has committed offsets for only some partitions of a multi-partition topic, Recovery should return only the partitions that have committed offsets and not include others. | |
| 436 | +| `pro/admin/recovery/read_committed_offsets_with_offsets_spec.rb` | When a consumer group has committed offsets and we read them via Recovery, we should get back the correct offsets per topic and partition. | |
| 437 | +| `pro/admin/recovery/read_committed_offsets_zero_offset_spec.rb` | When a consumer group has committed offset 0 for a partition, Recovery should return it correctly and not treat it as a missing/falsy value. | |
| 438 | +| `pro/admin/recovery_multi_broker_sequential/affected_partitions_distributed_spec.rb` | In a multi-broker cluster, __consumer_offsets partitions should be distributed across brokers. affected_partitions should return different subsets for each broker, and together they should cover all partitions exactly once. | |
| 439 | +| `pro/admin/recovery_multi_broker_sequential/blast_radius_workflow_spec.rb` | End-to-end blast radius assessment workflow on a multi-broker cluster: 1. Pick a broker via coordinator_for (known to work) 2. Find which __consumer_offsets partitions it leads (affected_partitions) 3. Discover which consumer groups live on those partitions (affected_groups) 4. Verify those groups are indeed coordinated by that broker (coordinator_for) | |
| 440 | +| `pro/admin/recovery_multi_broker_sequential/coordinator_for_multi_broker_spec.rb` | In a multi-broker cluster, different consumer groups should map to different coordinators. This verifies that coordinator_for returns valid broker info and that groups are distributed across the cluster. | |
| 441 | +| `pro/admin/recovery_multi_broker_sequential/migrate_workflow_multi_broker_spec.rb` | End-to-end two-step migration workflow on a multi-broker cluster: 1. Read committed offsets via Recovery (bypasses coordinator) 2. Verify the target group maps to a different coordinator 3. Write offsets to target group via ConsumerGroups.seek 4. Verify offsets match via both Recovery and standard Admin APIs | |
424 | 442 | | `pro/cli/declaratives/health_multi_broker_sequential/all_healthy_multi_broker_spec.rb` | Integration test for topics health command when all topics are healthy | |
425 | 443 | | `pro/cli/declaratives/health_multi_broker_sequential/critical_rf_one_spec.rb` | Integration test for topics health command detecting RF=1 (no redundancy) | |
426 | 444 | | `pro/cli/declaratives/health_multi_broker_sequential/critical_zero_fault_tolerance_multi_broker_spec.rb` | Integration test for topics health command detecting RF <= min.insync (zero fault tolerance) | |
|
0 commit comments