Flag to exit immediately on cache misses

[maxim-uvarov]

Please, consider adding a flag to return null when there is no caching results, but to request execution of the command in background.

I'm trying to implement a nushell cli wrapper, that would ask for results of cli execution asynchroniously.

I have a list of parameters, that I want to request information about in parallel threads from the app that retrieves such information from some server in the internet. BKT would be helpful here, if it just returned null instantaneously, and in background asked for information from cli. And, on the next call it would return the requested information.

[dimo414]

Thanks for the feature request. Can you elaborate on how you'd use the "null" signal, would you be handle it in some way, or just pass it off to the caller to deal with?

How would you feel about a --cached-only flag that outputs cached data if any exists and returns without executing anything (perhaps with a 126 exit code if there's a cache miss). The caller would then use --warm to trigger an async refresh as they see fit.

[maxim-uvarov]

Thanks for the feature request.

Thanks for the app and for your question. It helped me to clarify what I really need.

Can you elaborate on how you'd use the "null" signal, would you be handle it in some way, or just pass it off to the caller to deal with?

So I use nushell. I have a table with column of addresses. On each address I need to make a call to some cli, to get data from to fill a new column accordingly. The response of this cli execution takes about 2-10 seconds. As soon as nushell get a response from cli with null and some exit code, it can continue making another call of cli for the next address. I imagined, that after some time I just can repeat my requests on the list of addresses, and fastly fill the column with the values, that were executed already.

How would you feel about a --cached-only flag that outputs cached data if any exists and returns without executing anything (perhaps with a 126 exit code if there's a cache miss). The caller would then use --warm to trigger an async refresh as they see fit.

Ideally, I would avoid using the second call with --warm flag. But this way bkt must know about already running tasks, to avoid duplicating them. I'm not sure if it is feasible by the current design.

Anyway, thanks for your question. Now I see that some queue management tool is absolutely necessary in my case to limit the number of simultaneosly running jobs.

[dimo414]

What I've done in cases like this (such as when using bkt with fzf --preview) is kick off --warm invocations when the application starts, then invoke the same command without --warm when needed by the application. This is obviously racy, but IME helps a lot with these sort of startup delays.

Another approach you could consider, depending on your application's design (I've not used nushell), would be to call out to bkt in separate threads and only update the UI when the background thread(s) complete. That way your UI is still responsive even while the subprocess is running. This would be similar to how fzf --preview is implemented.

I am thinking about adding locking of some sort (see #11) but it would still block waiting for results without a feature like --cached-only.