spacebarchat / spacebarchat/server

Owner of Group DM cannot remove people from DM

Open
#1,081 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Bug
Dominant language
TypeScript
Stars
2.2k
Forks
323
Avg merge
14h 48m
Merged PRs (30d)
4

Description

I am running into weird behaviour with the server and i am pretty sure that this is weird/unintended server behaviour

Creating a DM, be it group dm or 1:1 dm, returns a channel object.

If i create a 1:1 DM channel, the channel object has 2 recipients: the user who created the channel, and the other user
When creating a group DM however, even when I add 3 people, the user who created the channel never shows up in the recipients of the returned channel. I can't find anything indicating that it should be this way.

Consider these two screenshots:
Here's a group DM which should have 3 People: "integrationtestuser", "integrationtestuser2" and "integrationtestuser3":
grafik

And here is a regular 1:1 DM between "integrationtestuser" and "integrationtestuser2":
grafik
and the runtime error which occurs, when trying to call the endpoint which removes a recipient from a group DM:
grafik

P.S: when looking into dm_channel using the debugger, owner_id is None, both in the regular DM and in the group DM:
grafik
Also not sure if this is intended.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing group DM creation and the endpoint that removes a recipient, comparing how the returned channel’s recipients are populated with how dm_channel.owner_id is handled. Use the reported runtime error and the two DM cases as reproduction points. Done means the intended owner and recipient behavior is consistent and removing a group-DM recipient no longer fails.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
api, backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.