Skip to content

Conversation

skaunov
Copy link
Contributor

@skaunov skaunov commented Oct 6, 2025

Description

The change is about allowing putting Record with publisher: None sacrificing republishing.

Sorry for so many lateral changes: I had to delve deeper to understand that the change would actually work and during active reading was eliminating redundant pieces which confuse comprehension with misleading supposition (looking for further use of a variable when it is actually just a parameter/argument was most common impediment).

Notes & open questions

I don't have a fine test for this in mind as it doesn't really do anything (because replication context doesn't yield an event). Simultaneously I'm not really satisfied with the approach I took to adapt/fix the test (retaining only Record with publisher: Some); but I need a hint if that's possible to do better due to the same fact of how silent replication is.

Change checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • A changelog entry has been made in the appropriate crates

@skaunov skaunov changed the title kad[feat]: enable putting Record without publisher kad: enable putting Record without publisher Oct 6, 2025
@skaunov skaunov changed the title kad: enable putting Record without publisher kad(feat): enable putting Record without publisher Oct 6, 2025
@skaunov skaunov changed the title kad(feat): enable putting Record without publisher feat(kad): enable putting Record without publisher Oct 6, 2025
Copy link
Member

@elenaf9 elenaf9 left a comment

Choose a reason for hiding this comment

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

Thanks for the PR!

I appreciate the general clean-up of the code, but it does make it hard to review. Given that I currently have limited time for reviews in general, I'd prefer it you could revert unrelated changes unless you feel strongly about them.

Comment on lines +93 to 102
pub fn new<K>(key: K, value: Vec<u8>, publisher: Option<PeerId>) -> Self
where
K: Into<Key>,
{
Record {
key: key.into(),
value,
publisher: None,
publisher,
expires: None,
}
Copy link
Member

Choose a reason for hiding this comment

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

I would prefer if we don't break the API and instead add a new method Record::new_anonymous or similar. And then just set a dummy Id here or sth like that, since the actual ID is replaced in Behavior::put_record anyway.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see what you want. I'd say ("for the record", the pun unintended) I really disagree with the direction, but I don't think my (obvious?) reasons are interesting to anybody now; and it's kinda problems of those who will disentangle the logic the days after. So I can go with it to get anonymous Record upstream. 👿

On the second thought: if instead of a dummy, separate the (new) logic of put_record between new and new_anonymous the change will be not degrading and even more minimal (add new_anonymous and remove the line from put_record).

// single request-response style exchange with a single remote peer. A query
// is made of multiple requests across multiple remote peers.
InboundRequest { request: InboundRequest },
InboundRequest(InboundRequest),
Copy link
Member

Choose a reason for hiding this comment

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

Please revert this change and the one below. We should avoid breaking the API unless it is necessary.

@skaunov
Copy link
Contributor Author

skaunov commented Oct 9, 2025 via email

skaunov added a commit to skaunov/rust-libp2p that referenced this pull request Oct 10, 2025
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.

2 participants