fix(prompt): return errors from functions that silently ignore API failures

[AdeshDeshmukh]

Description

Fixes 8 functions in pkg/prompt/prompt.go that silently discarded Harbor API errors using the blank identifier (_), causing nil pointer panics when API calls fail. Also fixes GetQuotaIDFromUser which logged the error but still dereferenced a nil payload.

Closes #684.

Before

func GetRegistryNameFromUser() int64 {
    go func() {
        response, _ := api.ListRegistries()  // error discarded
        rview.RegistryList(response.Payload, ...)  // PANIC if response is nil
    }()
}

After

func GetRegistryNameFromUser() (int64, error) {
    type result struct { id int64; err error }
    resultChan := make(chan result)
    go func() {
        response, err := listRegistriesFunc()
        if err != nil {
            resultChan <- result{0, err}
            return
        }
        // ...
    }()
    res := <-resultChan
    return res.id, res.err
}

Fixed Functions

Function	Before	After
GetRegistryNameFromUser	int64	(int64, error)
GetReferenceFromUser	string	(string, error)
GetImmutableTagRule	int64	(int64, error)
GetTagFromUser	string	(string, error)
GetScannerIdFromUser	string	(string, error)
GetInstanceFromUser	string	(string, error)
GetMemberIDFromUser	int64	(int64, error)
GetQuotaIDFromUser	int64	(int64, error)

Changes

• pkg/prompt/prompt.go — 8 functions refactored to use result{value, error} channel pattern (same as existing GetProjectNameFromUser / GetWebhookFromUser). Function variables added for testability.

• pkg/prompt/prompt_test.go — 9 new tests covering API failure and empty-list edge cases for all 8 functions.

• 25 caller sites across 20 files — each now checks the returned error with a clear message (e.g., "failed to list scanners").

Design Decisions

• Channel-based error propagation — goroutines in interactive TUI functions cannot use standard return. Using a result struct through a buffered channel is the established pattern in this file.
• Function variables for mocking — same approach as pkg/api/member_handler_test.go. Enables testing error paths without a running Harbor instance.
• All callers updated — changing function signatures is a breaking change. Every caller is updated in this PR to ensure consistency.

Type of Change

• Bug fix

Testing

• 9 new unit tests covering all 8 functions (error paths + empty-list edge case)
• Full test suite: 192 tests passing (no regressions)
• go vet clean
• gofmt clean
• Build succeeds

Signed-off-by: AdeshDeshmukh adeshkd123@gmail.com

[vg006]

@AdeshDeshmukh First of all, Thank you for showing interest in addressing the issue regarding the error handling.

For you notice, I have been into it for a long time and there has been some discussion with the community regarding addition of errors package (here #636) and improving the error handling across the project with proper logging in #635.

Since I have been working related to it and the PR contains major changes in the function signatures and logic across the project, It will be conflicting with my work and would be hard for me to manage.

So I would like to pursue it, hope you understand. Thank you.

[AdeshDeshmukh]

Thanks for the heads up, and apologies for any overlap — I should have checked #635/#636 more carefully before starting.

That said, this is a focused bug fix (nil panics from _-discarded errors), not an architectural refactor. It follows the exact GetProjectNameFromUser pattern already in the file, so it should be compatible with whatever errors package lands later.

I'm happy to:

1. Help rebase this once Proposal: Fix improper logging and error handling #635 lands
2. Adapt the approach however you or the maintainers prefer

No attachment to the PR — just wanted the panics fixed. I'll leave it to maintainers to decide how to proceed.

[vg006]

Yeah, I can understand. The changes need to studied and let us leave it to the maintainers, but I have few reviews.

[vg006]

I don't find any valid reason to declare aliases for the functions of the api package. They can be directly used.

[bupd]

closing this Since this overlaps with the ongoing work on #636

Thanks for the contribution though.