Genesys Cloud - Developer Community!

Hi @Stéphane Labrune,

I think there are actually two separate points here.

Regarding the events with status = Processing, what you are seeing seems consistent with the asynchronous nature of the forecast generation. At that stage, the operation is still running, so the operationId is mainly there to correlate the notification with the generation request. The actual forecast details are expected to become available when the operation reaches Complete.

The part I am less sure about is why you received notifications only for the fourth forecast. I think we would need a little more information about how the requests and notifications are being handled before concluding that the first three events were not published.

Could you share a few additional details?

• What HTTP status and response body did you receive for each of the four generate requests?

• Did each request return a different operationId?

• Were all four requests made with the same parameters, including forceAsync if you are using it?

• Was the notification subscription already active before the first request?

• Did the WebSocket/channel remain connected during all four executions, or was it recreated/reconnected at some point?

• Are you filtering the incoming notifications by operationId, status, or any other property in your code?

• Are you consuming this topic through the Notifications API/WebSocket or through EventBridge?

It would also be useful to confirm whether the first three forecasts were actually created successfully. That would help separate a forecast generation issue from a notification delivery/consumption issue.

If the forecasts exist but only the last operation produced notifications on your consumer, I would probably start investigating the subscription/channel lifecycle and how the application is processing the messages.

Hope this helps narrow it down a bit. If you can share the request/response samples - with any sensitive information removed - it may be easier to understand what is happening.

Hello and thank you for your message,

Here are some additional details:
We use EventBridge to retrieve the events (so no WebSocket, and no subscription channel issues).
I can confirm that the first three forecasts were indeed created.

The forecast generations were done via the UI.

Regarding the events generated with the "Processing" status, they all share the same operationId.

The main concern is the lack of information about which forecast they belong to (date, etc.).
At this point, I think I will only use the events with the "Complete" status (if I receive those events).

Hi @Stéphane Labrune,

I think there are actually two separate points here.

Regarding the events with status = Processing, what you are seeing seems consistent with the asynchronous nature of the forecast generation. At that stage, the operation is still running, so the operationId is mainly there to correlate the notification with the generation request. The actual forecast details are expected to become available when the operation reaches Complete.

The part I am less sure about is why you received notifications only for the fourth forecast. I think we would need a little more information about how the requests and notifications are being handled before concluding that the first three events were not published.

Could you share a few additional details?

• What HTTP status and response body did you receive for each of the four generate requests?

• Did each request return a different operationId?

• Were all four requests made with the same parameters, including forceAsync if you are using it?

• Was the notification subscription already active before the first request?

• Did the WebSocket/channel remain connected during all four executions, or was it recreated/reconnected at some point?

• Are you filtering the incoming notifications by operationId, status, or any other property in your code?

• Are you consuming this topic through the Notifications API/WebSocket or through EventBridge?

It would also be useful to confirm whether the first three forecasts were actually created successfully. That would help separate a forecast generation issue from a notification delivery/consumption issue.

If the forecasts exist but only the last operation produced notifications on your consumer, I would probably start investigating the subscription/channel lifecycle and how the application is processing the messages.

Hope this helps narrow it down a bit. If you can share the request/response samples - with any sensitive information removed - it may be easier to understand what is happening.

Apologies for the delay getting back to you on this.

This route can complete either synchronously or asynchronously, and which one happens explains what you're seeing. When a generation finishes quickly, the response comes back with the completed forecast already in the body, so no notification is sent for that call. Only when a generation takes long enough to miss that synchronous window does the call come back as "Processing," and the job continues asynchronously, publishing the Processing and Complete events from there.

Of your four identical requests, three finished inside that synchronous window and returned the completed forecast directly in the response. There was never an event to send for those; nothing was dropped. Only the fourth ran long enough to go asynchronous, which is also why every Processing event you saw shared one operationId. There was only ever one asynchronous operation in the batch.

On the metadata question: Processing events are only ever expected to carry the operationId. That status exists purely to signal the job is still running. Fields like weekdate and weekcount only get populated once the job reaches Complete, since that's the first point the full result actually exists. It's not an omission.

This route predates Event Bridge, and it's never been redesigned to fully support it. If you'd find it valuable to always get a notification, regardless of how quickly generation completes, I'd encourage submitting an idea on the Ideas portal so it can be prioritized: https://genesyscloud.ideas.aha.io/ideas

Going forward, you can switch on either the HTTP response code or the status field in the response body, they carry the same information. A 201 (or a "Complete" status) means the work is already done. A 202 (or a "Processing" status) means it's still running, so save the operationId and use it to correlate against the Processing and Complete notifications that follow. Either way, the forecast metadata is what's returned, both in the response and in a Complete notification.

One more thing worth calling out: make sure you're subscribed to the notification topic before sending the generate request, not after. If there's no active subscriber at the moment a notification would go out, it isn't queued or replayed, it's simply not sent.

Hello and thank you for your message,

Here are some additional details:
We use EventBridge to retrieve the events (so no WebSocket, and no subscription channel issues).
I can confirm that the first three forecasts were indeed created.

The forecast generations were done via the UI.

Regarding the events generated with the "Processing" status, they all share the same operationId.

The main concern is the lack of information about which forecast they belong to (date, etc.).
At this point, I think I will only use the events with the "Complete" status (if I receive those events).

Hi @Stéphane Labrune,

I think there are actually two separate points here.

Regarding the events with status = Processing, what you are seeing seems consistent with the asynchronous nature of the forecast generation. At that stage, the operation is still running, so the operationId is mainly there to correlate the notification with the generation request. The actual forecast details are expected to become available when the operation reaches Complete.

The part I am less sure about is why you received notifications only for the fourth forecast. I think we would need a little more information about how the requests and notifications are being handled before concluding that the first three events were not published.

Could you share a few additional details?

• What HTTP status and response body did you receive for each of the four generate requests?

• Did each request return a different operationId?

• Were all four requests made with the same parameters, including forceAsync if you are using it?

• Was the notification subscription already active before the first request?

• Did the WebSocket/channel remain connected during all four executions, or was it recreated/reconnected at some point?

• Are you filtering the incoming notifications by operationId, status, or any other property in your code?

• Are you consuming this topic through the Notifications API/WebSocket or through EventBridge?

It would also be useful to confirm whether the first three forecasts were actually created successfully. That would help separate a forecast generation issue from a notification delivery/consumption issue.

If the forecasts exist but only the last operation produced notifications on your consumer, I would probably start investigating the subscription/channel lifecycle and how the application is processing the messages.

Hope this helps narrow it down a bit. If you can share the request/response samples - with any sensitive information removed - it may be easier to understand what is happening.

Thank you for your responses.

We find this behavior unsatisfactory.

It would be logical for the event v2.workforcemanagement.businessunits.{id}.shorttermforecasts.generate to be received in all cases when a forecast is generated, and we do not see any mention of this in the documentation or where it is described.

This behavior is problematic because it forces us to test via the REST API every week over a year to check if forecasts have been created.

 Indeed, the API with the 'recent' parameter only covers the past 26 weeks, so we have to test weekly, and due to API rate limits (60 requests per minute), this quickly becomes a problem.

Is the same behavior observed for v2.workforcemanagement.businessunits.{id}.scheduling.runs?

Apologies for the delay getting back to you on this.

This route can complete either synchronously or asynchronously, and which one happens explains what you're seeing. When a generation finishes quickly, the response comes back with the completed forecast already in the body, so no notification is sent for that call. Only when a generation takes long enough to miss that synchronous window does the call come back as "Processing," and the job continues asynchronously, publishing the Processing and Complete events from there.

Of your four identical requests, three finished inside that synchronous window and returned the completed forecast directly in the response. There was never an event to send for those; nothing was dropped. Only the fourth ran long enough to go asynchronous, which is also why every Processing event you saw shared one operationId. There was only ever one asynchronous operation in the batch.

On the metadata question: Processing events are only ever expected to carry the operationId. That status exists purely to signal the job is still running. Fields like weekdate and weekcount only get populated once the job reaches Complete, since that's the first point the full result actually exists. It's not an omission.

This route predates Event Bridge, and it's never been redesigned to fully support it. If you'd find it valuable to always get a notification, regardless of how quickly generation completes, I'd encourage submitting an idea on the Ideas portal so it can be prioritized: https://genesyscloud.ideas.aha.io/ideas

Going forward, you can switch on either the HTTP response code or the status field in the response body, they carry the same information. A 201 (or a "Complete" status) means the work is already done. A 202 (or a "Processing" status) means it's still running, so save the operationId and use it to correlate against the Processing and Complete notifications that follow. Either way, the forecast metadata is what's returned, both in the response and in a Complete notification.

One more thing worth calling out: make sure you're subscribed to the notification topic before sending the generate request, not after. If there's no active subscriber at the moment a notification would go out, it isn't queued or replayed, it's simply not sent.

Hello and thank you for your message,

Here are some additional details:
We use EventBridge to retrieve the events (so no WebSocket, and no subscription channel issues).
I can confirm that the first three forecasts were indeed created.

The forecast generations were done via the UI.

Regarding the events generated with the "Processing" status, they all share the same operationId.

The main concern is the lack of information about which forecast they belong to (date, etc.).
At this point, I think I will only use the events with the "Complete" status (if I receive those events).

Hi @Stéphane Labrune,

I think there are actually two separate points here.

Regarding the events with status = Processing, what you are seeing seems consistent with the asynchronous nature of the forecast generation. At that stage, the operation is still running, so the operationId is mainly there to correlate the notification with the generation request. The actual forecast details are expected to become available when the operation reaches Complete.

The part I am less sure about is why you received notifications only for the fourth forecast. I think we would need a little more information about how the requests and notifications are being handled before concluding that the first three events were not published.

Could you share a few additional details?

• What HTTP status and response body did you receive for each of the four generate requests?

• Did each request return a different operationId?

• Were all four requests made with the same parameters, including forceAsync if you are using it?

• Was the notification subscription already active before the first request?

• Did the WebSocket/channel remain connected during all four executions, or was it recreated/reconnected at some point?

• Are you filtering the incoming notifications by operationId, status, or any other property in your code?

• Are you consuming this topic through the Notifications API/WebSocket or through EventBridge?

It would also be useful to confirm whether the first three forecasts were actually created successfully. That would help separate a forecast generation issue from a notification delivery/consumption issue.

If the forecasts exist but only the last operation produced notifications on your consumer, I would probably start investigating the subscription/channel lifecycle and how the application is processing the messages.

Hope this helps narrow it down a bit. If you can share the request/response samples - with any sensitive information removed - it may be easier to understand what is happening.

Sorry this turned into an unsatisfactory experience. A forum thread isn't where we can commit to changing how this endpoint behaves, that's a call for our product process, not something I can promise here. If a reliable way to track every generation request, fast or slow, without falling back to polling would help, I'd suggest posting it on the Ideas portal (https://genesyscloud.ideas.aha.io/ideas). That's where requests like this get weighed against the rest of the roadmap. (cc @Andrew Boland)

On scheduling runs: no, you won't hit the same issue there. That endpoint works differently from short-term forecast generation. By default it always comes back with a processing status right away instead of racing to finish synchronously, and the completion notification on the scheduling.runs topic fires once the run finishes no matter how fast it completes. So the gap you found, fast completions with no notification at all, shouldn't show up on schedule generation. It's a very different mechanism on the back end from scheduling.

Thank you for your responses.

We find this behavior unsatisfactory.

It would be logical for the event v2.workforcemanagement.businessunits.{id}.shorttermforecasts.generate to be received in all cases when a forecast is generated, and we do not see any mention of this in the documentation or where it is described.

This behavior is problematic because it forces us to test via the REST API every week over a year to check if forecasts have been created.

 Indeed, the API with the 'recent' parameter only covers the past 26 weeks, so we have to test weekly, and due to API rate limits (60 requests per minute), this quickly becomes a problem.

Is the same behavior observed for v2.workforcemanagement.businessunits.{id}.scheduling.runs?

Apologies for the delay getting back to you on this.

This route can complete either synchronously or asynchronously, and which one happens explains what you're seeing. When a generation finishes quickly, the response comes back with the completed forecast already in the body, so no notification is sent for that call. Only when a generation takes long enough to miss that synchronous window does the call come back as "Processing," and the job continues asynchronously, publishing the Processing and Complete events from there.

Of your four identical requests, three finished inside that synchronous window and returned the completed forecast directly in the response. There was never an event to send for those; nothing was dropped. Only the fourth ran long enough to go asynchronous, which is also why every Processing event you saw shared one operationId. There was only ever one asynchronous operation in the batch.

On the metadata question: Processing events are only ever expected to carry the operationId. That status exists purely to signal the job is still running. Fields like weekdate and weekcount only get populated once the job reaches Complete, since that's the first point the full result actually exists. It's not an omission.

This route predates Event Bridge, and it's never been redesigned to fully support it. If you'd find it valuable to always get a notification, regardless of how quickly generation completes, I'd encourage submitting an idea on the Ideas portal so it can be prioritized: https://genesyscloud.ideas.aha.io/ideas

Going forward, you can switch on either the HTTP response code or the status field in the response body, they carry the same information. A 201 (or a "Complete" status) means the work is already done. A 202 (or a "Processing" status) means it's still running, so save the operationId and use it to correlate against the Processing and Complete notifications that follow. Either way, the forecast metadata is what's returned, both in the response and in a Complete notification.

One more thing worth calling out: make sure you're subscribed to the notification topic before sending the generate request, not after. If there's no active subscriber at the moment a notification would go out, it isn't queued or replayed, it's simply not sent.

Hello and thank you for your message,

Here are some additional details:
We use EventBridge to retrieve the events (so no WebSocket, and no subscription channel issues).
I can confirm that the first three forecasts were indeed created.

The forecast generations were done via the UI.

Regarding the events generated with the "Processing" status, they all share the same operationId.

The main concern is the lack of information about which forecast they belong to (date, etc.).
At this point, I think I will only use the events with the "Complete" status (if I receive those events).

Hi @Stéphane Labrune,

I think there are actually two separate points here.

Regarding the events with status = Processing, what you are seeing seems consistent with the asynchronous nature of the forecast generation. At that stage, the operation is still running, so the operationId is mainly there to correlate the notification with the generation request. The actual forecast details are expected to become available when the operation reaches Complete.

The part I am less sure about is why you received notifications only for the fourth forecast. I think we would need a little more information about how the requests and notifications are being handled before concluding that the first three events were not published.

Could you share a few additional details?

• What HTTP status and response body did you receive for each of the four generate requests?

• Did each request return a different operationId?

• Were all four requests made with the same parameters, including forceAsync if you are using it?

• Was the notification subscription already active before the first request?

• Did the WebSocket/channel remain connected during all four executions, or was it recreated/reconnected at some point?

• Are you filtering the incoming notifications by operationId, status, or any other property in your code?

• Are you consuming this topic through the Notifications API/WebSocket or through EventBridge?

It would also be useful to confirm whether the first three forecasts were actually created successfully. That would help separate a forecast generation issue from a notification delivery/consumption issue.

If the forecasts exist but only the last operation produced notifications on your consumer, I would probably start investigating the subscription/channel lifecycle and how the application is processing the messages.

Hope this helps narrow it down a bit. If you can share the request/response samples - with any sensitive information removed - it may be easier to understand what is happening.

Thank you for your responses.

It's good news regarding the scheduling.runs event, as I will be able to use it, unlike the forecast.generate event.

I have consulted several other developers on this matter, and everyone generally agrees that this is an API issue that should be fixed rather than considered a potential evolution.

The development requests from our client have very tight deadlines, so proposing ideas at this stage would be a waste of time (which we do not have), because even if any of them were validated, it would be far too late for our current developments.

Best regards.

Sorry this turned into an unsatisfactory experience. A forum thread isn't where we can commit to changing how this endpoint behaves, that's a call for our product process, not something I can promise here. If a reliable way to track every generation request, fast or slow, without falling back to polling would help, I'd suggest posting it on the Ideas portal (https://genesyscloud.ideas.aha.io/ideas). That's where requests like this get weighed against the rest of the roadmap. (cc @Andrew Boland)

On scheduling runs: no, you won't hit the same issue there. That endpoint works differently from short-term forecast generation. By default it always comes back with a processing status right away instead of racing to finish synchronously, and the completion notification on the scheduling.runs topic fires once the run finishes no matter how fast it completes. So the gap you found, fast completions with no notification at all, shouldn't show up on schedule generation. It's a very different mechanism on the back end from scheduling.

Thank you for your responses.

We find this behavior unsatisfactory.

It would be logical for the event v2.workforcemanagement.businessunits.{id}.shorttermforecasts.generate to be received in all cases when a forecast is generated, and we do not see any mention of this in the documentation or where it is described.

This behavior is problematic because it forces us to test via the REST API every week over a year to check if forecasts have been created.

 Indeed, the API with the 'recent' parameter only covers the past 26 weeks, so we have to test weekly, and due to API rate limits (60 requests per minute), this quickly becomes a problem.

Is the same behavior observed for v2.workforcemanagement.businessunits.{id}.scheduling.runs?

Apologies for the delay getting back to you on this.

This route can complete either synchronously or asynchronously, and which one happens explains what you're seeing. When a generation finishes quickly, the response comes back with the completed forecast already in the body, so no notification is sent for that call. Only when a generation takes long enough to miss that synchronous window does the call come back as "Processing," and the job continues asynchronously, publishing the Processing and Complete events from there.

Of your four identical requests, three finished inside that synchronous window and returned the completed forecast directly in the response. There was never an event to send for those; nothing was dropped. Only the fourth ran long enough to go asynchronous, which is also why every Processing event you saw shared one operationId. There was only ever one asynchronous operation in the batch.

On the metadata question: Processing events are only ever expected to carry the operationId. That status exists purely to signal the job is still running. Fields like weekdate and weekcount only get populated once the job reaches Complete, since that's the first point the full result actually exists. It's not an omission.

This route predates Event Bridge, and it's never been redesigned to fully support it. If you'd find it valuable to always get a notification, regardless of how quickly generation completes, I'd encourage submitting an idea on the Ideas portal so it can be prioritized: https://genesyscloud.ideas.aha.io/ideas

Going forward, you can switch on either the HTTP response code or the status field in the response body, they carry the same information. A 201 (or a "Complete" status) means the work is already done. A 202 (or a "Processing" status) means it's still running, so save the operationId and use it to correlate against the Processing and Complete notifications that follow. Either way, the forecast metadata is what's returned, both in the response and in a Complete notification.

One more thing worth calling out: make sure you're subscribed to the notification topic before sending the generate request, not after. If there's no active subscriber at the moment a notification would go out, it isn't queued or replayed, it's simply not sent.

Hello and thank you for your message,

Here are some additional details:
We use EventBridge to retrieve the events (so no WebSocket, and no subscription channel issues).
I can confirm that the first three forecasts were indeed created.

The forecast generations were done via the UI.

Regarding the events generated with the "Processing" status, they all share the same operationId.

The main concern is the lack of information about which forecast they belong to (date, etc.).
At this point, I think I will only use the events with the "Complete" status (if I receive those events).

Hi @Stéphane Labrune,

I think there are actually two separate points here.

Regarding the events with status = Processing, what you are seeing seems consistent with the asynchronous nature of the forecast generation. At that stage, the operation is still running, so the operationId is mainly there to correlate the notification with the generation request. The actual forecast details are expected to become available when the operation reaches Complete.

The part I am less sure about is why you received notifications only for the fourth forecast. I think we would need a little more information about how the requests and notifications are being handled before concluding that the first three events were not published.

Could you share a few additional details?

• What HTTP status and response body did you receive for each of the four generate requests?

• Did each request return a different operationId?

• Were all four requests made with the same parameters, including forceAsync if you are using it?

• Was the notification subscription already active before the first request?

• Did the WebSocket/channel remain connected during all four executions, or was it recreated/reconnected at some point?

• Are you filtering the incoming notifications by operationId, status, or any other property in your code?

• Are you consuming this topic through the Notifications API/WebSocket or through EventBridge?

It would also be useful to confirm whether the first three forecasts were actually created successfully. That would help separate a forecast generation issue from a notification delivery/consumption issue.

If the forecasts exist but only the last operation produced notifications on your consumer, I would probably start investigating the subscription/channel lifecycle and how the application is processing the messages.

Hope this helps narrow it down a bit. If you can share the request/response samples - with any sensitive information removed - it may be easier to understand what is happening.