Repository navigation
Conversation
A pet removed while its async load is still pending skipped SavePetToDB, but the pet stable still moved it out of the current slot. Its row stayed at slot 0, and once the next pet was saved as current the owner had two slot 0 rows, which makes the character show twice on the character list. - While loading, a removal to a stable or unslotted slot now writes the new slot, and abandoning the pet deletes it, so it no longer returns on the next login. - Saving a non-hunter pet as current moves other slot 0 rows of the owner to PET_SAVE_NOT_IN_SLOT. - Cleanup for existing summoned pet duplicates keeps the most recently saved one.
Self-review — claude/fix-duplicate-current-pet-6ddd90 → masterOutcome 3 findings — 3 fixed — final round clean Tested in-game by the author Reviewed By Claude Code, Opus 5.5 ( Review details (3 rounds)Intent Prevent an owner from having more than one Project rules Diff Metadata Not mirrored from another core, so no upstream author credit applies. Rounds 1–2 (carried forward)
Round 3 —
|
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.
|
No actionable comments were generated in the recent review.
|
|
Yes, #22737 is this bug. A warlock with two #25301 looks like a different problem, so I wouldn't close it with this. The pet named "Voidwalker" comes from a newly summoned demon being saved before it gets its generated name. If the server crashes before the next save, the template name sticks. This PR doesn't touch that. The mount/dismount swap might be related to a duplicate slot 0 row, but I haven't confirmed it, so I'd keep that issue open. |
Changes Proposed:
This PR proposes changes to:
A warlock could end up with two demons in
character_petslot 0 (current pet). The character enum joinscharacter_peton the current slot, so the character then shows up twice on the character select screen.The cause is a pet being removed while its async load (
PetLoadQueryHolder) is still pending.Pet::SavePetToDBskipped every write whilem_loadingwas set, but the pet stable still moved the pet out of the current slot in memory. The row stayed at slot 0, and when the next demon was saved as current there were two. For example: a demon is resummoned from slot 0 after dismounting or zoning in, and a fast summon of another demon finishes before the load does.Changes:
Pet::SavePetToDB: while the pet is loading, spells and auras are still not saved (they are not loaded yet), but a removal to a stable or unslotted slot now writes the new slot, and abandoning the pet deletes its rows. Before, a hunter pet abandoned during the load came back as current on the next login.PET_SAVE_NOT_IN_SLOT, in the same transaction (new statementCHAR_UPD_CHAR_PET_SLOT_BY_SLOT_EXCLUDE_ID). Hunter pets keep their existing delete of slot 0 rows.PetType = 0) with several slot 0 rows, keeps the most recently saved one and moves the rest to slot 100. Hunter rows are left alone, since the core does not support a hunter having a current and an unslotted pet at the same time.Review guide:
src/server/game/Entities/Pet/Pet.cpp(SavePetToDB) is where the judgment is. The statement and the SQL update are mechanical.AI-assisted Pull Requests
Important
Using AI tools to prepare pull requests is allowed, but it must be disclosed and it must follow our AC guidelines for AI Agentic Engineering (link below).
You are expected to fully understand the changes you submit and to be able to explain and justify them when maintainers ask.
Issues Addressed:
SOURCE:
The changes have been validated through:
Tests Performed:
This PR has been:
How to Test the Changes:
SELECT id, entry, slot FROM character_pet WHERE owner = <guid>must have one row at slot 0.Known Issues and TODO List:
Player::_LoadPetStablestill assume a single slot 0 row; they are left unchanged since the writer no longer produces duplicates and the SQL update cleans existing ones.How to Test AzerothCore PRs
When a PR is ready to be tested, it will be marked as [WAITING TO BE TESTED].
You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:
http://www.azerothcore.org/wiki/How-to-test-a-PR
REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).
For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.