ames: ignore message-num.task for %drop tasks #6996
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
tl;dr: not working, but wanted to get some eyes on it first since this behavior has been in place since the %alef rewrite.
When a message is nacked (e.g. seq=25), we add it to nax.sink and create a %naxplanation message (e.g. seq=1; first ever naxplanation sent) that contains the nacked sequence number (25), and send it to the original sender on the naxplanation flow.
When the ack for the naxplanation (seq=1) comes back, we know that this was an ack for a naxplanation bone and then drop the sequence number of this naxplanation message (seq=1) instead of the original message (seq=25) that was nacked.
This causes a range of messages in nax.sink that will remain there until naxplanations catch up with the actual message numbers from the reference flow.
We are removing messages that might not have been nacked, but that seems ok since the message won't be there anyway. But this could mean that there are gaps in the sequence of messages that we have nacked so the fact that there are messages in nax.sink doesn't mean that we can say: "if a sequence number higher than what's in the queue is not in nax.sink, we can we assume that it has not been nacked?".
In any case, it looks like this behavior has not caused any (known?) issues, and as of this commit, this change introduced some problems (re: looking into it right now) so as it stands I wouldn't say that we should fix this before Directed Messaging is released since we could introduce other problems, but wanted to have some eyes on it since it looks like some of this was a part of the %alef rewrite (e.g. nax.peer-state which was never used, only nax.sink in the .message-sink) but got dropped when it got merged into %ames.
(PS: wip, currently does not work)
(PPS: a space-leak fix targeted these nacked messages directly and removed anything that had already been acked)