Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SQS send returns error code 0 on error #85

Open
nibynool opened this issue Nov 6, 2014 · 5 comments
Open

SQS send returns error code 0 on error #85

nibynool opened this issue Nov 6, 2014 · 5 comments

Comments

@nibynool
Copy link

nibynool commented Nov 6, 2014

Hi again Tim,

Thanks for the speedy help last time, I've found another small issue and once again my lack of Perl skills is letting me down.

I have defined a bash function as follows

function notifyQueue {
    ./aws --silent --simple --region="${REGION}" send-message "${1}" -message "${2}" || { echo $?; echo "{\"error\":\"Could not notify queue\",\"id\":\"${POST_ID}\"}"; exit 1; }
    echo $?
}

This works fine the majority of the time, but every so often I get the following response from your script

+--------+-----------------------+----------------------------------------------------------------------------------+
|  Type  |         Code          |                             Message                                              |
+--------+-----------------------+----------------------------------------------------------------------------------+
| Sender | SignatureDoesNotMatch | The request signature we calculated does not match the signature you provided... |
+--------+-----------------------+----------------------------------------------------------------------------------+

When this happens I still get an error code of 0 returned.

I've noticed that in your documentation is is mentioned that you don't always return a non-0 value on error, but can you give me some pointers as to where I would need to detect this to get a non-0 value.

My use case is that after processing a message I need to send a message to a second queue, when that message fails I don't want to delete the current working message.

Thanks again.

@nibynool
Copy link
Author

nibynool commented Nov 6, 2014

Ok, I think I found the issue :)

Starting at line 2520 you have the following code:

    else
    {
    # If there is an error response and we haven't yet set an error return, do it now
    if ( $result =~ /<ErrorResponse/ && !$ExitCode)
    {
        $ExitCode = 1;
    }

    print xml2tab($result) || xmlpp($result);
    }

    exit $exit_code;

I think the references to $ExitCode should in fact be $exit_code

@timkay
Copy link
Owner

timkay commented Nov 7, 2014

Is your point that the $ExitCode variable is not used? This code was added by a merge request from another user, related to RDS.

Why do you think that code relates to the error message you occasionally see?

@nibynool
Copy link
Author

nibynool commented Nov 7, 2014

Hi Tim, sorry if I wasn't clear.

It doesn't relate to the cause of the error, but does relate to the reporting of the error in the script's exit code. I tried changing the two $ExitCode occurrences to $exit_code (which appears 10 times in the code) and the script now returns an error code of 1 when there is an error response from AWS.

@nibynool
Copy link
Author

nibynool commented Nov 7, 2014

As a side note, I think the cause of the error is something I'm doing, because it consistently happens on one particular message.... Debugging the cause is 100% my problem though :)

@timkay
Copy link
Owner

timkay commented Nov 7, 2014

It is possible that there is a bug in the signing code, even though the code has been used by a zillion people for many years. This sort of issue has been reported very infrequently, and I haven't been able to reproduce it. If there is such a bug, it depends on specific keys. People are usually unwilling to share their keys with me for obvious reasons. I suggest the following work around: Using IAM, create a new set of keys that have the permissions you need to access SQS. If you are able to reproduce the issue, then you could update the keys have access to a specific test queue and then share the credentials with me (via [email protected], not via github). At that point, I could take a look. It is also possible that the new keys do not exhibit the faulty behavior, in which case you have your work around.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants