[Request] Filter by TaskResult

[tekumara]

Describe the bug

❯ pueue status status=killed
Error: 
   0: Failed to parse query
   1:  --> 1:8
        |
      1 | status=killed
        |        ^---
        |
        = expected status_queued, status_stashed, status_paused, status_running, status_success, or status_failed

Location:
   pueue/src/client/commands/state/query/mod.rs:163

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

Steps to reproduce

1. add a task
2. kill it
3. run pueue status status=killed

Debug logs (if relevant)

No response

Operating system

macos

Pueue version

4.0.1

Additional context

No response

[Nukesor]

To fill that request fully, we would have to a new filter keyword result:
This would then reflect the TaskResult enum:

/// This enum represents the exit status of an actually spawned program.
/// It's only used, once a task finished or failed in some kind of way.
#[derive(PartialEq, Eq, Clone, Debug, Display, Serialize, Deserialize)]
pub enum TaskResult {
    /// Task exited with 0
    Success,
    /// The task failed in some other kind of way (error code != 0)
    Failed(i32),
    /// The task couldn't be spawned. Probably a typo in the command
    FailedToSpawn(String),
    /// Task has been actively killed by either the user or the daemon on shutdown
    Killed,
    /// Some kind of IO error. This should barely ever happen. Please check the daemon logs.
    Errored,
    /// A dependency of the task failed.
    DependencyFailed,
}

status=success and status=failed would need to be removed and replaced with the result keyword and status=done.

[Nukesor]

The query API is also still somewhat experimental. There're no stability guarantees on it yet (as it's also very sparsely documented) so we don't have uphold any backwards compatibility guarantees.

[tekumara]

Thank you for considering this! Could it all be in a single field to simplify the UX, rather than split across two fields?

[Nukesor]

Sorry for the long wait.

I guess that would make somewhat sense? Any type of result implies that it's done anyway.

I'm wondering how we should handle failed and FailedToSpawn though. Or whether we should handle those at all.
To make those two fully queryable, we would need to specify the exit code/string.
Maybe we just skip them for now...

Anyway, feel free to create a MR for this one :)