Description of bug
docket export --app <app> --resource <global-address> exports nothing and exits non-zero, reporting the global address as not found on the server - even when the resource exists.
Reproduced against the export fixtures with a server holding app-one and the redis plugin:
--app app-one --resource 'dokku_plugin[name=redis]'
recipe: []
MissingResources: [dokku_plugin[name=redis]]
Two things combine. The leading global play is skipped whenever opts.Apps is set (tasks/export.go:303), which is right for a bare --app foo and wrong once an address explicitly asks for a global resource. Then resourceFilter.appNames (tasks/export_resource.go:173) walks only app-scoped selectors, so a run whose addresses are all global-scoped yields an empty app set, reads as restricted, and returns early with the address recorded as unmatched.
The address is not unmatched. Nothing looked for it, because the only place that would have - the global play - was skipped a few lines earlier.
--app alone and --resource alone both behave correctly; it is only the combination. The fix is to let a global-scoped address keep the global play when --app is also given, and to stop counting a global address as unmatched on the strength of the app-scoped pass.
Found while working on #425, which is what made the interaction visible: --resource post-dates that issue's claim that there is no narrowed read path for global resources, and this is the corner where the narrowed path does not compose.
Description of bug
docket export --app <app> --resource <global-address>exports nothing and exits non-zero, reporting the global address as not found on the server - even when the resource exists.Reproduced against the export fixtures with a server holding
app-oneand theredisplugin:Two things combine. The leading global play is skipped whenever
opts.Appsis set (tasks/export.go:303), which is right for a bare--app fooand wrong once an address explicitly asks for a global resource. ThenresourceFilter.appNames(tasks/export_resource.go:173) walks only app-scoped selectors, so a run whose addresses are all global-scoped yields an empty app set, reads asrestricted, and returns early with the address recorded as unmatched.The address is not unmatched. Nothing looked for it, because the only place that would have - the global play - was skipped a few lines earlier.
--appalone and--resourcealone both behave correctly; it is only the combination. The fix is to let a global-scoped address keep the global play when--appis also given, and to stop counting a global address as unmatched on the strength of the app-scoped pass.Found while working on #425, which is what made the interaction visible:
--resourcepost-dates that issue's claim that there is no narrowed read path for global resources, and this is the corner where the narrowed path does not compose.