We have a list of phrases that get replaced in titles and their replacements (which can be the empty string if we simply want to remove something). A moderator accidentally added an identical pair to it.
> We have a list of phrases that get replaced in titles and their replacements (which can be the empty string if we simply want to remove something). A moderator accidentally added an identical pair to it.
This should prove once and forever that tail recursion is dangerous and does not help with real world problems. Clearly, blowing up the stack would have been the appropriate and safer response here.
Yeah, that would replace an infinite loop with a stack overflow in that specific case, but I'm not sure that all infinite loop bugs can be converted to stack overflow bugs in the general case. Another commenter's suggestion to "have tests and a staging environment" makes more sense to me.
I think you mean that TCO is dangerous. Besides, this is probably more of an implementation problem. Do you really want to be applying a filter like this multiple times?
If I had to implement this, I would just imagine that just taking your mapping, and for each key,value , do a title.replace(key,value). I would be a "good enough" solution , and in the worst case you still have human editors on HN.
Interestingly, distinguishing between "non-loopy" and "potentially loopy" sets of rewrite rules seems to be equivalent to the halting problem :-( The key phrase would be "tag systems".
Sorry, this is uneducated bullshit. There was a infinite loop and that was a error in programming logic. Limiting loops a certain number of iterations is absolute bogus. Ever though how stupid it sounds to demand c to forbid while(1)?
yup. It took me literally several minutes before I saw the word "outage" in there for some reason. For some reason the non-word "gelet" overwhelmed my brain so I kept seeing out-a-gelet. Kind of like port-a-potty. Then I migrated to outa-gelet->ou-tage-let->o-utage-let->(I skipped ou-tagel-et because that looked like a german word sandwiched between two french words)->outage-let---eureka, where's my bath tub!
For a hardcoded list that is manually edited frequently, maybe a duplicate-safe data structure would be preferably. It might require an extra line to parse out duplicates, but at least a page won't fail if something like this happens again.
Presumably a hit on any of the "before" keys triggers not just a replacement with the corresponding "after", but another pass through either a subset of the replacement list starting from the key that matched, or the entire replacement list from the top down; otherwise an identical pair wouldn't have a chance to be pathological.
Don't know about phrases, but exclamation points are automatically removed, so "!" -> "" in this case. The problem arose because someone replaced an unidentified X with X, resulting in an infinite recursion.
I think you should do your best to always return an appropriate HTTP status header, and in this case it is status 503 (Service Temporarily Unavailable). You really want to reserve 403's for those pesky w00t w00ts :) , ' aNd 1=1 and the likes.
Getting 403's with my personal account, but gaining (slow) access through another browser, I was convinced that the issue had to do with my account being blocked.
In this case using nginx allow and deny statements was much easier than doing bit fiddling in Lua and returning 503s. Any time spent researching other options would have been time not spent determining the problem.
Often getting to the root of the problem as quickly as possible while simultaneously keeping the site up (practical) wins over always using correct HTTP response codes (pedantic).
This should prove once and forever that tail recursion is dangerous and does not help with real world problems. Clearly, blowing up the stack would have been the appropriate and safer response here.