Test Procedure — PlayerSync v2.1.5

CRITICAL

1. Drop + deco rapide + reco (regression Phase 0)

Steps:

Join Server A, fill inventory with a diamond sword
Drop the sword with Q
Immediately disconnect (within 1 second)
Rejoin Server A

Expected:

Inventory does NOT contain the sword
The ItemEntity is still on the ground where dropped
Player has exactly 1 copy of the sword total
Log shows [SAVE] LOGOUT completed then either no SaveToFile BG write or a [GUARD] SaveToFile BG skipped — player already offline in DB

CRITICAL

2. Backpack duplication (Sophisticated Backpacks)

Steps:

Join Server A, craft a SophisticatedBackpack, fill with 10 diamond blocks
Disconnect
Join Server B (configure different Server_id)
Open backpack, count diamond blocks

Expected:

Exactly 10 diamond blocks (no duplication)
Log shows [restore-backpack] uuid=... nbt_keys=... cleared_via=api (or reflection as fallback)
No WARN about failed removeBackpackContents

CRITICAL

3. Sophisticated Storage shulker duplication

Steps:

Join Server A, pack a diamond-filled shulker into your inventory
Have Player B (on same server) open your inventory via admin / trade / viewer
Disconnect Player A
Player A reconnects to Server B
Unpack shulker, count diamonds

Expected:

Exactly original diamond count
Log shows [CONTAINER_CLOSE] for Player B (viewer forced closed)
Log shows [restore-ss] uuid=... nbt_keys=...

CRITICAL

4. Kill -9 / OOM recovery

Steps:

Join Server A, set inventory to known state (put a named diamond)
Find server java PID : jps | grep Forge
Kill brutally : kill -9 <pid> (or Task Manager → End Task on Windows)
Restart server A
Join Server A, check inventory

Expected:

On startup log: [crash-recovery] cleared N orphan online=1 rows
On startup log: [crash-recovery] JVM shutdown hook installed AND ideally (if hook ran): [emergency-flush] flushed N players
Inventory matches last state before kill (within ~10 min auto-save window)

HIGH

5. Zombie peer server join (no 30s wait)

Steps:

In Adminer, manually set player_data.last_server=99999 and online=1 for a test UUID
Join any running server with that UUID

Expected:

Join happens within a few seconds (not 30s)
Log shows [RACE] Peer server 99999 is dead/zombie — taking over
DB now shows last_server=<thisServer>, online=1

HIGH

6. Periodic auto-save (10 min)

Steps:

Set auto_save_interval_minutes=1 in config for quick test
Join server, add items to inventory
Wait 1 minute (watch sync.log)
Kill -9 server
Restart, rejoin, check inventory

Expected:

Log shows [periodic-save] queued snapshots for N player(s) after 1 min
Post-crash inventory reflects the state AT the last periodic tick

HIGH

7. Pool saturation WARN log

Steps:

Wait 5 minutes after server start (for first PoolStatsReporter tick)
Grep sync.log for [POOL]

Expected:

At least one line like [POOL] executor active=0 queue=0 pool_idle=4 | hikari active=0 idle=4
No WARN unless under load

HIGH

8. Heartbeat updates server_info

Steps:

In Adminer, watch server_info.last_update for this server's id
Refresh every 20s for 1 minute

Expected:

last_update advances by ~10000 ms at every refresh
Log shows [heartbeat] started on boot

MEDIUM

9. Curios capability unavailable — no wipe

Steps:

Equip curios items, die in lava
Force-disconnect during death animation
Reconnect

Expected:

If cap was unavailable: log shows [store-curios] handler unavailable for ... skipping write
Curios row in DB NOT wiped

MEDIUM

10. Cross-server claim + downstream short-circuit

Steps:

Player connected on Server A
Disconnect then immediately join Server B (within 200ms)
Check sync.log on Server A

Expected:

Server A may log [GUARD] (last_server guard blocked) if B claimed during A's save
If blocked: [SAVE_SKIP] LOGOUT skipped: core guard blocked
Player inventory on B = inventory as it was on A (no merge, no overwrite)

Regression checks

Watch for these regressions after Phase 0-5 deployment:

TPS drop during auto-save ticks (periodic save at 10 min should be invisible to gameplay)
HikariCP leak warnings — leakDetectionThreshold=25000, warnings mean a connection held >25s
CallerRunsPolicy triggering (queue full) — look for WARN [pool-stats] executor queue high
Deadlock on logout → join (bgLock serialization) — log should show [SAVE] LOGOUT completed within ~500ms
Reflection fallback firing repeatedly — means upstream removeBackpackContents / removeStorageContents API broke

Procédure de Test — PlayerSync v2.1.5 (Version Française)

Mise en place

Scénarios à tester

CRITIQUE

1. Drop + déco rapide + reco (régression Phase 0)

Étapes :

Join Serveur A, remplir l'inventaire avec une épée de diamant
Drop l'épée avec Q
Déconnecter immédiatement (moins d'une seconde)
Rejoin Serveur A

Résultat attendu :

L'inventaire ne contient PAS l'épée
L'ItemEntity est toujours au sol où elle a été drop
Le joueur a exactement 1 copie de l'épée au total
Logs : [SAVE] LOGOUT completed puis soit aucun write SaveToFile BG, soit [GUARD] SaveToFile BG skipped — player already offline in DB

CRITIQUE

2. Duplication Backpack (Sophisticated Backpacks)

Étapes :

Join Serveur A, craft un SophisticatedBackpack, remplir avec 10 blocs de diamant
Déconnecter
Join Serveur B (configurer un Server_id différent)
Ouvrir le backpack, compter les blocs de diamant

Résultat attendu :

Exactement 10 blocs de diamant (pas de duplication)
Logs : [restore-backpack] uuid=... nbt_keys=... cleared_via=api (ou reflection en fallback)
Aucun WARN sur un removeBackpackContents raté

CRITIQUE

3. Duplication shulker Sophisticated Storage

Étapes :

Join Serveur A, packer un shulker plein de diamants dans l'inventaire
Faire ouvrir l'inventaire par un autre Joueur B (via admin / échange / viewer)
Déconnecter le Joueur A
Joueur A se reconnecte sur Serveur B
Déballer le shulker, compter les diamants

Résultat attendu :

Compte de diamants identique à l'original
Logs : [CONTAINER_CLOSE] pour le Joueur B (viewer force-fermé)
Logs : [restore-ss] uuid=... nbt_keys=...

CRITIQUE

4. Recovery kill -9 / OOM

Étapes :

Join Serveur A, mettre l'inventaire dans un état connu (poser un diamant nommé)
Trouver le PID java du serveur : jps | grep Forge
Kill brutal : kill -9 <pid> (ou Task Manager → End Task sur Windows)
Redémarrer le serveur A
Join Serveur A, vérifier l'inventaire

Résultat attendu :

Au boot : log [crash-recovery] cleared N orphan online=1 rows
Au boot : [crash-recovery] JVM shutdown hook installed ET idéalement (si le hook a tourné) : [emergency-flush] flushed N players
L'inventaire correspond au dernier état avant kill (dans la fenêtre auto-save ~10 min)

HIGH

5. Join sur serveur peer zombie (pas d'attente 30s)

Étapes :

Dans Adminer, setter manuellement player_data.last_server=99999 et online=1 pour un UUID test
Joindre n'importe quel serveur en cours avec cet UUID

Résultat attendu :

La connexion se fait en quelques secondes (pas 30s)
Logs : [RACE] Peer server 99999 is dead/zombie — taking over
La DB affiche maintenant last_server=<thisServer>, online=1

HIGH

6. Auto-save périodique (10 min)

Étapes :

Setter auto_save_interval_minutes=1 en config pour un test rapide
Join le serveur, ajouter des items à l'inventaire
Attendre 1 minute (surveiller sync.log)
Kill -9 du serveur
Redémarrer, rejoin, vérifier l'inventaire

Résultat attendu :

Log : [periodic-save] queued snapshots for N player(s) après 1 min
L'inventaire post-crash reflète l'état AU dernier tick périodique

HIGH

7. Log WARN sur saturation pool

Étapes :

Attendre 5 minutes après le boot du serveur (premier tick PoolStatsReporter)
Grep sync.log pour [POOL]

Résultat attendu :

Au moins une ligne comme [POOL] executor active=0 queue=0 pool_idle=4 | hikari active=0 idle=4
Aucun WARN sauf sous charge

HIGH

8. Heartbeat update server_info

Étapes :

Dans Adminer, surveiller server_info.last_update pour l'id de ce serveur
Refresh toutes les 20s pendant 1 minute

Résultat attendu :

last_update avance de ~10000 ms à chaque refresh
Log : [heartbeat] started au boot

MEDIUM

9. Capability Curios absente — pas de wipe

Étapes :

Équiper des items curios, mourir dans la lave
Force-déconnecter pendant l'animation de mort
Reconnexion

Résultat attendu :

Si cap absente : log [store-curios] handler unavailable for ... skipping write
Row curios en DB NON wipée

MEDIUM

10. Claim cross-server + court-circuit downstream

Étapes :

Joueur connecté sur Serveur A
Déco puis immédiatement join Serveur B (<200ms)
Vérifier sync.log sur Serveur A

Résultat attendu :

Serveur A peut logger [GUARD] (last_server guard a bloqué) si B a claim pendant la save de A
Si blocké : [SAVE_SKIP] LOGOUT skipped: core guard blocked
Inventaire joueur sur B = inventaire tel qu'il était sur A (pas de merge, pas d'overwrite)

Vérifications régressions

Surveiller ces régressions après le déploiement Phases 0-5 :

TPS drop pendant les ticks auto-save (la save périodique à 10 min doit être invisible gameplay)
Warnings HikariCP leak — leakDetectionThreshold=25000, warnings = connexion tenue >25s
Déclenchement CallerRunsPolicy (queue pleine) — WARN [pool-stats] executor queue high
Deadlock sur logout → join (sérialisation bgLock) — le log doit montrer [SAVE] LOGOUT completed en ~500ms
Fallback reflection qui tourne répétitivement — signifie que l'API upstream removeBackpackContents / removeStorageContents a été cassée

Test Procedure — PlayerSync v2.1.5

Setup

Scenarios to test

1. Drop + deco rapide + reco (regression Phase 0)

2. Backpack duplication (Sophisticated Backpacks)

3. Sophisticated Storage shulker duplication

4. Kill -9 / OOM recovery

5. Zombie peer server join (no 30s wait)

6. Periodic auto-save (10 min)

7. Pool saturation WARN log

8. Heartbeat updates server_info

9. Curios capability unavailable — no wipe

10. Cross-server claim + downstream short-circuit

Regression checks

Procédure de Test — PlayerSync v2.1.5 (Version Française)

Mise en place

Scénarios à tester

1. Drop + déco rapide + reco (régression Phase 0)

2. Duplication Backpack (Sophisticated Backpacks)

3. Duplication shulker Sophisticated Storage

4. Recovery kill -9 / OOM

5. Join sur serveur peer zombie (pas d'attente 30s)

6. Auto-save périodique (10 min)

7. Log WARN sur saturation pool

8. Heartbeat update server_info

9. Capability Curios absente — pas de wipe

10. Claim cross-server + court-circuit downstream

Vérifications régressions