Pass more info on job to callback fn

[Gautham]

Problem Statement

Currently, the callback fn is only passed the name of the executable/fn in the job. If I'm dealing with multiple jobs using the same executable that differ only in args, then the callback fn can't help me disambiguate which job ran.

Sample Usecase:

async_job my_env_worker "startEnv EnvA";
async_job my_env_worker "startEnv EnvB";

I'd like to have my callbackFn to provide some info on the env (envA vs envB) as well. However, $1 in callbackFn is just startEnv today. Is this possible today?

Alternatives

• ⚠️ I could have a separate worker per job args which is probably not how the library was meant to be used.
• 🚫 Processing individual jobs or attaching callbacks per request can result in race-conditions etc.

[mafredri]

Hey, this does indeed seem like a valid use-case. But for now there are a few ways you can work-around this limitation. For instance:

1. Create differently named wrapping functions or alises
2. Print something at the beginning of the job on the stdout (or stderr to separate) to identify and then check via if [[ $3 = my_idA* ]]; then ...

Example 1:

startEnvA() {
    exec startEnv "$@"
}
startEnvB() {
    exec startEnv "$@"
}
async_start_worker my_env_worker

async_job my_env_worker startEnvA EnvA
async_job my_env_worker startEnvB EnvB

Example 2:

async_job my_env_worker "print my_idA; startEnv EnvA";
async_job my_env_worker "print my_idB; startEnv EnvB";

Possible (future) solutions:

• Add a new callback argument that includes the entire cmdline
• Allow passing a unique ID to async_job, e.g. async_job --id envA ...
  • In this case we could use id for uniqueness check as well (when it is used)