From QUEUE page, attempts to contact requester fail on Submit.
aesha-CORUS opened this issue · 3 comments
Issue summary
From QUEUE page, attempts to contact requester fail on Submit. (havent tested the other pages since your recent update)
Malformed message
Your message subject or body is missing or exceeds the maximum length. Please revise and try submitting your message again.
Expected behavior
Well.. it should say the request was successful, and send me to Mturks HIT page.
Actual behavior
Error Message:
Malformed message
Your message subject or body is missing or exceeds the maximum length. Please revise and try submitting your message again.
http://prntscr.com/je45tr
I contacted Amazon about this before, and after 2 weeks said they had researched it, and that Mturk Engine was the cause. (I can contact requester successfully from normal Mturk pages)
http://prntscr.com/je46tq
Steps to Reproduce the Problem
- Have a HIT in queue
- Try to contact requester from the drop down menu
- Type in a short test message
- Submit
Specifications
- Mturk Engine version: 1.7.0
- Browser: Version 66.0.3359.139 (Official Build) (64-bit)
Some additional info. Here are the two URLs generated by Mturk, and Mturk Engine, for the same requester and HIT and the QUEUE page:
On the ACCOUNT page, when I lookup a completed HIT, the format is more in line with Mturks.
There are times I really want to complain to a requester about his HIT time lengths, broken content, or other things from the Queue (before it refreshes and disappears). Especially if it expired on me, wouldnt submit after completing, or I was forced to return it for some other reason.
Thanks for the help tracking down this bug @aesha-CORUS. The MTurk website seems to have slightly changed the URL of the page used to contact a requester for a HIT in a user's queue. I've updated the URL Mturk Engine uses and it will ship in the next update, which is hopefully soon. 7ab2f31
The large difference in URLs seems to be caused by the MTurk website using a different encoding standard for its URL's. I've switched the encoding standard Mturk Engine uses as well, since I think the URLs it produces are easier to read, even though MTurk apparently accepts either standard. d41bbd2
This fix just shipped with 1.8.0. Feel free to reopen this issue if it persists after updating.