Validate tool target compatibility#14
Conversation
|
Warning Review limit reached
Next review available in: 56 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds capability metadata ( ChangesItem Schema Capability Validation
Sequence Diagram(s)sequenceDiagram
participant Inventory
participant ItemSchema
Inventory->>ItemSchema: IsKeyCompatibleWithCrate(keyDefIndex, crateDefIndex)
ItemSchema-->>Inventory: compatibility result
Inventory->>ItemSchema: CanApplyStickerToDefIndex / CanApplyPatchToDefIndex(targetDefIndex)
ItemSchema-->>Inventory: eligibility result
Inventory->>ItemSchema: CanNameDefIndex(defIndex)
ItemSchema-->>Inventory: nameable result
Inventory->>Inventory: proceed or reject with logged message
Estimated code review effort: 🔵🔵🔵⚪⚪ (Medium-High, involves new schema validation logic touching multiple inventory operations) Related issues: None referenced in the provided summary. Related PRs: None referenced in the provided summary. Suggested labels: enhancement, item-schema, inventory Suggested reviewers: GT-610 🌸 A crate that once popped without a care, 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
csgo_gc/inventory.cpp (1)
863-911: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsolidate the duplicate
item_item_idlookup.
m_items.find(message.item_item_id())is performed twice — once to computetargetDefIndex(lines 870-878) and again to resolveitem(lines 903-911). Both rely on the samemessage.baseitem_defidx()condition to stay consistent; merging them removes the redundant lookup and the risk of the eligibility-check target and the mutated item diverging if either branch is edited independently in the future.♻️ Proposed consolidation
- uint32_t targetDefIndex = 0; - if (message.baseitem_defidx()) - { - targetDefIndex = message.baseitem_defidx(); - } - else - { - auto it = m_items.find(message.item_item_id()); - if (it == m_items.end()) - { - assert(false); - return false; - } - - targetDefIndex = it->second.def_index(); - } + CSOEconItem *targetItem = nullptr; + uint32_t targetDefIndex = 0; + if (message.baseitem_defidx()) + { + targetDefIndex = message.baseitem_defidx(); + } + else + { + auto it = m_items.find(message.item_item_id()); + if (it == m_items.end()) + { + assert(false); + return false; + } + + targetItem = &it->second; + targetDefIndex = targetItem->def_index(); + } if (sticker->second.def_index() == ItemSchema::ItemPatch) { if (!m_itemSchema.CanApplyPatchToDefIndex(targetDefIndex)) { Platform::Print("ApplySticker: patch item %llu cannot be applied to target def %u (target item %llu)\n", message.sticker_item_id(), targetDefIndex, message.item_item_id()); return false; } } else if (!m_itemSchema.CanApplyStickerToDefIndex(targetDefIndex)) { Platform::Print("ApplySticker: sticker item %llu cannot be applied to target def %u (target item %llu)\n", message.sticker_item_id(), targetDefIndex, message.item_item_id()); return false; } - CSOEconItem *item = nullptr; - if (message.baseitem_defidx()) - { - item = &CreateItem(message.baseitem_defidx(), ItemOriginBaseItem, UnacknowledgedInvalid); - } - else - { - auto it = m_items.find(message.item_item_id()); - if (it == m_items.end()) - { - assert(false); - return false; - } - - item = &it->second; - } - - assert(item); + CSOEconItem *item = message.baseitem_defidx() + ? &CreateItem(message.baseitem_defidx(), ItemOriginBaseItem, UnacknowledgedInvalid) + : targetItem; + + assert(item);🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@csgo_gc/inventory.cpp` around lines 863 - 911, The ApplySticker flow in inventory.cpp repeats the same message.item_item_id() lookup in two branches, once to derive targetDefIndex and again to resolve item, which can drift if edited separately. Refactor the logic around the ApplySticker handling so the baseitem_defidx() / m_items.find(message.item_item_id()) decision is made once and the resulting item or target data is reused for both the eligibility check and the item mutation, keeping the target-def validation and resolved item consistent.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@csgo_gc/inventory.cpp`:
- Around line 863-911: The ApplySticker flow in inventory.cpp repeats the same
message.item_item_id() lookup in two branches, once to derive targetDefIndex and
again to resolve item, which can drift if edited separately. Refactor the logic
around the ApplySticker handling so the baseitem_defidx() /
m_items.find(message.item_item_id()) decision is made once and the resulting
item or target data is reused for both the eligibility check and the item
mutation, keeping the target-def validation and resolved item consistent.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: caa8fc3e-aa47-4d62-9ec3-bbcd03f08682
📒 Files selected for processing (3)
csgo_gc/inventory.cppcsgo_gc/item_schema.cppcsgo_gc/item_schema.h
1 participant
Summary
Validation
Manual test notes
Summary by CodeRabbit
Bug Fixes
New Features