Prompt
Adopt consistent logging practices:
- Never allow correctness-affecting failures to be silent, especially inside OpenResty async callbacks (e.g.,
ngx.timer.at, log phase). Log each error path inside the callback. - Avoid noisy logs for expected/controlled conditions (e.g., rate/connection limits being reached as part of normal operation). If it will spam, downgrade/remove it.
- Use the correct log level: errors for unexpected failures; warn for expected degradation or shutdown paths where tests/operators shouldn’t treat it as an error.
- Include actionable context in every message (limits/thresholds, computed values, relevant identifiers like
service_name), and don’t log “mystery failures.” - Prevent duplicate logging: if a helper already logs, don’t log again at the caller.
Example pattern (async callback):
local function log_phase_work()
local red, err = redis.new(conf)
if not red then
core.log.error("failed to create redis in log phase: ", err)
return
end
local ok, incoming_err = red:do_incoming(...)
if not ok or incoming_err then
core.log.error("failed to deduct tokens in log phase: ", incoming_err)
return
end
-- release connection etc.
end
-- If you create a timer, still log inside the callback:
ngx.timer.at(0, log_phase_work)
Checklist for any new log line: 1) Will it help someone detect/triage a problem? 2) Could it otherwise be silently swallowed (async)? 3) Is it expected (don’t spam WARN/ERROR)? 4) Is the level appropriate (WARN vs ERROR)? 5) Does it include the key context needed to debug (ids/values)? 6) Does another function already log the same failure?