Skip to content

fix: Don't download pre-message again if it is known already - #8488

Open
Hocuri wants to merge 2 commits into
mainfrom
hoc/fix-ignoring-pre-message
Open

fix: Don't download pre-message again if it is known already#8488
Hocuri wants to merge 2 commits into
mainfrom
hoc/fix-ignoring-pre-message

Conversation

@Hocuri

@Hocuri Hocuri commented Jul 29, 2026

Copy link
Copy Markdown
Collaborator

There was a bug in prefetch_should_download() that it made it return true for pre-messages even when they were already downloaded. This meant that pre-messages were downloaded from all relays, rather than just one, wasting internet data.

The fix is in rfc724_mid_download_tried(), which is used by prefetch_should_download() to determine whether a message was already downloaded.

There was a bug in prefetch_should_download() that it made it return true for pre-messages even when they were already downloaded. This meant that pre-messages were downloaded from all relays, rather than just one, wasting internet data.

The fix is in rfc724_mid_download_tried(), which is used by
prefetch_should_download() to determine whether a message was already
downloaded.
Comment thread src/message.rs
Comment thread src/message.rs Outdated
Comment on lines 2180 to 2184

@hpk42 hpk42 Jul 29, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

the docstring is not now mapping the sql statement anymore, if i see it correctly? also half-copying the sql statement is not very helpful IMO. Maybe something like this?

/// Returns `true` if the given `rfc724_mid` has nothing left to fetch from a server,
/// i.e. it was already fetched, sent by us, or received as a pre-message.
pub(crate) async fn rfc724_mid_nothing_to_fetch(context: &Context, rfc724_mid: &str) -> Result<bool> {

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

For pre-messages, this function behaves exactly the same as for normal messages: It returns true iff the message was already fully fetched and is therefore in the database. It is post-messages that are treated differently, because for them there can be some in-between states where they are in the database but were not fetched yet, or it was tried to fetch them but unsuccessfully.

rfc724_mid_nothing_to_fetch() sounds misleading because the function returns true if a post-message was tried to fetch but network was lost halfway through. In this case, we still give the user the possibility to try again.

I tried adding some documentation, is it understandable?

@hpk42 hpk42 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

looks like a good fix overall (see comments for docstrings/naming suggestions).
Still may makes sense if somebody else approves, as i am not on solid ground with the current state of ephemeral/deletion mechanisms, and it's a sensitive area.

@link2xt link2xt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Looks good, agree that the documentation comment for rfc724_mid_download_tried should say something about pre-messages.

Comment thread src/message.rs
// Explanation of the SQL statement:
// - For messages that were not split into pre- and post-messages,
// the SQL statement is equal to `rfc724_mid=?1`
// because `download_state` is always `Done` and `pre_rfc724_mid is always an empty string.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Suggested change
// because `download_state` is always `Done` and `pre_rfc724_mid is always an empty string.
// because `download_state` is always `Done` and `pre_rfc724_mid` is always an empty string.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants