[Fetch Migration] Suppress exit code for graceful termination (SIGTERM)

[kartg]

Description

The orchestrator now suppresses exit code 143 (graceful termination following a SIGTERM) if it is returned by the migration monitor, since this is a result of a workaround for opensearch-project/data-prepper#3141

Unit tests have been added to cover this scenario. This change also ensures that a return_code is always returned by the function, and updates some stale comments.

• Category: Bug fix

Testing

Unit test coverage:

$ python -m coverage report --omit "*/tests/*"
Name                           Stmts   Miss  Cover
--------------------------------------------------
endpoint_info.py                  24      0   100%
endpoint_utils.py                106      1    99%
fetch_orchestrator.py             76      0   100%
fetch_orchestrator_params.py      22      0   100%
index_diff.py                     20      0   100%
index_doc_count.py                 5      0   100%
index_operations.py               76      0   100%
metadata_migration.py             65      0   100%
metadata_migration_params.py       7      0   100%
metadata_migration_result.py       5      0   100%
migration_monitor.py              90      0   100%
migration_monitor_params.py        6      0   100%
progress_metrics.py               91      0   100%
utils.py                          13      0   100%
--------------------------------------------------
TOTAL                            606      1    99%

Check List

• New functionality includes testing
  • All tests pass, including unit test, integration test and doctest
• New functionality has been documented
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (eacec89) 73.55% compared to head (0bce309) 73.76%.

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #478      +/-   ##
============================================
+ Coverage     73.55%   73.76%   +0.20%     
+ Complexity     1182     1180       -2     
============================================
  Files           124      124              
  Lines          4886     4886              
  Branches        439      439              
============================================
+ Hits           3594     3604      +10     
+ Misses          998      988      -10     
  Partials        294      294              

Flag	Coverage Δ
unittests	73.76% <ø> (+0.20%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[gregschohn]

Is there an integ test in place that runs DataPrepper and confirms that the error code and this codebase works as expected? If so, LGTM. If not, it would be really nice to have that to ensure that we'll know when DataPrepper changes and we need to make an update.

[gregschohn]

A citation to the DataPrepper code (github) showing where/why it returns 143 would be great. 143 seems like it could be a fragile number to pin on. This should also be a constant to document it a bit more.
I guess DataPrepper can also just run in "one-off" mode where it exits after a task is done (and then exits with code 0)?

[kartg]

143 is the standard exit code for a SIGTERM signal to indicate a graceful shutdown of the process. This behavior isn't managed by Data Prepper but rather by the JVM.

I wasn't able to find any system libraries in Python that have this declared as a constant. IMO a test case isn't needed for this behavior since it is the expected behavior for any Linux process. Let me know if you disagree?