search

SO-Close-Vote-Reviewers / UserScripts

Various user scripts that add features to the review queue or to the chat room
Other
57 stars 41 forks source link

UnclosedRequestReview.user.js showed question as "deleted" when it was not #171

Open tripleee opened 5 years ago

tripleee commented 5 years ago

Myself and Rene both observed this; a post which I submitted a del-pls for showed as "deleted" even though it was only closed at the time.

Original request: https://chat.stackoverflow.com/transcript/message/47200872

Follow-up, with screenshot: https://chat.stackoverflow.com/transcript/message/47200876#47200876

rschrieken commented 5 years ago

worth noting that the post was closed as a duplicate.

makyen commented 5 years ago

@tripleee How did you obtain the URL which was used in your del-pls request message? Was it something provided by SE? If so, under what conditions?

The URL in your request was ... unusually formed. The URL in your request message was:

https://stackoverflow.com/questions/57767289/how-to-fix-headers-already-sent-error-in-php?noredirect=1#57767289

The URL fragment (everything after the #) is SE's normal method of indicating to the end user that a fully resolved URL is an answer. A normal, fully resolved Stack Exchange answer URL will look like:

https://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php/60496#60496
                     question ID----^^^^^                   answer ID twice------^^^^^#^^^^^

The answer ID is repeated twice, once at the end of the path and again as the fragment. However, what matters to a human viewing the page is entirely the fragment, because that determines where the page will be scrolled to. In other words, what they will be shown as the destination of the link is whatever the fragment is.

The URRS currently assumes that if a fragment exists and is numeric (comment fragments are alphanumeric), then the fragment represents an answer ID. Given that a del-pls can be about either an answer or question, if the link looks like it's to an answer, the URRS doesn't force it back to the question. It also doesn't try to check to see if the fragment matches the question ID number (i.e. what was the case here). A fragment to a question ID would do nothing, because there is no element with an HTML id attribute or named anchor which is the question ID that exists in the page for the question (this is the first I've seen such in an SE URL). Thus, there's been no reason to believe that the URRS should discriminate between fragments that are answers and fragments that are questions.

So, the URRS attempted to get the data for that ID as an answer, and got no data. Getting no data is the way the SE API indicates that a post is deleted, so the URRS assumed that the "answer" was deleted.

While the URRS tries to get data as both questions and answers for IDs which it can only identify as a "post", it does not try to get question data for things it's identified as answers, nor does it try to get answer data for IDs it's identified as questions. It could do so, at least in one direction (i.e. whichever request was issued 2nd), but doing it both directions would require an additional SE API request each time data was fetched and there was at least one deleted post in the 2nd direction (up to a 50% increase in requests). At the time it was written, I was concerned there would be too many SE API requests made by the URRS, particularly if running in multiple tabs, so I didn't choose to increase the number of requests. As it turns out the number of requests it uses isn't really all that high, so trying both questions as answers and answers as questions would be possible.

Note: Data can be requested as a "post", which will tell you if it's an answer or a question, but the posts endpoint doesn't give all the data which the URRS uses from questions or answers. So, the answer and question requests would still need to be made, which makes the posts endpoint not useful for the URRS.

tripleee commented 5 years ago

I'm not entirely sure where I copy/pasted it from. Probably I had clicked on the inbox notification for the comment where I was pinged https://stackoverflow.com/questions/57767289/how-to-fix-headers-already-sent-error-in-php?noredirect=1#comment101969966_57767289 and then that would have been left in my browser's location bar. I try to remember to control-click the question title (or use the "share" link) but I probably forgot in this case.