feat: Automate replica names expansion in DependsOn

[pcastellazzi]

No description provided.

[pcastellazzi]

I have two questions about this:

• was the Copy intentional here? [https://github.com/F1bonacc1/process-compose/blob/main/src/loader/mutators.go#L134]?

• I went for a fully copy of DependsOnConfig because i am not sure if maps.Clone was enough. I think this is needed if the user makes a change to a single replica from the UI, but i am not 100% sure if that's correct.

    if proc.DependsOn != nil {
        newProc.DependsOn = make(types.DependsOnConfig)
        for k, v := range proc.DependsOn {
            newDep := v
            if v.Extensions != nil {
                newDep.Extensions = maps.Clone(v.Extensions)
            }
            newProc.DependsOn[k] = newDep
        }
    }

[F1bonacc1]

Checked out the branch — builds, ./src/loader passes under -race, and I confirmed the expansion works: depends_on: p0 on a 2-replica p0 expands to p0-0 + p0-1, with an explicit p0-1 override keeping its own condition.

Backward compatibility looks solid. Configs that already list explicit replica names (depends_on: {p0-0, p0-1}) pass through unchanged — groupReplicas is keyed by the original process name, so replica-name entries miss the lookup and fall through the else branch untouched. The override guard also handles the mixed case (bare group + explicit replica): the explicit entry wins, the bare name is dropped, no duplication.

Two things worth addressing:

1. The test doesn't actually cover the new feature. I ran it under coverage and the len(replicas) > 1 expansion loop and the override guard (mutators.go:137-140) never execute — the test passes even if that whole branch is deleted. The fixture has no process depending on a bare multi-replica group name: p2 depends on p1 (single replica) and on p0-1 (an explicit replica name), so every assertion goes through the else branch and the deep-copy. The p0-1 condition check looks like it's exercising the guard, but it's preserved via the plain else path (the guard only fires when a process depends on both p0 and p0-1).

Suggest adding a process that depends on the bare group name plus an explicit replica:

"p3": {
    Name: "p3",
    DependsOn: types.DependsOnConfig{
        "p0":   {Condition: types.ProcessConditionCompleted}, // should expand to p0-0, p0-1
        "p0-1": {Condition: types.ProcessConditionHealthy},   // explicit, should win
    },
},

and assert p3 ends up with p0-0 (Completed) + p0-1 (Healthy) and no bare p0 key. A second case asserting explicit replica names pass through unchanged would lock in backward-compat too.

2. Worth a docs note. Since depending on a replicated process used to be a load error and now works (meaning "wait for all replicas" under the given condition), a short mention in the depends_on section of www/docs/launcher.md would help.

Nice catch on the Vars fix, by the way — the old maps.Copy(newProc.Vars, proc.Vars) was a no-op (after the shallow struct copy newProc.Vars aliased proc.Vars, so it copied the map into itself), which meant all replicas shared one Vars map. maps.Clone fixes that.

[F1bonacc1]

Good questions.

was the Copy intentional here? [https://github.com/F1bonacc1/process-compose/blob/main/src/loader/mutators.go#L134]?

1. No, that maps.Copy wasn't doing anything useful - after newProc := *proc, newProc.Vars and proc.Vars are the same map, so it copied the map into itself (a no-op), and all replicas ended up sharing one Vars map. Your switch to maps.Clone is the right fix.

I went for a fully copy of DependsOnConfig because i am not sure if maps.Clone was enough. I think this is needed if the user makes a change to a single replica from the UI, but i am not 100% sure if that's correct.

2. Your instinct is right that maps.Clone isn't a full deep copy - it's shallow, so each ProcessDependency.Extensions sub-map would stay shared. Your per-entry copy makes those independent. Two caveats though: the rewrite loop rebuilds DependsOn from scratch anyway, so the copy is mostly overwritten; and the expansion step (newDependsOn[replicaName] = depConf) re-shares one Extensions map across all expanded entries of a process - so for true independence you'd clone in that loop too. As for the UI single-replica edit: I traced the runtime paths and nothing mutates DependsOn[x].Extensions in place (UpdateProcess replaces the whole config), so shared Extensions wouldn't leak across replicas today. Net: the full copy is fine and harmless, just not strictly required for current correctness.

[pcastellazzi]

I fixed the tests as you requested, my bad for not checking the coverage my self, sorry about that.
There is a commit with fixes to the clone steps, to include Extensions (ProcessDependency) too for completness.
Let me know what you think.

Regards,
Pablo C.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[F1bonacc1]

Thanks for driving this, @pcastellazzi, and for addressing all the comments!

Cheers! 😄