Member.top_role not updating when positions change

[Silari]

Summary

If a role position is changed, calling member.top_role does not update the top role if it has changed. It still shows whatever the old top position was.

Only similar issue still open is #2142 but that involved role creation and the cache, where these roles are being edited and the new position is set correctly.

Expected Results

The top_role property to always return the role with the highest position.

Actual Results

The old top role is still returned as the top role, despite it being moved to a lower position or another role being moved higher. The output of the following code in an on_message(message) event shows the issue.

msg = "Roles:"
for myrole in message.guild.me.roles:
    msg += " Name: " + myrole.name + " Position:" + str(myrole.position)
print(msg)
msg = "Top Role: " + message.guild.me.top_role.name + " " str(message.guild.me.top_role.position)
print(msg)

Roles: Name: @everyone Position:0 Name: PicartoBot-Dev Position:2 Name: Trixie Position:5
Top Role: Trixie 5

The highest role is Trixie, as it should be. After moving the Trixie role to just above @everyone (Position 1) and rerunning:

Roles: Name: @everyone Position:0 Name: PicartoBot-Dev Position:3 Name: Trixie Position:1
Top Role: Trixie 1

It still lists Trixie as the highest role, despite having updated the role with it's new position.

Looking at the code for Member.top_role, it seems like the list of roles should be sorted in ascending position order, but it's not being resorted when the role position is updated, thus causing top_role to return the wrong role.

Checklist

• I have searched the open issues for duplicates.
• I have shown the entire traceback, if possible.
• I have removed my token from display, if visible.

System Information

• Python v3.7.2-final
• discord.py v1.3.3-final
• aiohttp v3.6.2
• websockets v6.0
• system info: Windows 10 10.0.18362

[Rapptz]

I believe this happens because the cache for roles is not invalidated upon roles being updated. Invalidating the cache at this stage becomes kind of expensive so I may have to reconsider the cache layer here to properly fix this. Unsure at the moment.