YC: "unknown or expired link" -- fix it already | Hacker News Reader

YC: "unknown or expired link" -- fix it already

24 pointsgyro_robo8 comments

The "unknown or expired link" error message is getting annoying. I spent around 20 minutes composing a reply, only to get the error message on submit. So I went back and reloaded the comment I was replying to in order to get a "fresh closure", but since it wasn't a top-level story I got the "unknown or expired link" message again. Luckily I copied the textarea content so I could paste it in after going back to the top-level story.

Having to go back to the top-level story and reload just to be able to reply is a bug, not a feature. If I open several stories in tabs, by the time I've read the first couple, I might already be out of "closure clock" when I start writing my first reply.

I suggest you increase the number of closures from 20,000 considering YC traffic is steadily increasing (which means they expire more and more quickly). If instead it's not that you're running out of closures, but that you keep restarting the server (why?), just dump your closure hash table to disk on shutdown and re-read it on startup. Basically, make it work as well as every other, non-Arc discussion board on the planet for these very basic operations.

OK, will look into it. The right thing is probably to gc closures waiting for form submissions much more slowly.

Do you create one closure/session/page? Why not just one semi-permanent closure/page?

We did that sort of thing in our CPS Web-app. You can give semi-permanent URI to the continuation closure, if the closure only refers to the persistent objects and not any transient state; for example, the "reply" link attached to each comment. The link works as far as the persistent object (in the "reply" link case, the comment) lives.

Isn't that still brain-damaged? You are alleviating the problem rather than fixing the cause. The cause being using closures means you have to store data for all clients for an unknown amount of time instead of having each client store their own data; it does not scale.

http://news.ycombinator.com/item?id=24790

I've never run into this with News.YC, but yeah, that sort of behaviour is a hassle.

In fact, on our site I've just implemented a form key that's generated with each request (for CSRF prevention). But if you open a form in another tab then it'll generate a new form key and the first submit will fail. Similar problem to the News.YC closure problem ... hmmm.

Anyone else have experience with CSRF prevention and/or this issue? Is the best thing to do to keep a list of (say) the 10 most recent form keys in their session instead of just 1? They could theoretically open 11 tabs and then the first one would fail ... is there a better or safer solution?

I thought this was intentional, to avoid redundant replies.

On the subject of feature requests, different colours for read/unread (well, previously seen/unseen) comments would be nice.

Reply on news.ycombinator.com