If a template substitution fails, the appserver crashes

[Julian Edwards]

You are presented with a nice "Internal server error." page.

To recreate, change something like preseed_master to have an invalid variable, and preview the preseed in the node page.

[Julian Edwards (julian-edwards)]

Gavin suggested that we need to handle yaml escaping properly in templates:

-----

We could/ought to add the following escape function to the templates:

    from StringIO import StringIO
    import yaml

    def quote_yaml(thing):
        buf = StringIO()
        dumper = yaml.SafeDumper(buf, encoding=None)
        try:
            dumper.open()
            if isinstance(thing, unicode):
                # Force double-quote style for unicode strings.
                dumper.write_double_quoted(string)
            else:
                dumper.represent(thing)
            dumper.close()
        finally:
            dumper.dispose()
        return buf.getvalue()

[Gavin Panella (allenap)]

Fwiw, that code snippet is a work in progress; it needs testing to ensure it does the right thing for different types. The problem is that this will be used in the midst of a template. The dumper has no understanding of what the context is, e.g. indentation level, so we must choose representations that'll work regardless - like always using a double-quoted string for unicode.

[Raphaël Badin (rvb)]

We render tempita templates in two different places: in the UI (this is mostly a — very useful — debugging feature) and in the API.

In the UI, when rending the template errors, a good solution might be to display an error message with the template, the parameters, and the error we got when rendering the template. This mean creating a wrapper instead of calling durectly the tempita primitive 'template.substitute'.

In the API, we probably need to take a different course of action. In this case, I think we need to return an error. The content of the error might be similar to what I described above (a message with all the information pertaining to the failure) but the important point is that the response should contain an error status code. Now, which one to use is not obvious to me… 409 (conflict) might be a good option.

What do you think?

[Gavin Panella (allenap)]

Sounds good, but I would use 500 Internal Server Error with an explanatory message. From Wikipedia: "The 4xx class of status code is intended for cases in which the client seems to have erred".

[Raphaël Badin (rvb)]

Hum, you're probably right. I suggested 409 because a 500 error usually means the server crashed because of a bug or something. In this case, it's because the user-supplied config is wrong… I wish we had a code for that.