rfellows commented on PR #11175:
URL: https://github.com/apache/nifi/pull/11175#issuecomment-4652791755
Heads-up on a related backend bug I've been hitting while testing this
branch end-to-end against the Connector REST endpoints. Flagging it here
because it's the same family as the `findProcessGroup` fix you just landed in
`42fbdd9`, and the fix would likely sit in the same area — but happy to split
it into its own JIRA if you'd prefer.
### Symptom
`GET
/nifi-api/processors/{id}/descriptors?propertyName=<csTypedProp>&sensitive=false`
returns `"allowableValues": []` for any controller-service-typed property on a
processor that lives inside a Connector's managed flow — including when the
processor's currently configured CS exists in that connector's group and is
returned by `GET
/nifi-api/flow/process-groups/{parentGroupId}/controller-services`. The same
empty `allowableValues` shows up on CS-typed descriptors embedded in `GET
/processors/{id}` and on the descriptor returned by the inline "create new
service" round-trip from `PropertyTableHelper`. Flow-designer is unaffected;
only the Connector context reproduces it (regardless of whether the connector
is in `TROUBLESHOOTING` — I see it in normal `RUNNING` state too).
Downstream UI effect: the value cell renders the CS UUID instead of its
name, the combo box can't enumerate other compatible CSes, and a
freshly-created inline CS also comes back as a UUID with no allowable-values
context.
### Trace
`StandardNiFiServiceFacade.getProcessorPropertyDescriptor` →
```java
return dtoFactory.createPropertyDescriptorDto(descriptor,
processor.getProcessGroup().getIdentifier());
```
`DtoFactory#createPropertyDescriptorDto` (CS-typed branch) →
```java
final List<String> controllerServiceIdentifiers = new ArrayList<>(
controllerServiceProvider.getControllerServiceIdentifiers(serviceDefinition,
groupId));
```
`StandardControllerServiceProvider#getControllerServiceIdentifiers`:
```java
ProcessGroup group = getRootGroup();
if (!FlowManager.ROOT_GROUP_ID_ALIAS.equals(groupId) &&
!group.getIdentifier().equals(groupId)) {
group = group.findProcessGroup(groupId);
}
if (group == null) {
return Collections.emptySet();
}
```
Even with the `findProcessGroup` change from `42fbdd9` applied, the call
from `mainRoot.findProcessGroup(connectorManagedPgId)` still returns null:
- `flowManager.getGroup(id)` (unconditional) finds the managed PG fine.
- `isOwner(group.getParent())` then walks parents. The connector's managed
root only has `setExplicitParentAuthorizable(connectorNode)` set on it in
`StandardFlowManager.createConnector(...)` — there is no `setParent(...)`
linking it under the main root group. So `getParent()` returns `null`, the
`isOwner` loop terminates immediately, and `findProcessGroup` returns null.
- `getControllerServiceIdentifiers` short-circuits to
`Collections.emptySet()` before the class/scope filter ever runs — hence the
totally empty `allowableValues` array (not "wrong CSes filtered out").
The same `getRootGroup().findProcessGroup(...)` pattern exists in a handful
of other places in `StandardControllerServiceProvider`
(`getControllerServiceNodes(String)` and friends) and would presumably miss
connector-managed groups in the same way for any caller that resolves a group
from a connector-context id starting at main root.
### Suggested shape of the fix
Smallest change that matches the direction this PR has been heading (i.e.
the new `ConnectorManagedComponentLookup` facades and the
`locateProcessGroup(..., includeConnectorManaged=true)` calls in
`StandardProcessGroupDAO`): inside
`StandardControllerServiceProvider#getControllerServiceIdentifiers(serviceType,
groupId)`, replace the `getRootGroup().findProcessGroup(groupId)` traversal
with a direct `flowManager.getGroup(groupId)` lookup. The existing class filter
(`service.getProxiedControllerService().getClass()` / `isAssignableFrom`) and
the per-group `getControllerServices(true, false)` enumeration still do the
right thing once the group is reachable. Auth has already happened on the
owning processor, so the `isOwner` hierarchy gate isn't load-bearing for this
code path.
### Repro
1. Open a Connector whose managed flow contains a processor with a CS-typed
property already configured to point at a CS that lives in the same connector
group (e.g. PublishKafkaRecord → KafkaConnectionService).
2. `GET
/nifi-api/processors/{procId}/descriptors?propertyName=Kafka%20Connection%20Service&sensitive=false`
→ response below.
3. `GET /nifi-api/flow/process-groups/{parentGroupId}/controller-services` →
returns the CS with full details, confirming it exists and is enabled.
```json
{
"propertyDescriptor": {
"name": "Kafka Connection Service",
"displayName": "Kafka Connection Service",
"allowableValues": [],
"identifiesControllerService":
"org.apache.nifi.kafka.service.api.KafkaConnectionService",
"identifiesControllerServiceBundle": {
"group": "org.apache.nifi",
"artifact": "nifi-kafka-service-api-nar",
"version": "2.10.0-SNAPSHOT"
},
"dependencies": []
}
}
```
Reproducible regardless of Troubleshooting state — the connector was in
normal `RUNNING` state when I captured this. Happy to file a separate JIRA if
that's a cleaner home; just wanted to flag it here since you're already in the
area and the fix would fit the same shape.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
