Watcher File Change Events Trigger Unbounded Concurrent Reimports, without any Debounce or Limit #297

Describe the bug

Every Write event spawns a new goroutine with no debounce, no concurrency limit, no deduplication. When a file is saved in an IDE, it typically generates 2-5 write events in rapid succession
(write temp file, rename, metadata update). A cp or sed -i generates similar bursts. Each event spawns a separate HTTP upload to Microcks.

Why Critical:

1. Thundering herd: 10 files changed simultaneously leads to 10+ goroutines, 10+ concurrent uploads, potentially overwhelming the Microcks server.
2. Race condition on the server: Two concurrent uploads of the same artifact can create conflicting service definitions, especially for large specs that take seconds to process.
3. No error aggregation: Each goroutine logs errors independently to stdout with no structured tracking.
4. No backpressure: If the server is slow, goroutines accumulate indefinitely, this is a goroutine leak.
5. fsnotify on directories: Some editors replace files rather than modifying in-place, which can cause the watcher to lose track of the file entirely (the inode changes).

Expected behavior

When watching files for changes, the CLI should debounce file system events (e.g., waiting ~200-500ms after the last edit before triggering an import) to ensure only a single logical save triggers one import. It should also limit concurrency or sequence the TriggerImport calls to avoid overwhelming the Microcks server. Furthermore, the watcher should correctly handle atomic file saves (which often trigger fsnotify.Rename or fsnotify.Create events) so it doesn't lose track of files when they are overwritten.

Actual behavior

Currently in pkg/watcher/watchManager.go, the Run() loop listens specifically for fsnotify.Write and immediately spawns a new, unbounded goroutine (go TriggerImport(entry)) for every single event.
Modern IDEs and tools (like sed -i or VS Code) trigger multiple rapid file system events when a file is saved (temp file write, rename, metadata update). This results in a "thundering herd" where multiple concurrent HTTP requests to upload the exact same artifact are fired at the Microcks server within milliseconds. This causes:

• Race conditions on the Microcks server resulting in potential database issues or duplicated logic.
• Goroutine leaks / absence of backpressure if the server is slow to respond.
• Loss of file tracking if the IDE performs an atomic save (replacing the file and changing its inode), because the CLI ignores non-Write operations.

How to Reproduce?

Steps to reproduce the issue:

1. Start the microcks-cli watcher on a configuration tracking an API specification (e.g., using microcks-cli test ... or your dedicated watch command).
2. Open the tracked API specification file in an editor like VS Code and hit Save, or simulate rapid disk writes via terminal: for i in {1..5}; do touch my-api-spec.yaml; done
3. Inspect the microcks-cli console output. You will see multiple [INFO] Re-importing changed file: logs simultaneously, meaning multiple concurrent HTTP uploads for the same file are executed.

2026/05/05 23:29:07 [INFO] Watcher added on /root/cncf/microcks-cli/test-spec.yaml
[INFO] microcks-watcher started...
[INFO] Re-importing changed file: /root/cncf/microcks-cli/test-spec.yaml
[WARN] Error re-importing /root/cncf/microcks-cli/test-spec.yaml: Post "/test-context/api/artifact/upload": unsupported protocol scheme ""                      
[INFO] Re-importing changed file: /root/cncf/microcks-cli/test-spec.yaml
[WARN] Error re-importing /root/cncf/microcks-cli/test-spec.yaml: Post "/test-context/api/artifact/upload": unsupported protocol scheme ""                      
[INFO] Re-importing changed file: /root/cncf/microcks-cli/test-spec.yaml
[WARN] Error re-importing /root/cncf/microcks-cli/test-spec.yaml: Post "/test-context/api/artifact/upload": unsupported protocol scheme ""                      
...

Microcks version or git rev

• Microcks CLI version or git rev: master branch - Install method: Local build from source

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

No response

Additional information

The root cause is in pkg/watcher/watchManager.go:

case event := <-wm.fileWatcher.Events:
    if event.Op&fsnotify.Write == fsnotify.Write {
        // ...
        } else {
            wm.lock.Lock()
            entry, exists := wm.watchEntries[event.Name]
            wm.lock.Unlock()
            if exists {
                go TriggerImport(entry) // Spawned instantly per event
            }
        }