[Responsys] Setting timeout to 30 seconds

[seg-leonelsanches]

Some of our customers are facing Timeout errors in their Responsys integration. By default, Centrifuge waits up to 10 seconds for an Action to complete. This integration is taking a much longer time to sync large audiences.

This PR expands the Timeout to 30 seconds, as well as waiting 3 seconds to create a PET (the slowest Responsys endpoint).

Testing

• Added unit tests for new functionality
• Tested end-to-end using the local server
• [If destination is already live] Tested for backward compatibility of destination. Note: New required fields are a breaking change.
• [Segmenters] Tested in the staging environment
• [Segmenters] [If applicable for this change] Tested for regression with Hadron.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.52%. Comparing base (fdcc03e) to head (023eb2b).
Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2693   +/-   ##
=======================================
  Coverage   78.52%   78.52%           
=======================================
  Files        1033     1033           
  Lines       18702    18702           
  Branches     3548     3548           
=======================================
  Hits        14686    14686           
  Misses       2824     2824           
  Partials     1192     1192           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[joe-ayoub-segment]

hi @seg-leonelsanches thanks for the PR.
Are there any other code or configuration changes in any other services which need to be completed before this can be deployed?

[seg-leonelsanches]

hi @seg-leonelsanches thanks for the PR. Are there any other code or configuration changes in any other services which need to be completed before this can be deployed?

Hi @joe-ayoub-segment. No problem.

Centrifuge team deployed the timeout on their end today. We should be good to go with this PR, then.

[marinhero]

@seg-leonelsanches did you test this on stage? Also, can you link to the Centrifuge PR here? Thanks!

[seg-leonelsanches]

@seg-leonelsanches did you test this on stage? Also, can you link to the Centrifuge PR here? Thanks!

Hi @marinhero. This was not tested in Stage. The modification in Centrifuge apparently doesn't have an associated PR.

[marinhero]

Okay. How did we confirm this indeed works then? Another question, why are we reducing the PET time from 6 to 3 seconds if we are mentioning that this is the slowest responsys endpoint? Wouldn't we want to increase the time instead of decreasing?

[marinhero]

Please provide test evidence. Also, would love to have more context on the change and its expected effects specially for the PET wait interval. Thanks!

[seg-leonelsanches]

Another question, why are we reducing the PET time from 6 to 3 seconds if we are mentioning that this is the slowest responsys endpoint? Wouldn't we want to increase the time instead of decreasing?

Six seconds is causing this destination to ETimeout all the events in a particular customer. As no other logs are generated for this error, I'm experimenting with decreasing the wait time for this endpoints, since it is the one that takes most of the execution time.

[seg-leonelsanches]

After deployong in Stage, I was able to test an audience with this destination. However, the ETimeout errors persists. https://app.segment.build/nick-test/destinations/actions-responsys/sources/personas_nick-test-dev/instances/67216bbb86a7770306d97b08/event-delivery?period=past-day