Gatling feeder data lifecycle versus injection profile duration alignment

This question examines the interoperability between Gatling 3.x's feeder mechanism and its injection profile system when simulation duration exceeds the cardinality of the data source. The goal is to determine whether feeder data is automatically cycled, reused, or terminated, and what guarantees exist for record uniqueness across virtual users.

Gatling feeders can be materialized into memory or streamed from disk; injection profiles define user ramp-up, peak count, and simulation length. The interaction between these two features is not explicitly documented for edge cases where the number of virtual users or simulation steps surpasses the feeder's data pool, potentially introducing duplicates or gaps in recorded payloads.

Key uncertainties include whether Gatling applies modulo arithmetic to index feeder entries, how thread-safe access is maintained during concurrent user execution, and whether memory-based feeders incur performance penalties that affect injection timing accuracy.

• Does Gatling cycle feeder data using a modulo index when injection profile duration exceeds feeder cardinality?
• How does the framework ensure thread-safe feeder distribution without duplicating or skipping records across concurrent virtual users?
• What are the practical limits of memory-based feeders versus streamed feeders under sustained injection profiles exceeding typical test durations?