Context

A handler's first argument is always its deserialized payload — a lambda handler takes nothing else, while a @TaskHandler method may declare further @Resource(...) parameters that the generated companion injects. The execution context around it is reached two ways: resource resolution inside the handler, and the TaskContext handed to middleware.

Resources.use

import org.byteveda.flexiq.resources.Resources;

flexiq.worker().handle(sendEmail, payload -> {
    SmtpClient smtp = Resources.use("smtp");
    return smtp.deliver(payload);
});

Resolves a registered resource by name against the current task's scope. Valid only while a task runs on this worker — the worker binds the scope around the handler call; outside one it throws a ResourceException. Prefer the declarative @Resource("smtp") parameter on a @TaskHandler method, which the generated companion resolves the same way.

TaskContext (middleware)

The job's identity travels through middleware hooks rather than the handler signature:

flexiq.use(new Middleware() {
    @Override
    public void before(TaskContext context) {
        MDC.put("jobId", context.jobId);
    }

    @Override
    public void onError(TaskContext context, Throwable error) {
        log.warn("{} {} failed", context.taskName, context.jobId, error);
    }
});

Progress & cancellation

Progress and cooperative cancellation go through the client by job id: flexiq.setProgress(jobId, percent) records 0–100 for inspection and the dashboard, and flexiq.isCancelRequested(jobId) lets a long-running handler poll for a requestCancel from another process. Thread the job id into the payload (or capture it in middleware attributes()) when a handler needs either.