Why does HN emit "Unknown or expired link" messages
I can't count how many times I've hit the reload button while browsing Hacker News, only to see "Unknown or expired link". I understand there are myriad technical excuses for this, but it still has a significant effect on user experience.
Am I supposed to just forgive this, because I'm a technical person and can easily get out of the jail that his error message puts me in?
42 comments
[ 3.6 ms ] story [ 84.0 ms ] threadespecially: http://news.ycombinator.com/item?id=163696
[edit: Thanks for the reply aston. My mistake]
But if HN is strictly a quick and dirty tool, then you are right. It is not worthy to make it a topic for discission.
This is an unpopular opinion, but this needs to be said: to keep the quality of Hacker News relatively high, please follow the very few HN guidelines.
The general problem we're looking at is that fnid's (and the accompanying closures) are manufactured all over the place, and most of them don't need to stay around for very long.
However, there are some of these--in particular the ones created for sending a comment to be posted in a thread--that probably deserve a guaranteed lifetime on the order of hours, not minutes. Putting them into a different fnid queue is what I'd call a relatively easy fix, and that'd handle 95% of the complaints about expired links.
The other 5% are due to trying to reply to comment for a thread you opened a while back. I actually don't know why that's even coded the way it is. The reply link could easily just refer back to the post id instead of an fnid.
edit: I would probably be willing to fix this stuff myself, but as of late it seems pg's not been paying that much attention to news.yc. Also, last time I threw up a patch, I got burned pretty bad.
"The User doesn't care why this isn't working, or if it's a lot of work to fix it. Don't explain it - fix it. Every other message board works correctly."
Being as this is hacker news, I'm sure we can all deal, and understand the technical bits involved. Just saying, in this case, do as PG says, nawt as he does.
I work for Amie Street. We are an e-commerce site where the price of each product continuously changes. I am knee-deep in scenarios where things expire. Yes, it's an entirely different situation, but it has the same significance. Every time an Amie Street user gets an expiration message, we get negative feedback.
Still annoying? Definitely.
http://news.ycombinator.com/item?id=363
The easiest solution, then, is to simply increase the length of time that the continuations are held -- hence increasing the number of continuations held at once. If this were as simple as changing a number somewhere, I assume PG would have already done it. Hence it is likely that the server is already retaining as many continuations as it can at any one time, expiring them as it goes.
So the obvious solutions are: Get a heftier web server; rewrite mzscheme's continuations to take less resources; or rewrite HN to not use continuations. The first cannot be done with source code alone, the second has yet to be accomplished by Scheme's brightest minds, and the third is unlikely to appeal to PG.
(Edit: Not that I want to discourage anyone from improving Scheme, arc, or HN... just pointing out that the solution is harder than a simple bug fix.)
My particular example was for browsing the thread list. Let's s/continuation/browse context/. You can generate exactly one browse continuation a minute, and hand that one out to everyone who visits the page during that minute. It contains the effective state for that continuation. So it's a little out of date... big deal.
Let's say a browse context is 1 kilobyte (which can fit a list of several hundred IDs and scores). With 1 gigabyte of RAM, you can store 1.9 years worth of browse contexts.
When a user is logged in, one browse context is generated per link-that-requires-a-browse-context. Each "reply" link references a new browse context each time a page is loaded, for example. So if there are 50 comments on a page, then there are 50 "reply" links, each of which references a unique browse context. (If you mouseover each reply link in Firefox, you can see the ID of its browse context in the status bar. If you refresh the page, each reply link then references a different, unique, server-side browse context.)
So it's easy to see why this could get a little expensive. It's essentially a time-consuming optimization problem to get rid of the "unknown or expired link" error, at this point. And it is not hard to work around.
I wonder if these fnid-less URLs avoid generating continuations? If so, perhaps we could drop the "reply" link entirely and just label the "link" link as "link/reply"? If I understand your explanation correctly, that would both eliminate the error for initial replies and dramatically reduce the rate that continuations expire when using other site features...
When a logged-in user loads a Hacker News page, the server must generate a unique set of continuations for that user (one per each link that requires a continuation.) In other words, if everyone shared the same set of continuations, everyone would see the exact same Hacker News. The username in the upper-right corner would be the same, everyone's comments would be tagged with the same username, etc. Does that make sense?
So the "reply" link requires a continuation because you're adding a comment that's tagged with your username. But the "link" link does not require one because you're simply viewing a comment.
It's obviously a slightly different user experience, since users that aren't logged in won't get prompted to register/log in when clicking on "reply".
So, I'm not talking about reply. I'm not talking about links. Just giving me the main list of threads, that's why I wanted to call it "browse context". Not "reply context".
I also do not suggest sending the "browse context" to the user. I'm suggesting sending an ID to the user, while the server can store up to 1.9 years worth of browse contexts, so that I can hit reload on the main page for up to 1.9 years without seeing an expiration.
I would solve issues with reply separately. Maybe HN is meant to just be a demonstration of the power of continuation-based web dev.
I guess this could totally thrash performance by causing a lot of disk I/O, but I have no sense of how likely this is. If you had some statistics about the rate of continuation-cache misses and how often cache evictions occur, you could probably get a good idea whether it's feasible.
http://www.cs.brown.edu/pipermail/plt-scheme/2007-February/0...
Perhaps it is possible under other Schemes, though?
This has been addressed repeatedly already.