Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
tripleee opened this issue Sep 3, 2019 · 3 comments

Comments

@tripleee
Copy link
Contributor

tripleee commented Sep 3, 2019

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
Copy link
Contributor

worth noting that the post was closed as a duplicate.

@makyen
Copy link
Contributor

makyen commented Sep 3, 2019

@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
Copy link
Contributor Author

tripleee commented Sep 4, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants