TLDR: we should add an Unknown variant to NoteRelevance to handle notes for which we can't be sure if they can be consumed or not. That way to interpret the return value of check_relevance is:
Non-empty vector: the note can be consumed by one of the tracked accounts.
It might contain some accounts whose NoteRelevance is Unknown, meaning we can't be sure they can or can't consume the note.
Empty vector: the note is valid and we know for sure it cannot be consumed by any of the tracked accounts.
Error: either the note is invalid.
on #208 we're introducing the NoteScreener struct. It's capable of receiving a note and returning whether it is relevant to the client or not and if so by which accounts. By relevant to the client we mean that it can be consumed either now or somewhere in the future. Its check_relevance function does that and also handles malformed input, returning an error in certain cases. This is working fine since for known notes that's all there is to it. However, once we introduce the ability to check arbitrary notes with custom scripts we'll need to try and consume the note. That execution might return an error because it's too early or there's another problem.
To keep it short, an error during execution might not mean that it's not consumable but it's not currently consumable (but might be in the future). In those scenarios we'd like to keep those notes around as we don't know for sure whether they can be consumed or not, thus the need of a NoteRelevance::Unknown variant.
Good point! I think then maybe we do need to have something like NoteRelevance::Unknown variant. So, basically, the "for sure invalid" case still stays as an error - but the "maybe invalid" cases becomes NoteRelevance::Unknown variant. And then the caller will need to filter out unknowns or do w/e based on their requirements.
TLDR: we should add an
Unknownvariant toNoteRelevanceto handle notes for which we can't be sure if they can be consumed or not. That way to interpret the return value ofcheck_relevanceis:NoteRelevanceisUnknown, meaning we can't be sure they can or can't consume the note.on #208 we're introducing the
NoteScreenerstruct. It's capable of receiving a note and returning whether it is relevant to the client or not and if so by which accounts. By relevant to the client we mean that it can be consumed either now or somewhere in the future. Itscheck_relevancefunction does that and also handles malformed input, returning an error in certain cases. This is working fine since for known notes that's all there is to it. However, once we introduce the ability to check arbitrary notes with custom scripts we'll need to try and consume the note. That execution might return an error because it's too early or there's another problem.To keep it short, an error during execution might not mean that it's not consumable but it's not currently consumable (but might be in the future). In those scenarios we'd like to keep those notes around as we don't know for sure whether they can be consumed or not, thus the need of a
NoteRelevance::Unknownvariant._Originally posted by @bobbinth in https://github.com/0xPolygonMiden/miden-client/pull/208#discussion_r1550333040_