Inconsistencies with interaction response types.

[GoldenAngel2]

Description
When responding to a select interaction with a message it doesn't reset the state for the user.
(but responding with type: 7 it does reset the state for the user, but you can't respond with a message)

Steps to Reproduce

{ "type": 4, "data": { "content": "test", "flags": 64  } }

• For a message response (doesn't reset the state)

{ "type": 7 }

• For the state to reset.

Expected Behavior
Both should reset the state for the user.

Current Behavior
It doesn't reset the state for type: 4

Screenshots/Videos

Type 7:

Type 4:

Client and System Information
OS: Windows 10
Discord API Version: 9

[ckohen]

I believe the incorrect behavior is what you displayed with type 7 actually. IIRC selects are supposed to locally retain state unless the component is updated. It appears the component is being "updated" even though it should not.

[night]

This behavior looks correct to me. By sending type 7 you are submitting a message update to our server, which is then triggering a MESSAGE_UPDATE event that causes a rerender of the message in clients (telling the client to set the defaults back for components in the message). As stated above components are locally stored state, so the only way to keep persisted state is to set those values as new defaults when updating the message.