feat(framework,api): add source when triggered from workflow

[ainouzgali]

What changed? Why was the change needed?

Fix: Triggering a workflow from the bridge app, without syncing the workflow resulted in a successful trigger. Instead, should throw an error.

The tricky part with this "bug" is that there are multiple other cases where we do want to allow trigger of an un-synced workflow (like studio test trigger, trigger of the onboarding playground). They all reach the same api code snippet, as they contain a bridgeUrl, what I was looking for was to find a way to "force" this case, of workflowIdentifier.trigger to signal that this one does require a sync unlike the others.

The best way I found, that I felt was the most clean and still works with all other different usecases we have at this moment, is to add the __source to the payload to indicate that. When the functionality grows, we would need to do it in a more clever way - not only here but for all "stateless" workflows. Maybe have an explicit flag as part of the trigger structure, but that would be a major change for the context of this issue

Screenshots

Expand for optional sections

Related enterprise PR

Special notes for your reviewer

[linear]

NV-4272 No error returned when triggering unsynced workflow from @novu/framework

[djabarovgeorge]

Great job spotting all the uses in the trigger flow. I was surprised to see that we're passing the bridge URL by default. This means that for every request, we’re relying less on the state stored in the database.

As a result, instead of querying the database for workflow entities and control variables, the API performs a bridge discovery request and sends the data to the trigger engine.

In my opinion, this isn’t the expected behavior. We might need to add a new flag to explicitly decide whether the flow should be stateful or stateless.

[djabarovgeorge]

Great job spotting all the uses in the trigger flow. I was surprised to see that we're passing the bridge URL by default. This means that for every request, we’re relying less on the state stored in the database.

As a result, instead of querying the database for workflow entities and control variables, the API performs a bridge discovery request and sends the data to the trigger engine.

In my opinion, this isn’t the expected behavior. We might need to add a new flag to explicitly decide whether the flow should be stateful or stateless.

@rifont What do you think about this? Let me know if you need more context. I’m a bit concerned about giving users the option to choose an unsynced (stateless) flow.

[pkg-pr-new]

Open in Stackblitz

pnpm add https://pkg.pr.new/novuhq/novu/@novu/js@6504

commit: 03a3faa