fix(http): handle os.Getwd() error in AddStaticFiles

[NitinKumar004]

Description

AddStaticFiles in pkg/gofr/gofr.go discarded the error returned by os.Getwd():

currentWorkingDir, _ := os.Getwd()
filePath = filepath.Join(currentWorkingDir, filePath)

If os.Getwd() fails, currentWorkingDir becomes empty and the static file path is
silently resolved against the filesystem root, with no log to help the developer diagnose
why the endpoint didn't register correctly.

Change

Capture the error, log it via the container logger, and return early — mirroring the
existing error handling for the os.Stat failure path a few lines below in the same
function.

Testing

• go build ./pkg/gofr/
• go vet ./pkg/gofr/
• go test ./pkg/gofr/ -run 'TestStaticHandler|TestStaticHandlerInvalidFilePath|TestNewSetsHTTPRegisteredWhenStaticDirExists' — all pass
• golangci-lint run ./pkg/gofr/ — no new findings in the changed region

Fixes #3322

[aryanmehrotra]

Production code is correct — Errorf + return is the right pattern, consistent with the rest of AddStaticFiles. One bug in the test before this can merge.

[aryanmehrotra]

Wrong output stream — GoFr's logger writes to stdout, not stderr. With StderrOutputForFunc the captured string is always empty, so on Linux (where os.Getwd() does fail after os.Remove) both assertions run against "" and the test fails. On macOS the test skips, hiding the bug.

The existing test immediately above this one (TestStaticHandlerInvalidFilePath) exercises the same Errorf call and uses StdoutOutputForFunc — follow that pattern:

logs := testutil.StdoutOutputForFunc(func() {
    app := New()
    app.AddStaticFiles("gofrTest", "./somedir")
})

[NitinKumar004]

Thanks for the review! I double-checked this against the logger implementation, and I think the stream is actually reversed here.

GoFr's logger routes ERROR-level logs to errorOut, which is os.Stderr — not stdout. See pkg/gofr/logging/logger.go:

out := l.normalOut        // normalOut = os.Stdout
if level >= ERROR {
    out = l.errorOut      // errorOut  = os.Stderr
}

AddStaticFiles logs the failure via Errorf (ERROR level), so it goes to stderr. The existing TestStaticHandlerInvalidFilePath just above also captures the same Errorf output via StderrOutputForFunc, so this test follows that pattern.

I also verified empirically on Linux (where os.Getwd() does fail after the cwd is removed):

• with StderrOutputForFunc → test passes, the ERROR line is captured.
• with StdoutOutputForFunc → test fails: the captured string contains only the WARN config lines, and both assertions fail on the missing error message.

So StderrOutputForFunc is the correct choice here. Happy to adjust if I'm missing something!

My mistake — you're correct. ERROR-level logs go to errorOut = os.Stderr, and TestStaticHandlerInvalidFilePath immediately above already uses StderrOutputForFunc for the same reason. The test is right.

[aryanmehrotra]

You're right, my mistake. ERROR-level logs route to errorOut = os.Stderr in the logger, so StderrOutputForFunc is correct — and TestStaticHandlerInvalidFilePath right above follows the same pattern. Production code is clean. LGTM.