Handle uncaught error when content directory becomes invalid

[Shawn Stafford]

Description
I am currently experiencing an application error that I believe to be caused when the underlying directory (--dir ) gets removed or updated to point to a new location. After the filesystem update, the next request to the server responds with an HTTP 200 response code and the following content in the body:

curl http://localhost:8085/


Fatal error: Uncaught Error: Call to a member function getUri() on null in /daux/libs/Server/Server.php:155
Stack trace:
#0 /daux/libs/Server/Server.php(66): Todaymade\Daux\Server\Server->handle()
#1 /daux/index.php(80): Todaymade\Daux\Server\Server::serve()
#2 {main}
thrown in /daux/libs/Server/Server.php on line 155

Steps to Reproduce

1. Create a directory called "/tmp/content" containing an index.md file
2. Start the daux docker container, mounting the /tmp/content directory under "/content" and using the "--dir /content" argument
3. Use curl to verify that the index page is returned successfully
4. Use the "docker exec" command to shell into the container and remove the /content/index.md file
5. Use curl again to reproduce the error

Runtime Environment

docker run -p 8085:8085 --rm -it -v /tmp/content:/content -v /tmp/config:/config daux/daux.io daux serve --quiet --host=0.0.0.0 --port=8085 --source=/content --configuration=/config/config.json

Expected behavior

The error needs to be caught and the HTTP response needs to return a 404 or a 500 error.

Additional context

I am trying to deploy the "git-sync" container and the daux container in a kubernetes environment. The git-sync container syncs the markdown files to a volume and the daux container is responsible for serving up the content. However, when the git-sync container pulls down a new commit, it appears to create a new directory and update the symlink to the directory where daux is loading the content. The daux container then fails to load content from that point forward and needs to be restarted in order to work again. I was hoping to force the container to restart under this condition by using a Kuberntes liveness probe on the root URL, but since the daux fails to catch the unhandled error the HTTP server always returns an HTTP 200 response code and the liveness probe will always be successful.

[Stéphane Goetz]

Hello,

The daux serve mode is meant to be used for local writing and not to serve the documentation. It is not at all optimized for serving documentation sites and while it works okay for a few pages it won't scale for bigger documentation sites.

I'd recommend you use the approach documented here instead : #241 (comment)
In the case of git-sync, I've never heard about it. But I'd recommend using a CI pipeline to generate the docker image and deploy it using something like argocd or kubectl (I don't know what tooling you have around your cluster)

[Shawn Stafford]

Thank you for your response. I believe the bug is still a valid issue regardless of how the application is being used. You can reproduce the issue simply by starting the docker container without a valid index.md file in place to begin with and the same behavior is observed. Simply catching the error and handling it by returning a 404 or 500 would be an improvement.

Yes, I can work around the issue by implementing a liveness probe shell script to parse the error message. And yes, I do have Jenkins and ArgoCD and docker registries available and in use by other projects. That may be a route I take in the future, but in the short term I'm simply doing a proof-of-concept while I convert a small number of documents to markdown. This will never be a large collection of documents (maybe a few dozen) and the number of HTTP requests will be small and controlled (maybe a few requests per week) so I am also not concerned about request volume or performance. The ability to start a local container to preview documents while I'm working on them is the primary benefit of using the daux container.