Веб-API эффективно сигнализируют об ошибках, используя коды состояния HTTP, но пакетные задания требуют другого подхода, чтобы их среды выполнения распознавали ошибку. Изначально автор обнаружил существующую функцию Lambda, которая предназначалась для сигнализации об ошибках путем возврата false или объекта status: 500. Однако с точки зрения Lambda эти действия приводили к успешному вызову, предотвращая запись ошибок в CloudWatch. Следовательно, настроенная сигнализация CloudWatch не срабатывала, и уведомление в Slack не отправлялось. Автор понял, что привычный шаблон возврата кода состояния 500, распространенный в веб-API, не применим к пакетным заданиям. Вместо этого, для пакетного задания, весь вызов должен завершиться неудачно, чтобы среда выполнения обнаружила проблему. Чтобы решить эту проблему, обработка ошибок была переработана для выбрасывания исключения, что привело к фактическому сбою вызова Lambda. Этот сбой затем был правильно отражен в метрике ошибок CloudWatch, что позволило сработать сигнализации и отправить уведомление. Опыт показал, что обработка ошибок выходит за рамки самого кода приложения. Она требует обеспечения того, чтобы сбои были обнаруживаемы внешними системами мониторинга и оповещения. Поэтому при рассмотрении обработки ошибок необходимо задать не только вопрос о том, как ошибка обрабатывается внутри, но и о том, как внешние системы будут осведомлены о сбое. Это гарантирует, что механизмы мониторинга и оповещения функционируют должным образом для пакетных процессов.