[bug] Infinite recursion in Provisioner.Class(), Type(), and Description() methods

[Abhishek9639]

Describe the bug
The Provisioner struct in the environment provisioner package has three methods Class(), Type(), and Description() that call themselves unconditionally, causing infinite recursion and a stack overflow crash whenever they're invoked.

To Reproduce

1. Go to internal/provisioners/envprov/envprov.go
2. Look at the Provisioner receiver methods around lines 147–162
3. Call any of Class(), Type(), or Description() on a *Provisioner value
4. The program crashes with a stack overflow

Expected behavior
These methods should return a meaningful string value (or an empty string), not recurse into themselves. The sibling type envVarResourceTracker implements them correctly by returning stored fields like e.resClass.

Screenshots

func (p *Provisioner) Class() string {
	return p.Class() // calls itself infinitely
}
func (p *Provisioner) Type() string {
	return p.Type() // calls itself infinitely
}
func (p *Provisioner) Description() string {
	return p.Description() // calls itself infinitely
}

Desktop (please complete the following information):

• OS: All platforms
• Version: latest main branch

Additional context
These methods are currently not hit in normal CLI flows, which is why the bug has survived undetected. However, any future code that logs, debugs, or inspects a Provisioner value by calling these methods will immediately crash the binary. A simple fix would be to return a static string like "" or "*" from each method.

[Siddhartha-singh01]

Hi @Abhishek9639 I’d like to take this up. The issue seems to stem from self-referential calls in Class(), Type(), and Description() causing infinite recursion. I plan to update these methods to return the correct underlying fields instead.

Please assign this issue to me. I’ll submit a PR soon.

[Abhishek9639]

@mathieu-benoit, if this bug seems valid to you, please assign this issue to @Siddhartha-singh01.
Thanks

[mathieu-benoit]

Thanks guys! Before doing anything here, I think we should make sure there is an actual path to illustrate the issue. envprov is a very special (i.e. hard coded provisioner) and so very limited. If there is an end-user use case landing to the issue or if there is a unit test that can illustrate this, sure, let's fix this. Otherwise, I'm a bit hesitant to move forward here.

[Siddhartha-singh01]

@mathieu-benoit Thanks for reviewing .

You're right that this isn't currently hit in the main CLI execution flow.

However, it acts as a hidden landmine for developers. If anyone ever attempts to log, debug, or write tests inspecting the base Provisioner, the binary will instantly crash with a stack overflow due to the infinite recursion.

To illustrate this, I've written a unit test in envprov_test.go that directly invokes Class(), Type(), and Description(). Without a fix, these tests fatally crash the test runner.

I have a minimal, non-disruptive fix ready (returning static strings like default and environment, mirroring the sibling envVarResourceTracker implementation), alongside the unit tests to prevent future regressions.

I'll go ahead and raise the PR for your review

[Abhishek9639]

Hey @mathieu-benoit,
Thanks for the feedback. There is actually a real code path that hits this.

The score-compose provisioners command (in internal/command/provisioners.go, lines 88–102) iterates over all registered provisioners and calls .Type(), .Class(), and .Description() on each one including the envprov.Provisioner.
Both the JSON and table output paths trigger this.

So running score-compose provisioners should crash with a stack overflow if the env provisioner is in the list.

Here's a minimal test that demonstrates the crash:

func TestProvisionerClassDoesNotRecurse(t *testing.T) {
    p := new(envprov.Provisioner)
    // These will stack overflow due to infinite recursion
    assert.NotPanics(t, func() { p.Class() })
    assert.NotPanics(t, func() { p.Type() })
    assert.NotPanics(t, func() { p.Description() })
}

[Siddhartha-singh01]

Thanks @Abhishek9639 for confirming the real execution path that's a clear reproduction case.

Since score-compose provisioners iterates over all provisioners and calls .Type(), .Class(), and .Description() on each one, this will crash reliably in normal CLI usage whenever envprov.Provisioner is in the list. This is no longer a theoretical concern.

The fix in PR #483 looks straightforward and non-disruptive.

The unit tests added in envprov_test.go directly cover the crash scenario, which also prevents future regressions. I think this is ready to review .

[Abhishek9639]

hey @mathieu-benoit, what do you think about this issue?