[rattang-dev]

Issue

When a KCL application starts fresh (lease table does not exist), all workers simultaneously perform the initial shard sync operation via syncShardsOnce(). Each worker independently calls DescribeStream/
ListShards, paginating through the entire shard history. For large streams with many workers, this creates a burst of shard discovery API calls proportional to the number of workers, which can cause throttling
by the service and prevent the application from starting.

For example, a stream with 100K shards and 1000 workers would generate ~1000 concurrent ListShards paginations at startup.

Root Cause

The initial shard sync runs before the migration state machine and leader decider are initialized. Without leader election, every worker that finds an empty lease table proceeds to call syncShardsOnce(). The
existing shouldInitiateLeaseSync() method uses a random 1-30 second wait to reduce contention, but this is insufficient for large fleets — multiple workers can finish the wait simultaneously and all proceed
with shard sync.

Description of Changes

This change moves the initialization of the migration state machine and leader decider (migrationStateMachine.initialize() and leaderDecider assignment) before the initial shard sync block. This allows the
shard sync to be gated by leaderDecider.isLeader(), ensuring only the elected leader performs the initial shard discovery.

Why this is safe

• For fresh KCL 3.x deployments (CLIENT_VERSION_CONFIG_3X): The DynamoDBLockBasedLeaderDecider uses the CoordinatorState table (not the lease table) for lock-based leader election. It works correctly with an
  empty lease table. Only one worker acquires the lock and performs shard sync.
• For 2.x → 3.x migration: The lease table is never empty during migration (it has existing 2.x leases), so the isLeaseTableEmpty() check returns false and the shard sync block is skipped entirely. This path
  is unaffected.
• The migrationStateMachine.initialize() is idempotent and safe to call before shard sync. The original comment in the code already notes this.

Testing

• Tested fresh deployment of a KCL v3 application: confirmed only the leader worker performs the initial shard sync
• Tested application restart with existing leases: confirmed shard sync is skipped as expected
• Existing unit tests pass