enable direct error handling for bundle plugin trigger method #7143

torwunder · 2024-10-30T15:08:05Z

Why the changes in this PR are needed?

When using opa as a library you may want to directly control when and how opa interacts with the bundle registry.
When switching to manual trigger mode and triggering the the bundle plugin directly you may want to react to errors that occurred when downloading the bundles.
The current capability of using the bundle status requires configuring a listener and wait for it to be triggered which differs from the approach taken f.ex. in the discovery plugin.
By returning the downloader errors directly in the bundle plugin trigger method you can f.ex. check for HTTPError and its status code so to determine if a retry can be successful (status code 5xx) or will yield the same result (4xx).

What are the changes in this PR?

creating an error type for the bundle plugin similar to ast.Errors that will collect the different errors and wrap them in a detailed error type carrying the bundle name
collecting all downloader errors for bundles in manual trigger mode.
return errors in bundle plugin trigger mode or nil if no errors occurred
changed the exec_test to also verify the returned errors and not expect zero errors

Notes to assist PR review:

Further comments:

the different behaviour of the exec method might be undesired but would IMO be helpful
in case the behaviour change is undesired this functionality could be made configurable
also the downloader errors for bundles in periodic trigger mode could be returned

netlify · 2024-10-30T15:09:37Z

✅ Deploy Preview for openpolicyagent ready!

Name	Link
🔨 Latest commit	`356764b`
🔍 Latest deploy log	https://app.netlify.com/sites/openpolicyagent/deploys/6731c3c8d33a7800088d772a
😎 Deploy Preview	https://deploy-preview-7143--openpolicyagent.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

torwunder · 2024-10-31T14:16:08Z

plugins/bundle/plugin_test.go

@@ -6522,6 +6522,68 @@ func TestPluginManualTriggerWithTimeout(t *testing.T) {
 	}
 }

+func TestPluginManualTriggerWithServerError(t *testing.T) {


This test triggers the race condition.
My investigation led to the conclusion that this is triggered by having the bundle with the "periodic" trigger mode in the test.
The downloader.oneShot function will be triggered by the explicitly trigger method and also by the downloader.loop function.
The access to the shared variables (f.ex. etag, client) in Downloader is not synchronized and leads to the race condition.
A possible solution is to only trigger bundle dowloads with "manual" trigger mode in the trigger method.
F.ex. like this (in bundle.Plugin.Trigger)

func (p *Plugin) Trigger(ctx context.Context) error { [...] for name, dl := range p.downloaders { downloaders[name] = dl p.cfgMtx.RLock() triggerMode := p.config.Bundles[name].Trigger p.cfgMtx.RUnlock() if triggerMode != nil && *triggerMode == plugins.TriggerManual { downloaders[name] = dl } } [...]

This would also solve the question if Trigger should return errors for bundles with "periodic" trigger mode.

@ashutosh-narkar
Do you have a recommendation how to proceed with this?
To make the test green, I could remove the configuration for the bundle in "periodic" trigger mode but I think this might be a problem in the bundle plugin that should be addressed.

I think having only a manual trigger for the test should be fine.

ashutosh-narkar

Thanks for the contribution @torwunder! One high level comment I have is about the structure of the error. If we can model it similar to https://github.com/open-policy-agent/opa/blob/main/plugins/bundle/status.go#L64, it would be more informative I think.

torwunder · 2024-11-06T17:05:04Z

@ashutosh-narkar I modelled the error similar to the status.
I did not put the collected ast.Error from the ast.Errors as an array into the Err field (in contrast to the bundle status) but rather ast.Errors itself to make it easier to use with single errors like HTTPError
This can ofc. be changed.

ashutosh-narkar · 2024-11-06T19:27:40Z

plugins/bundle/errors.go

+	return fmt.Sprintf("Bundle name: %s, Code: %s, HTTPCode: %d, Message: %s", e.BundleName, errCode, e.HTTPCode, e.Message)
+}
+
+func (e Error) Unwrap() error {


Nit: Is there a reason to define this method?

it will allow using errors.As for retrieving the wrapped error. Something like this:

errs := Errors{NewBundleError("example", download.HTTPError{StatusCode: 500})} var httpError download.HTTPError errors.As(errs, &httpError) if httpError.StatusCode == 500 { ...

There is a test in errors_test.go (TestUnwrap) that will start to fail if we remove the function.

ashutosh-narkar · 2024-11-06T19:34:50Z

plugins/bundle/plugin.go

+		// plugin callback will also log the trigger error and include it in the bundle status
+		err := d.Trigger(ctx)
+		// only return errors for TriggerMode manual as periodic bundles will be retried
+		if err != nil && *p.config.Bundles[name].Trigger == plugins.TriggerManual {


Use the Config() method on the plugin to retrieve the config.

@ashutosh-narkar do you think it makes sense to only return the errors for bundles in manual trigger mode?
It felt sensible to me as periodic triggermode will be retried by the bundle plugin but might also just create confusion.
it also creates this additional if statement which will then not be tested.

Manual trigger mode can currently only be configured via a library integration. So to keep parity with the discovery plugin, returning errors in the manual mode makes sense.

ashutosh-narkar · 2024-11-06T19:35:33Z

plugins/bundle/plugin_test.go

@@ -6522,6 +6522,68 @@ func TestPluginManualTriggerWithTimeout(t *testing.T) {
 	}
 }

+func TestPluginManualTriggerWithServerError(t *testing.T) {


I think having only a manual trigger for the test should be fine.

ashutosh-narkar · 2024-11-12T19:29:31Z

cmd/exec_test.go

@@ -321,15 +323,32 @@ main contains "hello" if {

 					ctx, cancel := context.WithCancel(context.Background())
 					defer cancel()
-					go func() {
+					go func(expectedErrors []string) {


I'm trying to understand what we're testing here?

the existing test is verifying that the errors are present in the status,
my goal was to also verify that these errors are also returned directly from the trigger method
handing over the expected error as a parameter became necessary due to a detected race condition as the goroutine will otherwise work on tc.expErrs which is changed concurrently in the outer loop (l. 294)

ashutosh-narkar · 2024-11-12T19:35:11Z

@torwunder thanks for addressing the comments. Can you please fix the conflict and squash your changes and we can then get this in? Thanks!

…r errors for bundles in manual trigger mode Signed-off-by: towunderlich <[email protected]>

* model Error similar to bundle status Signed-off-by: towunderlich <[email protected]>

* only test error handling for bundle in manual trigger mode * use plugin config method Signed-off-by: towunderlich <[email protected]>

* enable new test to run in parallel Signed-off-by: towunderlich <[email protected]>

torwunder · 2024-11-13T09:09:47Z

@ashutosh-narkar I resolved the conflict and added the parallel setting to the test, in line with the upstream changes.
also thanks for your reviews :)

torwunder force-pushed the bundle_plugin_error_return_value branch 3 times, most recently from 201abe0 to c510621 Compare October 31, 2024 13:59

torwunder commented Oct 31, 2024

View reviewed changes

ashutosh-narkar reviewed Nov 5, 2024

View reviewed changes

ashutosh-narkar reviewed Nov 6, 2024

View reviewed changes

torwunder force-pushed the bundle_plugin_error_return_value branch 2 times, most recently from 356764b to 2776139 Compare November 12, 2024 08:58

ashutosh-narkar reviewed Nov 12, 2024

View reviewed changes

torwunder force-pushed the bundle_plugin_error_return_value branch from 2776139 to f9a46e2 Compare November 13, 2024 08:45

torwunder added 4 commits November 13, 2024 09:54

enable direct error handling for bundle plugin by returning downloade…

2289fda

…r errors for bundles in manual trigger mode Signed-off-by: towunderlich <[email protected]>

Fixed changes request by @ashutosh-narkar (squash before merge)

25e4c91

* model Error similar to bundle status Signed-off-by: towunderlich <[email protected]>

Fixed changes request by @ashutosh-narkar (squash before merge)

1397690

* only test error handling for bundle in manual trigger mode * use plugin config method Signed-off-by: towunderlich <[email protected]>

Fixed changes request by @ashutosh-narkar (squash before merge)

bd3212c

* enable new test to run in parallel Signed-off-by: towunderlich <[email protected]>

torwunder force-pushed the bundle_plugin_error_return_value branch from f9a46e2 to bd3212c Compare November 13, 2024 08:57

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

enable direct error handling for bundle plugin trigger method #7143

enable direct error handling for bundle plugin trigger method #7143

torwunder commented Oct 30, 2024

netlify bot commented Oct 30, 2024 •

edited

Loading

torwunder Oct 31, 2024 •

edited

Loading

torwunder Nov 6, 2024

ashutosh-narkar Nov 6, 2024

ashutosh-narkar left a comment

torwunder commented Nov 6, 2024

ashutosh-narkar Nov 6, 2024

torwunder Nov 7, 2024

ashutosh-narkar Nov 6, 2024

torwunder Nov 7, 2024

ashutosh-narkar Nov 7, 2024

ashutosh-narkar Nov 6, 2024

ashutosh-narkar Nov 12, 2024

torwunder Nov 13, 2024

ashutosh-narkar commented Nov 12, 2024

torwunder commented Nov 13, 2024

enable direct error handling for bundle plugin trigger method #7143

Are you sure you want to change the base?

enable direct error handling for bundle plugin trigger method #7143

Conversation

torwunder commented Oct 30, 2024

Why the changes in this PR are needed?

What are the changes in this PR?

Notes to assist PR review:

Further comments:

netlify bot commented Oct 30, 2024 • edited Loading

✅ Deploy Preview for openpolicyagent ready!

torwunder Oct 31, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ashutosh-narkar left a comment

Choose a reason for hiding this comment

torwunder commented Nov 6, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ashutosh-narkar commented Nov 12, 2024

torwunder commented Nov 13, 2024

netlify bot commented Oct 30, 2024 •

edited

Loading

torwunder Oct 31, 2024 •

edited

Loading