Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Carry triggerinstance context everywhere #1602

Closed
manasdk opened this issue Jun 9, 2015 · 2 comments
Closed

Carry triggerinstance context everywhere #1602

manasdk opened this issue Jun 9, 2015 · 2 comments

Comments

@manasdk
Copy link
Contributor

manasdk commented Jun 9, 2015

  1. add triggerinstance.correlation_id to supply reference to an external event in a triggerinstance
  2. triggerinstance.id accessible in a rule so that it can be passed into an action
  3. on-start notification to notify when an execution is started
  4. ActionTrigger_start TriggerType
  5. triggerinstance.id and triggerinstance.correlation_id should be available in notifier, actiontrigger etc.
@skarmark
Copy link

Little bit of a context of the use case which we talked about -

Recently I added the ability to be able to filter executions by trigger instance id. This is useful when you know the trigger instance id or can look for it easily. For thousands of executions run in response to sensors listening to messaging queue such as rabbitmq, it is hard to find a particular execution. There a couple of ways to solve this -

  1. Give ability for users to create their own IDs eg. UUID inside the sensor and pass it as correlation_id when dispatching trigger (Reactor model and basic tox setup #1 and maybe STORM7-CreateStackControllersubfolderinrepo #5 above).
  2. Make triggerinstance.id accessible in the sensor or rule so that it can be communicated to the user (# 2, 3 and 4 above).

Personally, I like option 1 better. This way, stackstorm doesn't need to communicate the id, since user already knows it. And this being an attribute of trigger instance, it makes it easy to filter by using stackstorm api or cli or even webui. If we use a custom attribute in payload to store this, users will need to explicitly pass it through all the actions in the workflow and filtering is harder as well. I believe this should be pretty easy to add as well.

@dzimine
Copy link

dzimine commented Sep 29, 2015

implemented with trace-tags

@dzimine dzimine closed this as completed Sep 29, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants