Date format doesn't exist, don't crash

[BNolet]

Is your feature request related to a problem? Please describe. When you use a percent encoding format that doesn't exist within the date command, it causes espanso to crash with an unhelpful error in the log like so:

18:51:08 [ERROR] thread 'daemon_background' panicked at 'a Display implementation returned an error unexpectedly: Error': /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/alloc/src/string.rs:2202
stack backtrace:
   0: backtrace::backtrace::trace
   1: backtrace::capture::Backtrace::new
   2: log_panics::init::{{closure}}
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic_handler::{{closure}}
   5: std::sys_common::backtrace::__rust_end_short_backtrace
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::option::expect_none_failed
   9: <espanso::extension::date::DateExtension as espanso::extension::Extension>::calculate
  10: <espanso::render::default::DefaultRenderer as espanso::render::Renderer>::render_match
  11: espanso::engine::Engine<S,C,M,U,R>::inject_match
  12: espanso::matcher::<impl espanso::event::KeyEventReceiver for M>::on_key_event
  13: <espanso::event::manager::DefaultEventManager as espanso::event::manager::EventManager>::eventloop
  14: espanso::worker_background
  15: std::sys_common::backtrace::__rust_begin_short_backtrace
  16: core::ops::function::FnOnce::call_once{{vtable.shim}}
  17: std::sys::unix::thread::Thread::new::thread_start
  18: _pthread_start

Describe the solution you'd like In this case, it would be useful to try and parse whether the format is correct and if not, throw that into the log. Without crashing of course :P

Describe alternatives you've considered Looking up the formatting options that exist and using them properly.

[federico-terzi]

Hey @BNolet,

Thanks for reporting this issue! This definitely looks like a bug we should solve :) Do you have an example of format date that caused the crash?

Cheers :)

[BNolet]

Sure, no problem!

I had found this formatting here, which upon second look, seems to be something specific to the ExpressionEngine program this doc is intended to be used with.

Here was the formatting that crashed espanso: %Y-%m-%dT%H:%i:%s%Q

[federico-terzi]

@BNolet Thanks! I'll investigate :)

[smeech]

The error in espanso log for the current release, here is:

17:27:51 [worker(694246)] [ERROR] thread 'engine thread' panicked at 'a Display implementation returned an error unexpectedly: Error': /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/alloc/src/string.rs:2525
17:27:51 [worker(694246)] [ERROR] thread 'detect thread' panicked at 'unable to send to the source channel: "SendError(..)"': espanso/src/cli/worker/engine/funnel/mod.rs:104
17:27:51 [worker(694246)] [ERROR] X11Source destruction returned non-zero code
17:27:51 [worker(694246)] [ERROR] Unable to block the LinuxEventLoop: receiving on an empty and disconnected channel
17:27:51 [worker(694246)] [ERROR] thread 'main' panicked at 'unable to run main eventloop: receiving on an empty and disconnected channel': espanso/src/cli/worker/mod.rs:160
17:27:51 [daemon(694238)] [ERROR] received unexpected exit code from worker 101, exiting

and Espanso restarts. Is that any better?

I can leave this up, but I don't think it'll be a priority, I'm afraid.

[BNolet]

That is certainly better. I am on macOS, would the behaviour potentially change based on platform?

[smeech]

Potentially, I guess, and I wouldn't be surprised if the log format is different. Is the behaviour any better on macOS with the current release?

[BNolet]

Doesn't look like it if I put an invalid date format. Espanso crashes and never restarts on macOS 14.3.1

[smeech]

That's more painful! We'll keep this open, then.