Repository navigation
Add labels or an owner field to Tasks, with label filtering on ListTasks #488
Description
Problem
ObjectMeta holds only a name, an atespace and a creation time. A platform that runs Tasks for many users has no way to record who a Task belongs to, so it can't find a user's Tasks after a restart, cap Tasks per user, or split cost per user, without encoding ownership in env values or names.
Env values are a poor place for it: they end up in the ActorTemplate and in the runner's metadata, so anything sensitive put there leaks.
Ask
Labels on ObjectMeta (or an owner field), stored by ax-server and not passed into the sandbox, and a label selector on ListTasks.
This touches the v1alpha1 API, so it should line up with the field cleanup in #485.
Activity
Bortlesboat commentedon Oct 17, 2026
I'd like to pick this up. Rough plan, happy to adjust:
map<string, string> labelsonObjectMeta, validated like k8s labels (key/value length + charset)label_selectoronListTasksRequest, equality only for now (team=foo,user=bar),ax get tasks -l ...in the CLImetadata.labelsfromlaunchTaskbefore it's marshaled intoAX_TASK_YAML. Right now the whole task minus status goes into the template env, so without this labels would land in the sandbox and also change the template name hashThe part I'm least sure about is the Redis store. ListTasks pages with ZREVRANGE on the atespace index, so filtering after the fetch would give short or empty pages. I was going to add a per-label index zset (
tasks:<atespace>:label:<k>=<v>) written/removed in the same pipeline as the existing indexes, and intersect them for multi-label selectors. Does that seem reasonable, or would you rather keep it simpler for now (single-label selector, or filter-after-fetch and accept uneven pages)?Owner field I'd leave out unless you want it separately, since an
ownerlabel covers the use case in the issue.