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

bignum too big to convert into `long' #623

Closed
camelpunch opened this issue Nov 25, 2011 · 7 comments · Fixed by #625
Closed

bignum too big to convert into `long' #623

camelpunch opened this issue Nov 25, 2011 · 7 comments · Fixed by #625

Comments

@camelpunch
Copy link
Contributor

Hi there,

On a 32-bit REE system, when I receive a message with AWS::SQS, I get the aforementioned exception. It's choking when trying to convert timestamps to Time objects.

In my particular case, the @value variable had this string in it: "1322229918740".

Will try to submit a test case / patch shortly.

@camelpunch
Copy link
Contributor Author

Update on progress: I've configured a branch on my fork for Vagrant, to allow us to easily test this in a 32-bit environment.

I'm having difficulty understanding how to write a Shindo test to reproduce this bug, but could do it in RSpec if that's alright? Would rather be consistent with your tests, however.

@geemus
Copy link
Member

geemus commented Nov 27, 2011

I don't want you to get stuck on that. Feel free to write it in rspec and I can always convert it later. Alternatively if you have questions about doing it in shindo that I could clear up I would be happy to help. Thanks!

@camelpunch
Copy link
Contributor Author

I've found the bug: you need to divide the timestamp returned by Amazon by 1000.0 before sending it to Time.at. From the official SDK: https://github.com/amazonwebservices/aws-sdk-for-ruby/blob/master/lib/aws/sqs/received_message.rb#L157

The AWS API documentation doesn't seem to mention this.

There doesn't seem to be any assertion that checks the correctness of the returned timestamps for SQS messages. Would this be easy to put into Shindo? The only examples I can see are assertions on the types of values returned. Maybe I'm missing something?

@geemus
Copy link
Member

geemus commented Nov 28, 2011

Gross. Would be good to get that fix in, its unfortunate that it is required though.

The assertions that are there are all about type and are mostly aimed at ensuring that mocked output is accurate. As a side effect they tend also to show when things from the remote side have changed, but this isn't the main goal.

When you say "checks the correctness" I'm not certain what you mean though, could you clarify?

@camelpunch
Copy link
Contributor Author

Ah - the AWS docs do mention this: they say the timestamp is in milliseconds, not seconds: http://docs.amazonwebservices.com/AWSSimpleQueueService/latest/APIReference/index.html?Query_QueryReceiveMessage.html

@camelpunch
Copy link
Contributor Author

By checking the correctness, I mean that we should have a test that checks the timestamps are converted from milliseconds-since-epoch to the correct time as Time objects. Presently, times are waaay too far into the future. For example, my SentTimestamp above converts to Tue Oct 19 00:32:20 +0000 43869, where it should be Fri Nov 25 14:05:18 +0000 2011.

@geemus
Copy link
Member

geemus commented Nov 28, 2011

ah, yes, that would be good. Feel free to add those (and the other) tests as rspec if you feel more comfortable with that. I can help convert them once the groundwork is in place.

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