Add top level errors conforming to http codes#86
Conversation
There was a problem hiding this comment.
Pull request overview
Adds top-level sentinel errors representing key HTTP status classes to make client-side diagnosis of 400/401/404 responses easier.
Changes:
- Introduces new exported sentinel errors for HTTP 400/401/404.
- Wraps actions-exception-derived errors with a status-based top-level error.
- Adds
wrapResponseErrorTypehelper to apply status-to-sentinel mapping.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| RunnerExistsError = scalesetError("runner exists") | ||
| JobStillRunningError = scalesetError("job still running") | ||
| MessageQueueTokenExpiredError = scalesetError("message queue token expired") | ||
| // Top level errors carying the http status code meanings. |
There was a problem hiding this comment.
Typo/grammar in the new comment: "carying" -> "carrying", and "http" should be "HTTP" (also consider "Top-level").
| // Top level errors carying the http status code meanings. | |
| // Top-level errors carrying the HTTP status code meanings. |
| BadRequest = scalesetError("bad request") | ||
| NotFound = scalesetError("not found") | ||
| Unauthorized = scalesetError("unauthorized") |
There was a problem hiding this comment.
New exported sentinel errors are named inconsistently with the existing *Error pattern in this file (RunnerNotFoundError, RunnerExistsError, etc.). Consider renaming these to BadRequestError, NotFoundError, and UnauthorizedError (or another consistent suffix) to avoid ambiguous/generic exported identifiers like NotFound.
| case strings.Contains(exception.ExceptionName, "AgentExistsException"): | ||
| return fmt.Errorf("%s: %w: %s", sb.String(), RunnerExistsError, exception.Message) | ||
| return wrapResponseErrorType(resp, fmt.Errorf("%s: %w: %s", sb.String(), RunnerExistsError, exception.Message)) | ||
| case strings.Contains(exception.ExceptionName, "AgentNotFoundException"): | ||
| return fmt.Errorf("%s: %w: %s", sb.String(), RunnerNotFoundError, exception.Message) | ||
| return wrapResponseErrorType(resp, fmt.Errorf("%s: %w: %s", sb.String(), RunnerNotFoundError, exception.Message)) | ||
| case strings.Contains(exception.ExceptionName, "JobStillRunningException"): | ||
| return fmt.Errorf("%s: %w: %s", sb.String(), JobStillRunningError, exception.Message) | ||
| return wrapResponseErrorType(resp, fmt.Errorf("%s: %w: %s", sb.String(), JobStillRunningError, exception.Message)) | ||
| default: | ||
| return fmt.Errorf("%s: %w: %w", sb.String(), err, exception) | ||
| return wrapResponseErrorType(resp, fmt.Errorf("%s: %w: %w", sb.String(), err, exception)) |
There was a problem hiding this comment.
wrapResponseErrorType is only applied in the JSON actions-exception branch. Other newRequestResponseError return paths for the same HTTP responses (e.g., text/plain bodies, empty bodies, read failures, JSON unmarshal failures) will not get the new top-level HTTP status sentinel errors, which seems to undercut the stated goal of diagnosing 400/401/404 via status-based errors. Consider wrapping those earlier returns too (or restructuring to build the error first and apply wrapResponseErrorType once before returning).
| func wrapResponseErrorType(resp *http.Response, err error) error { | ||
| switch resp.StatusCode { | ||
| case http.StatusBadRequest: | ||
| return fmt.Errorf("%w: %w", BadRequest, err) | ||
| case http.StatusUnauthorized: | ||
| return fmt.Errorf("%w: %w", Unauthorized, err) | ||
| case http.StatusNotFound: | ||
| return fmt.Errorf("%w: %w", NotFound, err) | ||
| default: | ||
| return err | ||
| } |
There was a problem hiding this comment.
The new status-to-sentinel mapping in wrapResponseErrorType isn’t covered by tests. Since this repo already has comprehensive unit tests for newRequestResponseError in errors_test.go, please add assertions that 400/401/404 responses produce errors where errors.Is(err, BadRequest/Unauthorized/NotFound) is true (including at least one case for each status).
This PR can help diagnose bad requests, or not found responses, allowing easier inspection of misconfigurations, since status codes carry useful pieces of information.