Fix deleted rooms persisting in navigation #285
Reference in New Issue
Block a user
Delete Branch "userAdityaa/flotilla:fix-room-delete-nav"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
gt(strictly greater than) — when theROOM_DELETEevent has the samecreated_atas theROOM_META, the room survived the filter. Switched togte.ROOM_DELETEevents inloadRoomso direct navigation to a deleted room picks up the deletion.closes #194
3d9898f6b2to55137237b555137237b5tob42ba377e5@@ -597,2 +597,4 @@Boolean(relay?.supported_nips?.map?.(String)?.includes?.("29"))const getRoomDeleteId = (event: TrustedEvent) =>getTagValue("h", event.tags) || getTagValue("d", event.tags)The
dtag will never match, room delete always usesh@@ -608,0 +618,4 @@if (h) {deletedByH.set(h, max([deletedByH.get(h), event.created_at]))}}this is unnecessary, deletes are already in roomMetaEventsByUrl right?
It’s already there, but after deleting a room and refreshing, the deletion took a second to reflect.
so I did this to avoid the user noticing that delay even for a moment.
let me attach a video for it.
I see, the roomMetaEventsByIdByUrl isn't populated until the event is accepted by the relay? This should be something taken care of by welshman's thunk — it populates both repository and tracker optimistically when publishing. I would debug why that's not working rather than add this band-aid.
please focus on caravel from your side for now since it’s the priority. I’ll dig into this issue a bit more from my end.
See review comments
b42ba377e5to92cc000004@@ -611,3 +613,3 @@for (const event of deleteEvents) {for (const h of getTagValues("h", event.tags)) {const h = getRoomDeleteId(event)Just leave getTagValues, getRoomDeleteId is unnecessary if you understand the data model
@@ -654,1 +658,3 @@filters: [{kinds: [ROOM_META], "#d": [h]}],filters: [{kinds: [ROOM_META], "#d": [h]},{kinds: [ROOM_DELETE], "#h": [h]},It looks like this is the only substantial change, does this fix it on its own?
It seems to be fixed now. Could you please confirm from your side as well?
92cc000004to4c737b26c04c737b26c0to594231ea48Looks good to me