Discarded `fmt.Errorf` return value in `TriggerImport` silently swallows config-load failures

[abhaygoudannavar]

Describe the bug

In pkg/watcher/executor.go at line 15, the error returned by config.DefaultLocalConfigPath() is "handled" with:

fmt.Errorf("Error while loading config: %s", err.Error())

fmt.Errorf returns an error value — it does not print anything to the console. Because the return value is never assigned or checked, the error is silently discarded. The function then continues execution with a zero-value cfgPath (empty string ""), which is passed to os.Stat(""). This always fails, causing the code to silently fall through to the else branch, where it incorrectly uses raw context strings as server URLs instead of reading them from the local config file.

Expected behavior

If the local config path cannot be resolved, TriggerImport should log a clear, visible warning (e.g., via log.Printf) and return early, so the developer can see exactly why re-imports are failing.

Actual behavior

The error is completely swallowed with no output. The watcher continues with cfgPath = "", falls through to the fallback branch, and attempts connections to incorrect URLs. The developer sees only a cryptic downstream connection error with no indication that the root cause is a config-path resolution failure.

How to Reproduce?

Reproducer:
Resources to reproduce the behavior:

1. Start the file watcher via microcks import --watch.
2. While the watcher is running, corrupt or remove ~/.microcks/config (or set $HOME to a non-existent path).
3. Modify a watched API specification file to trigger a re-import.
4. Observe: no error message is printed about the config failure, but the import fails with a connection error to an incorrect URL.

Microcks version or git rev

master (commit cfe2267)

Install method (docker-compose, helm chart, operator, docker-desktop extension,...)

(docker-compose, helm chart, operator, docker-desktop extension,...) CLI Binary (built from source via make build-local)

Additional information

The fix is a 3-line change: replace fmt.Errorf(...) with log.Printf("[ERROR] ...") and add a return statement to abort the function early when the config path cannot be resolved. I would like to work on this fix if the maintainers agree with the approach.

[abhaygoudannavar]

Hi @lbroudoux @Harsh4902,

I came across this while auditing the watcher subsystem in pkg/watcher/executor.go. The fmt.Errorf on line 15 is a classic Go gotcha it formats an error string but doesn't print it, so the return value just gets thrown away. This means if the config path fails to resolve, the watcher silently falls through to incorrect behavior with no diagnostic output.

Happy to submit a PR if you're aligned with this approach. Would you also prefer I add a unit test for the TriggerImport error path, or keep the PR scoped to just the bug fix?