Infos:
- Used Zammad version: 3.3.x
- Used Zammad installation source: package
- Operating system: Debian 4.9.189-3+deb9u2 (2019-11-11) x86_64 GNU/Linux
- Browser + version: any
Some background:
Yesterday I fiddled around with methods that work within rails console and tried them as variables within a scheduler’s e-mail notifications, e.g.
#{article.first / no such method}
#{article.last_customer_agent_article / no such method}
Later, I also tried something more complex—I can’t remember the exact variable, but I think it was something containing parentheses and apostrophes, like:
#{Ticket.find_by(number:'101234').articles.first
—which seems to have broken that particular scheduler job completely. A second scheduler job (clone from the first one without the bad syntax does indeed run:
Also, after editing the older job, the ‘planned for’ time will change in the UI—but it won’t execute and it will stay at that exact timestamp.
@MrGeneration Could you maybe explain how Scheduler works technically, and why it didn’t try to run again later? I’d love to understand it and contribute something to the documentation!
Expected behavior:
- Scheduler job should be run again after removing not working variables
- Ideally Zammad would do better error handling before running the job, i.e. maybe ignore the syntax errors and just throw an error in
production.log
Actual behavior:
E, [2020-03-04T19:12:06.670017 #27160-69883551029620] ERROR -- : execute Job.run (try_count 0) exited with a non standard-error #<SyntaxError: (erb):1: syntax error, unexpected tIDENTIFIER, expecting tSTRING_DEND
I, [2020-03-04T19:12:06.671689 #27160-46960850806260] INFO -- : Scheduler stopped.
- Scheduler stopped
- That particular job wouldn’t execute again (even though I removed the variable completely)
(Also, I’d love to understand the log file better—what exactly does #27160 refer to? PID?)
Thanks,
Ben