feed lifecycle event should have a fully resolved trigger name
- Dominant language
- Scala
- Stars
- 6.8k
- Forks
- 1.2k
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 2
Description
In looking through some code for the providers, I noticed that when a user creates an event feed, the request carries a trigger name that is not fully resolved.
For example, when creating an alarm feed,
wsk trigger create t --feed whisk.system/alarms/once ...
The feed provider receives the following request:
{
"authKey":"...",
"lifecycleEvent":"CREATE",
"triggerName":"/_/t"
}
The trigger name isn't fully resolved as it uses the implicit/placeholder `_`. This means the feed handler has to resolve the namespace. It can do this by doing a lookup using the provided key against the openwhisk controller:
GET https://apikey@apihost/api/v1/namespaces
In the providers I looked at, the namespace is being resolved another way: by using the `__OW_NAMESPACE` activation context value. This is OK as well but if we just treat the feed creation as an arbitrary API call, this won't work. So either the client has to resolve the trigger name fully, or the provider has to do it (or both?).
I am contemplating a change to the feed specification to make the trigger name fully qualified (ie no underscore) and so clients must do this and providers can reject requests that don't conform.
Current specification https://github.com/apache/incubator-openwhisk/blob/master/docs/feeds.md#implementing-feed-actions
Related to https://github.com/apache/incubator-openwhisk-cli/issues/416
Contributor guide
Research direction
Start with docs/feeds.md at “Implementing feed actions” and the related apache/incubator-openwhisk-cli issue #416. Trace how feed creation produces the lifecycle event shown in the report, then compare the client and provider expectations. Done means the project has a decided, documented behavior for fully resolving the trigger name and the relevant request path follows it.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- scala
- Domain
- api, backend, cloud
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100