📝 Verdict — PARTIAL
The core request/response feature works end-to-end: a deployed HTTP Endpoint returns 200 with a request-derived body and application/json; wrong method → 405; body > 1 MB → 413; and the X-Request-Id idempotency layer returns a cached response on match and 422 on mismatch. Fire-and-forget keeps its legacy behaviour (immediate 200, empty body) and is long-lived.
After dev triage: the “single-use endpoint” behaviour is by design (not a bug) — you poll while the branch is executing, before it reaches Return. Three bugs stand: ContentType input missing (Major), 503 on idempotent replay (Minor), and the package-icon 404 (Minor). Several apparent designer “failures” were also confirmed by-design. The response-body and request $input shapes are slated to change alongside the ContentType fix.
Bugs to raise (3)
🟡 Minor — 503 on idempotent replay of a failed X-Request-Id
From the E2E run (TC4). Replaying an X-Request-Id whose first attempt didn’t complete returns 503 Service Unavailable. The dev confirmed 410 Gone is intended here but 503 is not. Filed as ENG-5117-BUG3.
🟠 Major — ContentType input missing from the HTTP Endpoint activity
From TC1. No ContentType control exists on the activity in any Mode — the response Content-Type can’t be configured. Confirmed by the dev: it existed, was removed when planning to relocate it, and was not re-added. Filed as ENG-5117-BUG2.
🟡 Minor — HTTP Endpoint package icon 404
From TC1 regression. assets/shared-ui/icons/designer-packages/http.svg returns 404; the activity falls back to the default icon. Filed as ENG-5117-BUG1.
TC1 — Verify HTTP Endpoint Activity Inputs in Designer
Overall: PARTIAL — 9 pass / 4 fail / 4 blocked (verdicts are build-vs-test-case; several “fails” are test-case errors — see Not-bugs)
| Area | Result | Detail |
|---|---|---|
| Drag onto canvas + node renders | PASS | HTTP Endpoint adds with ports On Created / On Request Received |
| Inputs present (Method, ContentType, Mode) | FAIL | Only Methods + Mode present; no ContentType (BUG2) |
| Mode options | FAIL vs TC | Three options (Fire and forget default, Sync, Async) — by design (backwards compat) |
| Set Mode Sync/Async; Methods POST/GET | PASS | Accepted; Methods is a multi-select (POST/GET/PUT/PATCH/DELETE) |
| Save + reload persistence | PASS | Methods & Mode persisted across save + reload |
| Return response-value input | FAIL vs TC | No body property — response body is the value wired into Return ($input), by design |
| ContentType steps | BLOCKED | No ContentType input to set (BUG2) |
E2E — TC2 / TC4 / TC5 (deployed via GraphQL)
The GoJS canvas can’t be wired by automation, so probe workflows were authored as SerializedDefinition JSON and deployed via the admin GraphQL API (workflowCreate → draftSave → installationDeploy). The endpoint URL is minted per endpoint and surfaced only via $scope.endpoint.url in the On Created branch. URL scheme: https://api.automate.<env>.sense.engineering/package/http/endpoint/<token> (public API host, not behind Basic Auth).
TC2 — Synchronous mode
| Check | Result | Evidence |
|---|---|---|
| POST valid JSON → 200, request-derived body, Content-Type | PASS | HTTP 200, ~0.5–1.5s, application/json, body echoes the sent payload |
| Wrong method (GET) → 405 | PASS | GET → 405 |
| Body > 1 MB → rejected | PASS | 1.3 MB → 413 (no run created) |
| Subsequent requests after the first | FAIL | Instance completes after 1 request → 410/503 (High finding) |
| Sync 5-min timeout | NOT RUN | Needs a 5-minute wait; deferred |
TC4 — Idempotency (X-Request-Id)
| Check | Result | Evidence |
|---|---|---|
| Same id + same body → cached 200, no re-exec | PASS | Replay returned byte-identical 200 (0.17s, from the grain) |
| Same id + different body → 422 | PASS | ExistsMismatch → 422 |
TC5 — Fire-and-forget (backwards compatibility)
| Check | Result | Evidence |
|---|---|---|
| POST → immediate 200, empty body | PASS | HTTP 200, Content-Length: 0, ~0.2s |
| Endpoint handles multiple requests | PASS | Two POSTs both 200; instance stayed Executing and logged both |
Single-use endpoint — resolved (by design)
Observed: the Sync probe instance went Executing → Completed after one request; further requests got 410 Gone / 503. The fire-and-forget probe (no Return) stayed Executing and served many — isolating the cause to Return ending the instance.
Dev triage: by design. A request is served while its branch executes; you poll while the branch is executing, before it reaches Return. 410 Gone is intended; only the 503 on replay is a defect (filed as ENG-5117-BUG3). The response-body shape and the request $input shape (→ { body, headers }) are slated to change alongside the ContentType fix.
Confirmed not-bugs (by design — per dev)
- Mode has 3 options (Fire and forget / Sync / Async, default Fire and forget) — intentional, kept for backwards compatibility.
- Return has no body field — the response body is the value wired into Return (
$input). - HTTP Endpoint is under Actions, not Triggers — correct; it is not a trigger (it creates an endpoint within a running instance).
- “Methods” is a multi-select defaulting to POST — intentional.
The 7 test cases were updated to match this confirmed design.
Screenshot Gallery
Deferred / not run
Need multi-minute / 1-hour waits or an async-polling harness: TC2 sync 5-minute timeout, TC3 async (202 + Location polling + 1-hour TTL), TC6 fault paths, TC7 missing/partial Return. Two probe workflows were left deployed in the Dev New org (QA ENG-5117 E2E Sync, QA ENG-5117 E2E FireForget).