The protocol allows less flags to be generated than possible which could lead to a DoS of the primary liquidation process
The maximum flags (for liquidation) that can exist at the same time should be limited by the maximum number, of flaggerIdCounter which is a uint24, but it is limited by the maximum number of a uint16 instead. Therefore, a maximum of 65535 shortRecords can be flagged for liquidation at the same time. This is way too less if the protocol is used a lot and a market goes up in price, and would therefore lead to a DoS of the liquidation process.\\nThe maximum of the flaggerIdCounter and therefore the maximum of flags that can exist at the same time is limited by the maximum number of a uint24:\\n```\\nuint24 flaggerIdCounter;\\n```\\n\\nIf there are no flags left to override the system tries to generate a new flagId, but it does not use the maximum number of uint24, it uses the maximum number of uint16 instead, which is 65535:\\n```\\n} else if (s.flaggerIdCounter < type(uint16).max) {\\n    //@dev generate brand new flaggerId\\n    short.flaggerId = flagStorage.g_flaggerId = s.flaggerIdCounter;\\n    s.flaggerIdCounter++;\\n} else {\\n    revert Errors.InvalidFlaggerHint();\\n}\\n```\\n\\nThis could be way to less if the protocol is used a lot and the price of a market goes up. Therefore it would prevent creating new flaggerIds and shortRecords with unhealthy CR can not be liquidated.
Set the check to type(uint24).max.
DoS of the liquidation process, which could potentially lead to a lot of shortRecords with unhealthy CR, which could in the worst case lead to the situation that assets are no longer backed enough, and the market needs to be shut down. This would result in a big loss of user funds.
```\\nuint24 flaggerIdCounter;\\n```\\n