In 3b698e1 I added the YarnError exception handler and tested it
against get_job_status only. The other four YARN-touching tools
(get_external_job_status, get_external_job_result,
get_external_job_logs, list_applications) were assumed to be
covered by the same handler but never actually exercised against a
YarnError.
Add one integration test per remaining tool. Each one:
- saves a Connection
- mocks the underlying yarn_client symbol the tool uses
(get_application_status / get_application_logs /
list_applications_yarn) to raise YarnError with a distinctive
message
- hits the tool's route via TestClient
- asserts HTTP 502 + the YarnError message in the response detail
The new tests prove the YarnError -> 502 contract holds uniformly:
- test_external_job_status_returns_502_on_yarn_error
(get_application_status raising "not found")
- test_external_job_result_returns_502_on_yarn_error
(get_application_status raising "Connection refused")
- test_external_job_logs_returns_502_on_yarn_error
(get_application_logs raising "HTTP 500 cluster overloaded")
- test_list_applications_returns_502_on_yarn_error
(list_applications_yarn raising "HTTP 503")
Each one uses a different YARN exception message so the test
distinguishes which code path produced the error. Combined with
the existing get_job_status test, the YarnError -> 502 contract
is now verified end-to-end for all five YARN REST-call sites.
Tests: 405 passed (was 401, +4 net).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
