Skip to content

Conversation

@daksh-r
Copy link
Contributor

@daksh-r daksh-r commented Aug 19, 2025

Goal

handle delete-for-me scenario in messages:

  1. hard delete and delete-for-me are mutually excluding
  2. introduce options object as a second parameter to client.deleteMessage() method
  3. enrich the delete message response message object with type 'deleted' and deleted_for_me boolean flag

@github-actions
Copy link
Contributor

github-actions bot commented Aug 19, 2025

Size Change: +979 B (+0.29%)

Total Size: 338 kB

Filename Size Change
dist/cjs/index.browser.js 112 kB +328 B (+0.29%)
dist/cjs/index.node.js 114 kB +322 B (+0.28%)
dist/esm/index.mjs 112 kB +329 B (+0.3%)

compressed-size-action

@MartinCupela
Copy link
Contributor

@daksh-r if I understand it well, we still need to update client.deleteMessage() and client._deleteMessage() implementation. This will also have impact on offline support (right @isekovanic?).

for the user that deleted it for himself:

What will be the message.type value? Will it be deleted or regular?
What will be the message.text value?

@MartinCupela
Copy link
Contributor

I also see that we will need to update the type Event with deleted_for_me?: boolean attribute.

@MartinCupela
Copy link
Contributor

@daksh-r why the WS event has the following format:

type: "message.deleted"
deleted_for_me: true
message: { … }

but the message object will contain deleted_for_me too (as declared in MessageResponseBase)?

Isn't that duplication? Is it necessary to have deleted_for_me at the root of the WS event object?

@daksh-r
Copy link
Contributor Author

daksh-r commented Aug 19, 2025

@daksh-r why the WS event has the following format:

type: "message.deleted"
deleted_for_me: true
message: { … }

but the message object will contain deleted_for_me too (as declared in MessageResponseBase)?

Isn't that duplication? Is it necessary to have deleted_for_me at the root of the WS event object?

in the ws event, we don't send deleted_for_me inside the message {...} , it only gets sent once at the root of the message.deleted event, when a client subsequently tries to fetch the message(via the queryChannels or getMessage or getManyMessages endpoints) that's when we populate the deleted_for_me field in there.

@daksh-r
Copy link
Contributor Author

daksh-r commented Aug 19, 2025

@daksh-r if I understand it well, we still need to update client.deleteMessage() and client._deleteMessage() implementation. This will also have impact on offline support (right @isekovanic?).

for the user that deleted it for himself:

What will be the message.type value? Will it be deleted or regular? What will be the message.text value?

we only add the deleted_for_me boolean flag to messages, everything else stays as is

connection_id?: string;
// event creation timestamp, format Date ISO string
created_at?: string;
deleted_for_me?: boolean;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it necessary to add this property to the WS event payload root if it is already contained inside the message object? I suppose that this would be message.deleted event that carries the message.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that I already pointed this out and see that the message inside the WS event is not getting the property.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the property has been added recently, can you tell for which request you aren't receiving this ?

you can find the latest sdk spec here

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was just wondering why the property is duplicated in the message WS event root, when it is available in the message object in the same WS event

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no big deal

@MartinCupela
Copy link
Contributor

@daksh-r I have adjusted few things with c7cc175

@MartinCupela MartinCupela force-pushed the feat/add-deleted-for-me-field-in-message-response branch from 1365dc0 to b2df356 Compare October 9, 2025 07:56
@MartinCupela MartinCupela merged commit 26e83c4 into master Oct 9, 2025
6 checks passed
@MartinCupela MartinCupela deleted the feat/add-deleted-for-me-field-in-message-response branch October 9, 2025 10:29
github-actions bot pushed a commit that referenced this pull request Oct 9, 2025
## [9.22.0](v9.21.0...v9.22.0) (2025-10-09)

### Features

* add deleted_for_me field in message response ([#1604](#1604)) ([26e83c4](26e83c4))
* add message delivery receipts ([#1617](#1617)) ([c8a2fe6](c8a2fe6))
@stream-ci-bot
Copy link

🎉 This PR is included in version 9.22.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants