fix: refresh the clicked slot without the reopened view

[XxFran10xX]

Live console on 0.4.2 was logging IndexOutOfBoundsException: Index 46 out of bounds for length 46 from GearRefreshListener line 49.

The click refresh runs one tick after the click and read the raw slot from player.getOpenInventory() at that point. If a chest or menu closed during that tick, the player was back in their own crafting view. countSlots() is top size + bottom size, which is larger than that menu's 46 real slots, so the bounds check passed and getItem threw.

The listener now keeps event.getClickedInventory() and event.getSlot() from the click and refreshes that inventory directly, checking the slot against its size. The cursor refresh is unchanged.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes
  • Gear refreshes now target the clicked inventory slot, preventing updates from being applied to an incorrect slot if the open inventory changes before the refresh.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 44f603cf-92c4-4ab0-b90b-44f2f0dbce02

📥 Commits

Reviewing files that changed from the base of the PR and between 5d06bff and e2bef82.

📒 Files selected for processing (1)

• src/main/java/net/tfminecraft/magic/listener/GearRefreshListener.java

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Walkthrough

Walkthrough

The click handler now captures the clicked inventory and its local slot before scheduling a refresh. On the next tick, it validates and refreshes that slot in the captured inventory. The online-player check and cursor refresh remain.

Changes

Gear refresh handling

Layer / File(s)	Summary
Capture and refresh the clicked slot src/main/java/net/tfminecraft/magic/listener/GearRefreshListener.java	The handler captures the clicked inventory and local slot before deferring work. It refreshes the slot only when the inventory exists and the slot is within its size. The online-player check and cursor refresh remain.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: carolinebondhus

Merge Risk: ⚪ Minimal · up to e2bef

The change addresses the stale-view slot lookup, and no actionable new risk was established for this PR.

Security Architecture Review

Security architecture risk: 🔵 Low · up to e2bef

The change fixes the reported slot mismatch, but a deferred refresh can still modify the previously clicked inventory after the player leaves it. The effect is limited to a clicked slot, and no privilege escalation has been demonstrated; whether that write remains appropriate after a view change is unresolved.

Retained concerns

• Low · security · inferred: The deferred callback can refresh the current occupant of the originally clicked slot after the player leaves that inventory, without revalidating the inventory session or ownership. If the inventory is shared or its slot changes before execution, the write may affect an item other than the one involved in the click. An unauthorized mutation is not established.

Security review details

Security Blast Radius

• inferred — A player click can trigger a later write to one slot of the inventory clicked at that event, including after a view change. Repeated clicks can schedule further callbacks; evidence does not establish broader service or data-store exposure.

Security Findings and Attack Paths

• inferred — If a clicked inventory remains mutable after close and another action changes its slot before the callback, the callback may refresh the new occupant under the original player's event. No permission bypass or harmful cross-player outcome has been verified.

Trust Boundaries and Controls

• observed — The handler ignores cancelled click events, requires a Player and later an online player, validates the captured slot bounds, and writes only when refresh returns a replacement. None of those checks establishes that the player still has the clicked inventory open.

Hardening Proposals

• proposed — Define whether refresh is permitted after the clicked view closes or its slot changes; if not, revalidate the relevant inventory session or item target before writing, while preserving the intended next-tick read of settled click contents.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: refreshing the clicked slot without using the reopened view.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

---

_{A rabbit watched the gear slots gleam
Then saved the clicked one for the next tick’s stream
It checked the inventory, checked the place
And refreshed that slot at a measured pace
The cursor stayed in view
Then hopped away, content too}

_{Comment @coderabbitai help to get the list of available commands.}