THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
The first scenario is reset offset without committed offsets:
| offset reset strategy | current reset behavior | reset behavior |
| none | throw exception | throw exception |
| earliest | reset to earliest | reset to earliest |
| latest | reset to latest | reset to latest |
| earliest_on_start | reset to earliest | |
| latest_on_start | reset to latest | |
| safe_latest | if group is started newly, reset to latest. if some new partitions is expanded when group is consuming, reset to earliest for these new partitions. | |
| nearest | it only effect when trigger for out-of-range, for this scenario, its behavior is determined by the earliest, or latest, or safe_latest used together. |
The other is when an out of range exception is triggered:
| offset reset strategy | current reset behavior | reset behavior |
| none | throw exception | throw exception |
| earliest | reset to earliest | reset to earliest |
| latest | reset to latest | reset to latest |
| earliest_on_start | throw exception | |
| latest_on_start | throw exception | |
| safe_latest | reset to latest, consistent with latest. | |
| nearest | to the earliest if it was under the range, or to the latest if it was over the range. It has nothing to do with the earliest, or latest, or safe_latest used together. |
...