`navPerShareHighMark` not reset to 1.0
The LMPVault will only collect fees if the current NAV (currentNavPerShare) is more than the last NAV (effectiveNavPerShareHighMark).\\n```\\nFile: LMPVault.sol\\n    function _collectFees(uint256 idle, uint256 debt, uint256 totalSupply) internal {\\n        address sink = feeSink;\\n        uint256 fees = 0;\\n        uint256 shares = 0;\\n        uint256 profit = 0;\\n\\n        // If there's no supply then there should be no assets and so nothing\\n        // to actually take fees on\\n        if (totalSupply == 0) {\\n            return;\\n        }\\n\\n        uint256 currentNavPerShare = ((idle + debt) * MAX_FEE_BPS) / totalSupply;\\n        uint256 effectiveNavPerShareHighMark = navPerShareHighMark;\\n\\n        if (currentNavPerShare > effectiveNavPerShareHighMark) {\\n            // Even if we aren't going to take the fee (haven't set a sink)\\n            // We still want to calculate so we can emit for off-chain analysis\\n            profit = (currentNavPerShare - effectiveNavPerShareHighMark) * totalSupply;\\n```\\n\\nAssume the current LMPVault state is as follows:\\ntotalAssets = 15 WETH\\ntotalSupply = 10 shares\\nNAV/share = 1.5\\neffectiveNavPerShareHighMark = 1.5\\nAlice owned all the remaining shares in the vault, and she decided to withdraw all her 10 shares. As a result, the `totalAssets` and `totalSupply` become zero. It was found that when all the shares have been exited, the `effectiveNavPerShareHighMark` is not automatically reset to 1.0.\\nAssume that at some point later, other users started to deposit into the LMPVault, and the vault invests the deposited WETH to profitable destination vaults, resulting in the real/actual NAV rising from 1.0 to 1.49 over a period of time.\\nThe system is designed to collect fees when there is a rise in NAV due to profitable investment from sound rebalancing strategies. However, since the `effectiveNavPerShareHighMark` has been set to 1.5 previously, no fee is collected when the NAV rises from 1.0 to 1.49, resulting in a loss of fee.
Consider resetting the `navPerShareHighMark` to 1.0 whenever a vault has been fully exited.\\n```\\nfunction _withdraw(\\n    uint256 assets,\\n    uint256 shares,\\n    address receiver,\\n    address owner\\n) internal virtual returns (uint256) {\\n..SNIP..\\n    _burn(owner, shares);\\n    \\n// Add the line below\\n if (totalSupply() == 0) navPerShareHighMark = MAX_FEE_BPS;\\n\\n    emit Withdraw(msg.sender, receiver, owner, returnedAssets, shares);\\n\\n    _baseAsset.safeTransfer(receiver, returnedAssets);\\n\\n    return returnedAssets;\\n}\\n```\\n
Loss of fee. Fee collection is an integral part of the protocol; thus the loss of fee is considered a High issue.
```\\nFile: LMPVault.sol\\n    function _collectFees(uint256 idle, uint256 debt, uint256 totalSupply) internal {\\n        address sink = feeSink;\\n        uint256 fees = 0;\\n        uint256 shares = 0;\\n        uint256 profit = 0;\\n\\n        // If there's no supply then there should be no assets and so nothing\\n        // to actually take fees on\\n        if (totalSupply == 0) {\\n            return;\\n        }\\n\\n        uint256 currentNavPerShare = ((idle + debt) * MAX_FEE_BPS) / totalSupply;\\n        uint256 effectiveNavPerShareHighMark = navPerShareHighMark;\\n\\n        if (currentNavPerShare > effectiveNavPerShareHighMark) {\\n            // Even if we aren't going to take the fee (haven't set a sink)\\n            // We still want to calculate so we can emit for off-chain analysis\\n            profit = (currentNavPerShare - effectiveNavPerShareHighMark) * totalSupply;\\n```\\n