add worker id

[plastikfan]

Instead of worker-01, etc, lets make this more interesting by using this:

workerIDs := []string{
"baffling-aardvark",
"barking-badger",
"belching-behemoth",
"bellowing-banana",
"bickering-beetle",
"blundering-buffalo",
"booming-boomerang",
"bouncing-banana",
"bouncing-buffoon",
"braying-biscuit",
"buckling-beetle",
"bubbling-biscuit",
"burping-bungalow",
"cackling-cabbage",
"clattering-cupcake",
"clobbering-camel",
"crashing-cactus",
"crawling-caterpillar",
"croaking-crab",
"dancing-doughnut",
"dashing-dragon",
"dawdling-dolphin",
"dribbling-dragon",
"drifting-dragonfly",
"ducking-dude",
"fidgeting-ferret",
"fizzing-ferret",
"flailing-flamingo",
"flapping-flounder",
"flopping-fudge",
"fuming-funnel",
"galloping-goblin",
"gibbering-giraffe",
"giggling-goose",
"gnawing-gnome",
"grumbling-goose",
"grunting-gremlin",
"hollering-hedgehog",
"hopping-hippo",
"humming-herring",
"hustling-hedgehog",
"jiggling-jellybean",
"joking-jackrabbit",
"jostling-javelin",
"jumbling-jigsaw",
"keening-kangaroo",
"kicking-koala",
"loafing-lobster",
"lurking-llama",
"lurching-lemur",
"meandering-mongoose",
"meddling-meerkat",
"muttering-muffin",
"munching-marshmallow",
"nibbling-narwhal",
"noodling-nectarine",
"pecking-pangolin",
"pattering-pickle",
"poking-panda",
"posing-porcupine",
"prancing-quail",
"prowling-pretzel",
"puffing-quokka",
"quacking-quiche",
"quibbling-quokka",
"rattling-rat",
"roaring-rabbit",
"rumbling-raccoon",
"rummaging-raspberry",
"sauntering-salamander",
"scoffing-sasquatch",
"scurrying-spaghetti",
"shuffling-sloth",
"skittering-spaghetti",
"slurping-squirrel",
"snooping-sausage",
"snoozing-snail",
"snorting-snake",
"sparkling-spoonbill",
"squabbling-squid",
"sprawling-spider",
"sputtering-salamander",
"stomping-stoat",
"stumbling-stork",
"swaggering-walrus",
"swiveling-swan",
"teetering-turnip",
"tinkering-turkey",
"toddling-toad",
"tottering-tadpole",
"trundling-taco",
"twitching-toucan",
"waddling-watermelon",
"wheeling-wombat",
"wheezing-weasel",
"wiggling-walnut",
"wobbling-wombat",
"wobbling-wizard",
"zipping-zebra",
}

We should randomise from this list, then append a four digit zero padded number, separated with a dash, eg "swiveling-swan-0001"

[plastikfan]

In jaywalk, here is some key code that retrieves the worker id...

func (e *shellPoolExecutor) observe() {
	defer close(e.done)

	for output := range e.pool.Observe() {
		payload := output.Payload
		workerID := fmt.Sprintf("W#%d", output.WorkerID)

		e.mux.Lock()
		for marker, callback := range e.pending {
			if result, ok := parseShellResult(payload, marker, output.Error); ok {
				delete(e.pending, marker)
				e.mux.Unlock()
				callback(workerID, result.output, result.err)
				goto next
			}
		}
		e.mux.Unlock()

	next:
	}
}

The jay worker is derived from the pool worker-id (RoutineID), but I am not sure if its the correct ID.

In pants-api

	// JobOutput represents the output of Job execution
	JobOutput[O any] struct {
		ID         string
		SequenceNo int
		Payload    O
		Error      error
		WorkerID   RoutineID
	}

*coordinator (func (c Coordinator) executeActionAsync()

...
	if _, err := c.poolExec.Post(ctx, expResult.Cmd, func(workerID string, output []byte, err error) {
		if err != nil {
			event.Err = err
		}
		event.CommandOutput = c.processOutput(output, c.actionRegexes[req.ActionName])
		event.WorkerID = workerID
		event.IsLast = isLast
		req.UI.OnActionEvent(event)
	}); err != nil {
		event.Err = err
		event.IsLast = isLast
		req.UI.OnActionEvent(event)
	}
...

[plastikfan]

actually, we should leave the pants WorkerID to be numeric. The worker ID in clients can be a derivative and in jay, we'll make them string based so the worker ID can use string worker IDs mentioned previously.

[plastikfan]

Please review the worker id as used in project. It appears there is a bit of a mix up between
with what should be the worker id; the id assigned to a worker as it is created and a job ID
that is assigned to each job. Please perform an analysis and tell me your findings. I suspect
that the job id is being mistaken for the worker id and there is no worker id being made available
to client users of pants. The end goal, is for there to be both worker IDs and job IDs.

Here are my findings:

Analysis: Worker ID vs Job ID in pants

Both IDs exist and are correctly assigned, but the naming is confusing in one internal area:

Worker ID (RoutineID, type int32)

• Assigned at worker creation via pool.allocID() — an atomic int32 increment (pool.go:296, pool-func.go:298)
• Stamped into the envelope when a worker picks up work (worker.go:91-99, worker-func.go:112-119)
• Exposed to clients via JobOutput.WorkerID and input.WorkerID() inside pool functions
• No confusion here — it's properly propagated.

Job ID (type string)

• Assigned at job submission via o.Generator.Generate() in Post() (worker-pool-func-manifold.go:62)
• Default generator is Sequential with format "ID:%08d"
• Exposed to clients via Job.ID and JobOutput.ID
• Also no confusion here — it's a separate field.

The actual confusion (internal only)
The internal Envelope struct (ants.go:124-128) has a field called ID of type RoutineID, but it stores the worker's ID, not a job ID:

type Envelope struct {
    ID    RoutineID  // This is the WORKER ID, despite the field name
    Input any
    state any
}

This is somewhat misleading — the field name ID is generic, though it's accessed via the WorkerID() method which clarifies intent.

Conclusion

Your suspicion is not quite correct — the job ID is not being mistaken for the worker ID. Both IDs are already flowing correctly through the system. However, the field naming in Envelope.ID and TaskEnvelope.ID is ambiguous (they store RoutineID — the worker ID — but are just called ID). The IDGenerator documentation comment mentioning "worker ID or job ID" is also misleading since it only generates job ID strings, not the int32 worker IDs.

Both IDs are already available to client users — WorkerID as RoutineID on JobOutput, and Job.ID as string. No gap exists, just a naming clarity issue in internal types.

---

Left as-is (context is clear):

• Job.ID — clearly the job ID (type string)
• JobOutput.ID — clearly the job ID (type string)
• goWorker.id — clearly the worker's ID (private field on a goWorker type)
• goWorkerWithFunc.id — same reasoning
• JobOutput.WorkerID — already explicitly named WorkerID

The field was made unexported (id) to avoid a Go compile error (field and method can't share the name WorkerID). All access goes through the WorkerID() method anyway, which is the interface contract.