Closed ichorid closed 2 years ago
Seems like log output from this statement:
[Administration] This should not be crashing IPv8: lowering priority to "enhancement".
It would be better to log a warning in case of OP and return from on_created()
if circuit_id not in self.circuits
.
Well, this is definitely a bug in Anonymization community, and since the code responsible for this is hosted in this repository, I report it here :wink:
@ichorid I'm not sure what the latter half of your comment is responding to. I never claimed that you are posting in the wrong repository.
I do not see the grounding in the former half of your comment stating "this is definitely a bug". All I see is a log statement that prints the abrupt termination of a message handler (at the correct point in the execution flow) and then logs this abnormal execution flow. I see that we can "enhance" this by describing the abnormal execution better in a log statement of lesser severity, which is why I labeled this issue as an "enhancement". Could you elaborate on your statement?
I see that we can "enhance" this by describing the abnormal execution better in a log statement of lesser severity,
Well, as the IPv8 author you see an opportunity for enhancement of logging statements. As the maintainer of Tribler anonymity feature, I see a bug in the Anonymity community logic :shrug: I'm going to file a PR to address this at the level of Anonymity community logic.
You stated "this is definitely a bug in Anonymization community" and I asked you to elaborate on this statement because I do not agree and I gave you the reason why. You answered with "I see a bug in the Anonymity community". This is a repetition and it does not explain anything. Being a maintainer of Tribler anonymity doesn't address this lack of explanation in any way. You could be Her Majesty The Queen of England and it still would not explain why you see this as a bug. Please explain your point of view.
If you cannot qualify why this log statement should be anything but a log statement, please don't expect any PR to the most fragile internals of IPv8 to be anything but instantly rejected.
Well, the original post above explained the bug ("What happens is..."). Let's elaborate:
remove_circuit
, which (correctly) removes the circuit_id
from self.circuits
while (incorrectly) leaving the associated cache in place.CreatedPayload
back (correctly)on_created
), checks (correctly) if there exists the associated cache entry (it is still there) and proceeds to get the associated circuit from self.circuits
dict. p.s. regarding your :crown: of :gb: comment, I just pointed out that we have different views :eyes: of the subject: for you as the IPv8 maintainer, it is enough to ensure that IPv8 does not crash on random community bugs. Indeed, it does not crash in this case. While for me, as the (hopefully, temporary) AC maintainer, merely demoting an interpreter error to a warning is not enough - I must investigate every such case and solve the root problem :shrug:
Thank you. That gave me enough information to understand and reproduce this issue. Feel free to open a PR to resolve this.
As the cache that is left behind cleans itself in 10 seconds, there is no permanent damage to the TunnelCommunity (just the ugly log statement). Therefore, through the definitions of "bug" and "enhancement" used in the IPv8 repository (not some personal view), this issue qualifies as an "enhancement". I agree that it would be nicer to remove the cache immediately though.
Please use the following unit test to verify the new behavior:
Observed during anonymization tests:
What happens is:
remove_circuit
removescircuit_id
fromself.circuits
, while leaving the associated"retry"
request_cache
uncleaned. Then,on_created
receives a message, sees the cache is still there and tries to get access it, resulting in the error above.