What behaviour is observed:

Nothing appears to be working after updating. There is just a massive amount of problems. Prior to updating to 3.0, everything worked perfectly.

1. Using /setskin appears to no longer do anything. Your skin never changes.
2. There's no 429 handling? If the plugin receives a 429 error, it seems to just give up rather then trying in X minutes, or trying another source.
3. The plugin is attempting to insert records that already exist.. https://pastebin.com/K9YvFXWN

There's clearly an issue with MySQL handling in version 3.0
https://i.gyazo.com/a75925397abd1a321951c5d4f7339aa8.png

What behaviour is expected:

For /setskin to change skins, 429 errors to be properly handled rather then ignored (Based on observation, have not checked the code), and for one one record per UUID to exist in my table.

Steps/models to reproduce:

I just use the plugin on my Bungeecord instance, and one of the spigot servers in the bungee network. I also use MySQL rather then SQLite

Plugin list:

Essentials, WorldEdit, WorldGaurd, Protocollib, NoCheatPlus, AAC

Environment description

Bungeecord, and only one of the spigot servers in the network use this plugin. The server version is 1.8, and the Bungeecord version is always within a week of the latest bungeecord release. The server is hosted on a dedicated machine, with a local MySQL instance. Server is also in Offline mode

Plugin version or build number (don't write latest or the build number with #):

3.0

Error Log:

https://pastebin.com/K9YvFXWN

And the HTML 429 stacktrace is pretty self explanatory

Configuration:

https://pastebin.com/mHu6vw52

Update to a dev-build please. You are 43 commits behind with version 3.0.

Duplicate entry

Fixed after multiple tries (Next time I should make a branch for this) and with a lot helpful of some users.
Commits affecting this:
c47113c
a95906f
61cc473
b6f1779
11ae586
59b337d
6125c56
fbfdfbd

429 errors handling

This should now be handled better with more logging messages to the user instead of just logging it.

It appears to have worsened. Now i only get "UUID was successfull resolved from the player name"

You should probably put "successfully" too

Using build #9​4 and the same database + table I've been using since initially using this plugin. Should i reset the database?

There's also no exceptions to be found. I've also noticed for whatever reason the command /setskin is NOT logged to latest.log.

https://pastebin.com/WmLNEfiG

I found exceptions in the bungeecord log. The table is just screwed up behold repairing so I'm going to reset it later tonight when my traffic dies down.

I'll update you on whether or not a table reset resolves my issues.

You should never reset a single table. Only both if you really need it. That exception means that the same got requested too often within one minute.

Please post the complete BungeeCord log.

Giving you the complete log will compromise my users IP's. The only errors in the log are the one provided, and the insert on existing values only happens sometimes on joins it seems. There are 0 errors other then that.

Rundown:

1. I join the server with the username bob7l. My skin is properly set to the bob7l skin and my data exists within the MySQL.

15:56:21 [INFO] [bob7l] <-> ServerConnector [rustv2] has connected
15:56:21 [FINE] [ChangeSkin] Applying skin for bob7l
15:56:21 [INFO] [bob7l] <-> DownstreamBridge <-> [lobby] has disconnected

2. I then execute /setskin Notch. It says with a green message the UUID was resolved successfully and nothing more. My skin still remains the same, so i exit and rejoin. Still the same skin (instant-skin is disabled in my config).

3. I then execute /setskin bob7l Notch from the console and get "UUID was sucessfull" followed by "Skin was changed. Relogin to see the changes".

4. I re-log into the server and still have the exact same bob7l skin.

Zero errors during the whole process. I just reset my tables for SkinData and preferences today and still nothing. I am using build #99.

My assumption is it's not reading from the MySQL correctly and using my default skin no matter what.

Here is the data for bob7l:

https://i.gyazo.com/7f7e6fb40ca64b0e5f41d33561d68643.png
https://i.gyazo.com/c7ed030f05900d02eb3c2acda241a968.png

"Notch's" skin URL: a116e69a845e227f7ca1fdde8c357c8c821ebd4ba619382ea4a1f87d4ae94
"Notch's" UUID: 069a79f444e94726a5befca90e38aaf5

bob7l's UUID (preferences): e07381471d993189bd5081d8355c25f8
bob7l's skin URL: 88e8b7798bd67ec8710f14c642a6c88df57ef46badef39ceb3b317da53b6045
bob7l's UUID inside skinData: cc45fc40168b4ca996f665235c713209

After i relogged, it seems it set my skin back to bob7l because now my target skin points back to my actual account rather then notch.

Still broken: https://pastebin.com/mEueZt5r

You're clearly inserting already existing values instead of using UPDATE.

:D I already know that. It's a race condition with multiple saves. I still need the complete log please.

/setskin also appears to have a permanent cooldown. "Please wait, You cannot change your skin so fast" 8 hours later. My cooldown: 600

Also another thing i just realized. I never got a cooldown before. I believe the reason i got it this time is because i used the console to execute the setskin.

I am able to set the skin through the console using /setskin bob7l Notch. The skin sets fine (Although i do not visually see it due to having instant change off). When i relog however, the skin is set back to the default bob7l skin by the BUNGEE instance.

Giving you the complete log will compromise my users IP's.

That's a valid reason. Why don't you told me that earlier. You could easily remove the IP addresses:
sed -r 's/[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}/CENSORED/g' *.log It just complicates the things a lot if I cannot see the context.

Rundown: [...]

What you are describing here is different bug... Do you tried to execute it from the Spigot or the Bungee console?

/setskin also appears to have a permanent cooldown. "Please wait, You cannot change your skin so fast" 8 hours later. My cooldown: 600

Fixed now. The number was accidentally in minutes.

When i relog however, the skin is set back to the default bob7l skin by the BUNGEE instance.

You mean from default skins or using restore skins?

Please keep tickets independent from each other next time. It's easier to isolate the details.

BTW What are your BungeeCord plugins, because I cannot reproduce it with ChangeSkin installed alone on it?

EDIT: Could you also try it with an empty blacklist? Maybe there is an issue.

I confirmed the issue ONLY occurs with "bukkit-permissions: true". I've tested this on a test server with zero other plugins.

Bungee version; #1​30​5
Spigot version: 1.10.2-R0.1-SNAPSHOT, And tested on 1.8

Using LuckPerms-Bukkit-4.1.25 and tested latest PEX too

[23:09:35] [Server thread/INFO]: bob7l issued server command: /op bob7l
[23:09:35] [Server thread/INFO]: [bob7l: Opped bob7l]
[23:09:37] [Server thread/INFO]: Incomming message: 1522217377122
[23:09:37] [Server thread/INFO]: ChangeSkin
[23:09:37] [Server thread/INFO]: bob7l
[23:09:37] [Server thread/INFO]: Channel:PermissionsCheck
[23:09:37] [Server thread/INFO]: rowId: 1
[23:09:37] [Server thread/INFO]: encodedData: eyJ0aW1lc3RhbXAiOjE1MjIyMTM3NzM4NTMsInByb2ZpbGVJZCI6ImNjNDVmYzQwMTY4YjRjYTk5NmY2NjUyMzVjNzEzMjA5IiwicHJvZmlsZU5hbWUiOiJib2I3bCIsInNpZ25hdHVyZVJlcXVpcmVkIjp0cnVlLCJ0ZXh0dXJlcyI6eyJTS0lOIjp7InVybCI6Imh0dHA6Ly90ZXh0dXJlcy5taW5lY3JhZnQubmV0L3RleHR1cmUvODhlOGI3Nzk4YmQ2N2VjODcxMGYxNGM2NDJhNmM4OGRmNTdlZjQ2YmFkZWYzOWNlYjNiMzE3ZGE1M2I2MDQ1In19fQ==
[23:09:37] [Server thread/INFO]: encodedSignature: A//ftEjFjCHV+IV0f24j+RlmUvwsD9ljuyFbfQMzUgIgl6A+Ys0D06MiVmPD7OJa3BUDICHCgIDTa77jCf4M2IduB4l+2H0GLnEzirbvx66HNPeb3E7eehEtcFKIb4c8GHbW0CZQQaa++YPRD4JEniEM/8hPOPx2Vyn2JHNrKnksOhRr/cwB8bC4jEkvYmsIrW421O27thoMSp0NeWPElieZwyq9Cm57RrmRjguvVWGM8wC9bylzpN+jAyUrYa6qSgRgc4TW4lj0wjnikBjb2TVq62ZjyVNFkH+pQy4+pjstKoV6Z0S2yspxNjpIAURgipeuincSYnzHuCX0h8XykhWCWAtJ4qKKULc2uVoqsOfqc1YZdq84OPqSfMzE+6I0acDv0mN2qUxDyRmI0FH1AO9fW5pBluRRLjSqvsaUpz7hCHRy8DzVm10r/wcg9lirDTXyWRsiZcuABQOhDZ+G3qSu8T7w3YFLyAsF/L8oJtSAEZkqkofHBLxDQkL2/RXAbKUanqMcQZEc37sCRyvuX80mt39RMYX1GazihzQxLHAKhPv3rOfuVrC4/uOXonKAI9C2/Kpv9Ws0UDtCmXms2rrcHHS65Oa8YvdJJNaCBrOzHX/bs1DJo1w3K33beUi0E3FNXoT173QjNIzdOjvMw8YSesEvOZK2eJto9+dZZoc=
[23:09:37] [Server thread/INFO]: receiverUUD: e0738147-1d99-3189-bd50-81d8355c25f8
[23:09:37] [Server thread/INFO]: skinPerm: false
[23:09:37] [Server thread/INFO]: isOp: false

This is listening to the plugin channel on the spigot server and printing all the data. bob7l is op and it still says isOp: false.

BTW: Never use #Number it's used to reference to other tickets.

You are misunderstanding something here. The OP status is not bound to Bukkit, it's bound to BungeeCord that why it's always false.

Using LuckPerms-Bukkit-4.1.25 and tested latest PEX too

If you are already using LuckPerms, why don't you use the BungeeCord module of it. This way ChangeSkin doesn't have to worry about permissions forwarding.

Still some open questions:

Do you tried to execute it from the Spigot or the Bungee console?
Could you also try it with an empty blacklist? Maybe there is an issue. [In combination with your newer answer maybe a combination of both]

What about the response. Do you checked if it it response with a successful response too?

I've tried with every configuration combination, that includes blacklist being an empty array.

I believe I figured out the problem.

When i join my hub server, I am able to /setskin perfectly and the Bungee server actually receives a PluginMessage from ChangeSkin. When I go into another server using /server survival I can no longer use /setskin and if i have "bukkit-permissions" DISABLED I'm able to set the skin, but the only message it gives me is the UUID was resolved. Also, in the survival server with bukkit-permissions ENABLED, the Bungee instance of ChangeSkin never even receives a plugin message from the spigot ChangeSkin whereas in the hub it does.

Bungee (Skin) -> Lobby (Skin) -> Survival Server (No skin)

Could you check if ChangeSkin is installed in all Spigot servers and it correctly detected BungeeCord. ChangeSkin only listens to plugin messages if BungeeCord is enabled.

why dont u just put dev build on spigot every month? (genuinely curious)

@Spikey101 I only want to release well tested version to Spigot.