WardCunningham
server loses welcome-visitors page
I've seen an edited welcome-visitors page revert back to the default template, a page with two factories. Some possibly relevant information:
- sinatra server running as a farm on a mac mini
- blocked from any login by editing a bogus open_id.identity (read only site)
- under more than usual traffic due to posting url to twitter (maybe one page view per second in peaks)
- diff with local copy shows only one page affected: welcome-visitors
There should be no circumstance where pages are written on a read only site. However, an exception to this rule occurs when GETing a page that does not exist but for which there is a page in default-data/pages. The page is created from default on demand.
My guess is that some read error occurred under load and this was interpreted as a queue to make the default page. If this can be established as the case then two things come to mind:
- the server should be more careful when creating default pages. error responses should be read carefully. maybe even page absence should be confirmed before writing the default data.
- default-data/pages should be cleaned out. no need for all those pages that at one time could be shared by no other means.
I'm kind of thinking that we may want to do away with default data fall back completely, and instead when a site is created we 'prime' its data/pages with any defaults we want (for the main project that would probably be just the welcome-visitors page with relevant forks in it.) This would simplify a lot of things as we move forward towards supporting multiple databases/storage mechanisms.
Yes, it could be that simple. We could leave welcome-visitors in default-data/pages for now but copy it on creation instead of on demand if that is more convenient for the server implementation.
The rest of those pages should go on fed.wiki.org under the assumption I can keep it running.
There might be some value having help pages in default-data/pages so that they are in sync with a release but we don't do that now.
The data loss mechanism here is similar to that in issue #181. Same solution (defensive programming) probably applies.