Azure / Azure/eno

Return custom input binding errors through KRM results instead of panicking

Open
#642 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
28
Forks
31
Avg merge
2d 13h
Merged PRs (30d)
6

Description

## Problem

In `pkg/function` v0.2.2, errors returned while finalizing a custom input binding are propagated out of the internal `main` function and then converted to a panic by the public `function.Main` entrypoint.

The relevant flow is:

1. `readInputStruct` calls `input.Finalize()`.
2. If `Finalize()` returns an error, `readInputStruct` returns that error directly.
3. The internal `main` only serializes `ErrInputReadingFailed`; other input errors are returned.
4. Public `Main` panics with `error while calling synthesizer function: ...`.

This differs from errors returned by the synthesizer function itself, which are added to the KRM `ResourceList.results` with error severity and written to stdout.

For custom input bindings, validation and parsing errors are expected runtime input failures. Turning them into process panics makes the synthesis look like an unexpected crash, bypasses the normal KRM error result contract, and makes structured error reporting harder for callers.

## Expected behavior

Errors from custom input binding/finalization should be serialized as error-severity KRM results and written through the `OutputWriter`, consistent with synthesizer-function errors. `function.Main` should reserve panics for framework initialization failures or genuinely unexpected conditions.

## Reproduction

Register a custom input type whose binding function returns an error:

```go
function.AddCustomInputType(func(secret *corev1.Secret) (*Config, error) {
return nil, errors.New("invalid config")
})
```

When that input is finalized, the process panics with:

```text
panic: error while calling synthesizer function: invalid config
```

Expected output is a KRM result equivalent to:

```yaml
results:
- severity: error
message: invalid config
```

Malformed or invalid custom-input data should therefore be observable as an ordinary synthesis failure rather than a synthesizer crash.

Contributor guide

Open the contributing guide

Research direction

Start by tracing readInputStruct through the internal main and public function.Main entrypoints, then inspect the OutputWriter handling used for synthesizer-function errors. Reproduce the custom input binding failure and add coverage for the expected error-severity KRM result, confirming that invalid finalization data is written to stdout without a panic.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes
Domain
api, backend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.