Suggestion for more friendly debugging

[lordaugustus]

Sometimes I would encounter error like this:

[error] 5326#0: *1247 lua entry thread aborted: runtime error: /usr/local/openresty/lualib/template.lua:182: invalid value (userdata) at index 7 in table for 'concat'

I wish the error log would report the exact variable name that is invalid. That would be really helpful. Thanks a lot!

[bungle]

Good suggestion. Can you give me an example file, and call where you encounter this error. It would help me get going with this enhancement (you may replace that error causing userdata with ngx.null). I know that the lua-resty-template is quite a brutal right now, but let's see if we can make it better in that sense. Extra checks and debugging information usually means a performance hit, but maybe we could introduce debugging/development mode here with Nginx config flag:

set $template_debug on;

Regards
Aapo

[lordaugustus]

Hello, ngx.null is common to be encountered when you get result from lua-resty-redis and lua-resty-mysql. For demostration purpose, recreating this error is quite easy, like this

local test = {
a="good",
b=ngx.null
}
local template = require "resty.template"
local view = template.new([[

{{test.a}}

{{test.b}}

]])
view.test = test
view:render()

The resulting error would be like this
[error] 7297#0: *1740 lua entry thread aborted: runtime error: /usr/local/openresty/lualib/resty/template.lua:182: invalid value (userdata) at index 4 in table for 'concat'
stack traceback:
coroutine 0:
[C]: ?

So in this case, a more helpful message would be something like
"invalid value (userdata) for variable test.b".

Hopefully this is just error handling debug message so that normal good request would not be affected.

[bungle]

I just committed one patch. This patch doesn't include any debugging facilities, but template.output now treats the ngx.null the same as Lua nil (i.e. it gets converted to empty string):
5e88bf6#diff-c68d033c84d9c97f50f8e1516a097182R87

I have to think about this debugging more. I have some ideas, but nothing looks like a right solution yet. Have to think this more. If you have other examples, please let me know. At least the above example will work fine now.

[bungle]

I also changed template.output function to call tostring on non nil, ngx.null and function values:
94a87dd

Please let me know if it helps your pain. Or do you have other cases where you get cryptic error messages?

[bungle]

If you want to have an error page in production, you could do this:

if not pcall(view.render, view) then
    ngx.say("ERROR") -- or render error template with lua-resty-template
end

[bungle]

But let's keep this open still. I think that better debugging facilities are still a good thing to have. Maybe someone comes, and suggests something nice. I do not have a good solution in my mind yet.

[lordaugustus]

Thanks for implementing this so quickly. While we are discussing possible improvements, let me bring up a problem I had with my recent project.

Sometimes I have troubles managing Lua code inside template. Lets say in "user.html" we show all the messages to the present user. In the main Lua code:

local cjson = require "cjson"
local template = require "resty.template"
local user_mod = require "user_module"
local user = ......
template.render("user.html" ......)

The problem is Lua code inside the template seems to have separate scope then the main Lua code, i.e. you have to inject every Lua function that is needed to render the template explicitly like
template.getMessages = user_mod.getMessages
template.getMessageSender = user_mod.getMessageSender
...

It seems kind of redundant and sometimes It feels like injecting module inside module. I am not an expert in Lua, but I wonder would it make sense to let the template function to have the same scope as the main Lua script flow, sort of like "embedding" the template within the main Lua script.

Of course I might be doing things the wrong way here, perhaps I should structure my code differently? Please let me know what you think about this. Thanks a lot!

[bungle]

That's a nice question. Let's disquss this a little bit. I'm not sure I'm on a same page, so please correct if I have understood something wrong.

Why aren't you placing user_mod inside the template context:

local cjson = require "cjson"
local template = require "resty.template"
local user_mod = require "user_module"
template.render("user.html", user_mod)

And then in user.html you just call those functions:

{% for _, message in getMessages() do %}
<div>
  <h3>{{message.title}}</h3>
  <p>{{message.body}}</p>
  <p class="sender">Sent by {{getMessageSender(message.id).name}}</p>
</div>
{% end %}

Would that work for you? I think that it is better to be explicit here, and define your template context by yourself. Lua globals and template are there in addition to that. Think about the context as a function parameter that you are passing in. In case of template.new the selfwill be the default context. You may create a context creating helper to add all your frequently used stuff in context. Or you may add them to template.user = require "user_mod" or add user_mod to Lua global user_mod = require "user_mod".

Heck, you may even define your own view()function that returns your default view:

local function view(file)
  local view = template.new(file, "master.html")
  local user = require "user_mod" 
  view.user = user
  view.sidebar = template.render("sidebar.html", { is_admin = user.isAdmin() })
  return view
end

And then just call it everytime you need a view:

local view = view("subpage.html")
view.something = 3
view:render()

I'm not sure if this is what you are asking, but those are some options to that. I haven't tested the code, but it looks ok. Please let me know if it doesn't.

[bungle]

I was also thinking that maybe you can add current env to the context (getfenv or with Lua >= 5.2 _ENV). I haven't tested these. In general, it is not in many cases a good idea to mix too much code in templates.

[lordaugustus]

Thanks a lot for your detailed explanation. I guess I was not sure to inject the whole user_mod then because the module itself would depend on many other modules, like lua-resty-redis, mysql... But you are right that this will work properly.

And thanks for pointing out getfenv, which lead me to the lines
load_chunk = function(view)
local func = assert(loadstring(view))
setfenv(func, context)
return func
end
I am thinking maybe a really hacky way is to comment out the setfenv line. Of course this is probably not good for most use cases.

[bungle]

I added this to a roadmap, but I still need to think what is the best way to implement it.