Deactivating an account as an application service using user_id yields a response not containing id_server_unbind_result

[ew-at-vier]

Description

The scenario is as follows:

• No 3PIDs or third party identity servers have been used on the synapse server involved.
• There is a configured application service.

The application service wants to deactive an account in its namespace and issues a post
request to

/_matrix/client/v3/account/deactivate?user_id=<some user id from application service user namespace>

with request body of

{}

Synapse answers with http status code 200 and a response body of

{}

not containing id_server_unbind_result in violation of Client Server API Spec accountdeactivate which states as description of the response field id_server_unbind_result:

Required: An indicator as to whether or not the homeserver was able to unbind the user’s 3PIDs from the identity server(s). success indicates that all identifiers have been unbound from the identity server while no-support indicates that one or more identifiers failed to unbind due to the identity server refusing the request or the homeserver being unable to determine an identity server to unbind from. This must be success if the homeserver has no identifiers to unbind for the user.
One of: [success, no-support].

So in this case, it should have answered with a response body of { "id_server_unbind_result": "success" }.

Steps to reproduce

• use clean synapse instance
• configure an application service
• create a user as an application service
• deactivate the user as an application service using the user_id feature explained in Application Service API Spec 1.3.1. Identity assertion
• observe a response not containing id_server_unbind_result.

Homeserver

From hub.docker.com matrixdotorg/synapse:v1.92.3

Synapse Version

{"server_version":"1.92.3","python_version":"3.11.5"}

Installation Method

Docker (matrixdotorg/synapse)

Database

sqlite

Workers

I don't know

Platform

Observed on my developer machine

NixOS 23.05 / amd64

Also observed in an deployment in nomad, I think the nodes are either rocky linux or centos 7.

Configuration

Just an application service with a user namespace and room alias namespace.

Relevant log output

Sorry not observed.

Anything else that would be useful to know?

I assume synapse/rest/client/account.py:307 is the culprit.

Maybe just put return 200, {"id_server_unbind_result": "success"} there to satisfy the spec?

[reivilibre]

Thanks for your report! Looks like it should just process the deactivation in the same way, except for skipping the user-interactive authentication. I've put up #16617 to fix this.