-
Notifications
You must be signed in to change notification settings - Fork 26
Description
I have been experiencing issues where ServicePulse is not retrying messages. This was occurring with both ServicePulse 1.2.1/ServiceControl 1.6.3 and now ServicePulse 1.3.0/ServiceControl 1.7.1.
The steps to reproduce are simple:
- Select an error group
- Select a message
- Click "Retry 1 message"
Actual: The page redirects back to the list of Error Groups (no confirmation/warning/error messages are seen). From looking at the journal queue, I can clearly see that no attempts were made to retry the message. The error message remains visible in ServicePulse with no indication that a retry was attempted.
Expected: The message should have been retried and should have appeared in the journal queue.
HTTP Request Headers
POST /api//errors/retry HTTP/1.1
Host: localhost:33333
Connection: keep-alive
Content-Length: 40
Accept: application/json, text/plain, /
Origin: http://localhost:9090
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
Content-Type: application/json;charset=UTF-8
Referer: http://localhost:9090/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
HTTP Request Body
["d50331f8-4bfa-24de-5e7a-cf9969195f5c"]
HTTP Response Headers
HTTP/1.1 202 Accepted
Cache-Control: private, max-age=0
Transfer-Encoding: chunked
Content-Type: text/html
Server: Microsoft-HTTPAPI/2.0
X-Particular-Version: 1.7.1
Access-Control-Expose-Headers: ETag, Last-Modified, Link, Total-Count, X-Particular-Version
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Methods: POST, GET, PUT, DELETE, OPTIONS, PATCH
Access-Control-Allow-Origin: *
Date: Thu, 29 Oct 2015 16:24:05 GMT
The request URL looks suspicious to me -- api//errors/retry has a double forward slash, maybe that is causing the problem?