[PLA-2010] v2.0.0 API Updates

[v16Studios]

PR Type

Enhancement, Tests

---

Description

• Updated the token mint cap type logic across the codebase, replacing SINGLE_MINT and INFINITE with COLLAPSING_SUPPLY.
• Modified SQL query conditions to reflect the new token cap type.
• Adjusted tests to accommodate the changes in token cap type logic.
• Removed references to TokenMintCapType in test data preparation.

---

Changes walkthrough 📝

	Relevant files
Enhancement	BatchProcess.php Update token mint cap type logic in batch processing          src/Commands/BatchProcess.php Updated token mint cap type logic. Replaced SINGLE_MINT and INFINITE with COLLAPSING_SUPPLY. Adjusted cap amount logic for single mint scenarios. +2/-2      TokensDoNotExistInBeam.php Modify token cap type in SQL query conditions                        src/Rules/TokensDoNotExistInBeam.php Changed token cap type from SINGLE_MINT to COLLAPSING_SUPPLY. Updated SQL query conditions for token cap checks. +1/-1
Tests	UpdateBeamTest.php Update test for token cap type change                                        tests/Feature/GraphQL/Mutations/UpdateBeamTest.php Updated test to use COLLAPSING_SUPPLY instead of SINGLE_MINT. +1/-1      CreateCollectionData.php Remove TokenMintCapType and set cap to null in tests          tests/Feature/Traits/CreateCollectionData.php Removed TokenMintCapType usage. Set token cap to null in test data preparation. +1/-2

---

💡 PR-Agent usage: Comment /help "your question" on any pull request to receive relevant information

[github-actions]

PR Reviewer Guide 🔍

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 PR contains tests

🔒 No security concerns identified

⚡ Key issues to review Possible Bug The conditional logic for setting 'type' and 'amount' under 'cap' might not handle all edge cases correctly, especially when neither condition is true. Consider adding an else case to handle unexpected scenarios. Code Consistency The SQL condition added for 'COLLAPSING_SUPPLY' should be reviewed to ensure it aligns with the intended logic changes and consistency across similar conditions.

[github-actions]

PR Code Suggestions ✨

Category	Suggestion	Score
Possible bug	Add null checks for $claim->collection to prevent null reference exceptions Consider handling the case where $claim->collection might be null before accessing the force_single_mint property to avoid potential null reference exceptions. src/Commands/BatchProcess.php [193-194] -'type' => $claim->quantity == 1 || $claim->collection?->force_single_mint ? TokenMintCapType::COLLAPSING_SUPPLY->name : null, -'amount' => $claim->collection?->force_single_mint ? 1 : null, +'type' => $claim->quantity == 1 || ($claim->collection && $claim->collection->force_single_mint) ? TokenMintCapType::COLLAPSING_SUPPLY->name : null, +'amount' => $claim->collection && $claim->collection->force_single_mint ? 1 : null, Suggestion importance[1-10]: 3 Why: The suggestion correctly identifies a potential null reference issue, but the existing code already uses the null-safe operator (?->), which handles null references. Therefore, the improvement is minor and not crucial.	3

[leonardocustodio]

This was changed to force_collapsing_supply