System Response After a Map/Reduce Interruption
A map/reduce script can be interrupted at any time. For example, a disruption to the application server immediately stops the script’s execution. Additionally, an uncaught error, although it does not cause the script to stop executing, stops the current function invocation, even if it is not complete.
For more details, review the following sections:
Regardless of how your script is configured, you should make sure that it includes logic that checks to see whether a restart has occurred. If the function has been restarted, the script should take any actions needed to avoid unwanted duplicate processing. For details, see Adding Logic to Handle Map/Reduce Restarts.
System Response After an Application-Server Disruption
An application disruption can occur because of a NetSuite update, NetSuite maintenance, or an unexpected failure of the execution environment. When the application server is disrupted in this way, the script stops executing. After the application server restarts, the script also restarts, resuming the same stage that it was in process when the script was interrupted.
When an application server restart interrupts the map or reduce stage, the system writes the SSS_APP_SERVER_RESTART error code to the relevant iterators. This error code is shown alongside the codes recorded for any uncaught errors that were thrown.
For more details, see the following table.
Stage where interruption occurred |
Script behavior |
SSS_APP_SERVER_RESTART error code written to |
---|---|---|
Get Input Data |
When the disruption occurs, the script stops executing. After the application server restarts, the system restarts the function. |
— |
Map |
When the disruption occurs, the script stops executing. Any data that was saved during the previous invocation by using the context.write() method is discarded. Afterward, the response is as follows:
|
|
Reduce |
|
|
Summarize |
When the disruption occurs, the entire script stops executing. After the application server restarts, the system restarts the function. |
— |
System Response After an Uncaught Error
An error that is not caught in a try-catch block does not necessarily end the execution of a map/reduce script, but the error can disrupt the script’s work. Some aspects of this behavior are configurable. For details, see the following table.
Stage where error occurred |
Script behavior |
Errors written to |
---|---|---|
Get Input Data |
The script ends the function invocation and exits the stage. It proceeds directly to the summarize stage. This behavior cannot be configured. |
|
Map |
When the error occurs, the function invocation ends, even if its work is not complete. Any data that was saved during the invocation by using the context.write() method is discarded. Afterward, the system responds as follows:
|
|
Reduce |
|
|
Summarize |
The script stops executing. This behavior cannot be configured. |
— |
This table describes the behavior for the majority of errors, but a few errors result in different behavior. For example, if one of the jobs being processed in the map or reduce stage fails on SSS_USAGE_LIMIT_EXCEEDED, other jobs in Processing status are normally finished and their executions are not interrupted, but jobs in Pending status are canceled immediately. For details, see Hard Limits on Total Persisted Data.