WPB-20429: add replace channel's member endpoint

[blackheaven]

https://wearezeta.atlassian.net/browse/WPB-20429

Checklist

• Add a new entry in an appropriate subdirectory of changelog.d
• Read and follow the PR guidelines

[blackheaven]

@fisx thanks you!

[fisx]

btw i think that the problem with the test that only failed on CI, but not locally, was that ensureLocal was called with example.com, which of course failed on CI (even though I'm not sure why it didn't locally?). anyway if i make the entire test non-federated it works fine. for remote conversations, this end-point should fail indeed (even though 4xx would be nicer than 5xx), so it's ok to not that that here.

i've opened another related ticket to be addressed elsehwere.

[pcapriotti]

Looks good. Some comments below. I'm also not sure about the following edge case: what if we want to add user u as admin, but u is already present as a regular member? If I understand the code correctly, nothing would happen. But then u wouldn't be an admin as requested. This violates a general property which you would probably expect. Namely that the outcome of a replace operation does not depend on the current state.

[pcapriotti]

I don't think it's a problem in practice, but why V2?

[blackheaven]

I have missed the 1 in 12.

Thanks, fixed.

[pcapriotti]

Shouldn't it be 13, though?

[blackheaven]

added, but I had to create it

[blackheaven]

Looks good. Some comments below. I'm also not sure about the following edge case: what if we want to add user u as admin, but u is already present as a regular member? If I understand the code correctly, nothing would happen. But then u wouldn't be an admin as requested. This violates a general property which you would probably expect. Namely that the outcome of a replace operation does not depend on the current state.

should I upsert them then?

[blackheaven]

Looks good. Some comments below. I'm also not sure about the following edge case: what if we want to add user u as admin, but u is already present as a regular member? If I understand the code correctly, nothing would happen. But then u wouldn't be an admin as requested. This violates a general property which you would probably expect. Namely that the outcome of a replace operation does not depend on the current state.

should I upsert them then?

As discussed in DM:

I'm not sure about the requirements there, you probably have a better idea than me about what should be the correct behaviour here. I was just pointing out that slight inconsistency. You can probably leave it, I don't think it matters too much.

The RFC is clear on this:

determine which members need to be added and which members need to be removed and execute the adding and removal,

However, I'm not sure it is intentional

[fisx]

However, I'm not sure it is intentional

i'm pretty sure it's not, but it's the letter of the law. i'll make a ticket where we can decide about actually intended behavior so we can move on here. in short: please follow the RFC.

[eyeinsky]

Just a drive-by comment, but as I just noticed the last commit adding V13: it's already present in the develop branch from here 1c2d211 -- just need to rebase.

[blackheaven]

Just a drive-by comment, but as I just noticed the last commit adding V13: it's already present in the develop branch from here 1c2d211 -- just need to rebase.

nice, thanks!

[fisx]

----- MLS.SubConversation.testResendingProposals FAIL (7.48 s; failed at 2025-10-30T10:53:54.755Z) -----
assertion failure:
Failed spawning process

call stack: 
1. assertFailure at test/MLS/Util.hs:836

2. spawn at test/MLS/Util.hs:130

3. runCli at test/MLS/Util.hs:108

4. mlscli at test/MLS/Util.hs:704

5. mlsCliConsume at test/MLS/Util.hs:677

6. consumeMessageWithPredicate at test/MLS/Util.hs:683

7. consumeMessage at test/Test/MLS/SubConversation.hs:381

huh? as in "Failed spawning unix process"? smells flaky.

[battermann]

Approved on behalf of Paolo and Matthias