envd: tag-based process lookup aborts early due to inverted Range return values

Inizia in packages/envd/internal/services/process/service.go, in getProcess, e rivedi la callback del selettore dei tag rispetto alla semantica di sync.Map.Range. Controlla packages/envd/pkg/version.go per l’incremento richiesto di behavior-version. Verifica che la ricerca dei tag continui oltre i processi non corrispondenti e si fermi in corrispondenza di una corrispondenza, quindi esegui i test envd pertinenti, se disponibili.

Summary

In packages/envd/internal/services/process/service.go, getProcess looks up a process by tag by iterating the process map with Map.Range. The boolean return values in the Range callback are inverted relative to sync.Map.Range semantics (return true to continue, false to stop), so the search can terminate before it ever reaches the matching process.

Affected code

case *rpc.ProcessSelector_Tag:
    tag := selector.GetTag()

    s.processes.Range(func(_ uint32, value *handler.Handler) bool {
        if value.Tag == nil {
            return true
        }

        if *value.Tag == tag {
            proc = value

            return true   // match found, but KEEPS iterating
        }

        return false      // non-matching tagged process -> STOPS the whole scan
    })

    if proc == nil {
        return nil, connect.NewError(connect.CodeNotFound, fmt.Errorf("process with tag %s not found", tag))
    }

Map.Range is a thin wrapper around sync.Map.Range, whose contract is: the callback returns true to continue iteration and false to stop.

Root cause

The return values are reversed:

• On a match, the callback returns true, so iteration continues unnecessarily (and, if multiple processes shared a tag, proc would be overwritten by a later one).
• On a tagged but non-matching process, the callback returns false, which aborts the entire iteration.

Because sync.Map.Range visits entries in an unspecified (effectively random) order, if any non-matching tagged process is visited before the target, the scan stops early, proc stays nil, and the call wrongly returns CodeNotFound ("process with tag X not found") even though a process with that tag exists.

Impact

Tag-based process lookup (Connect / SendInput / SendSignal / Update / etc. via ProcessSelector.tag) becomes order-dependent and can intermittently fail with NotFound whenever more than one tagged process exists concurrently. With a single tagged process the bug is masked, which likely explains why it has gone unnoticed.

Proposed fix

Invert the return values so iteration stops on a match and continues otherwise:

s.processes.Range(func(_ uint32, value *handler.Handler) bool {
    if value.Tag != nil && *value.Tag == tag {
        proc = value

        return false // found it, stop iterating
    }

    return true // keep looking
})

Notes

This logic has existed since the process cgroup change (#1580) and was never modified afterward (a later lint-only PR just added a blank line). Per the envd contributing guidelines, the fix should also bump packages/envd/pkg/version.go since it changes behavior.