bignum too big to convert into `long' #623

Closed
camelpunch opened this Issue Nov 25, 2011 · 7 comments

Comments

Projects
None yet
2 participants
@camelpunch
Contributor

camelpunch commented Nov 25, 2011

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

This comment has been minimized.

Show comment
Hide comment
@camelpunch

camelpunch Nov 27, 2011

Contributor

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.

Contributor

camelpunch commented Nov 27, 2011

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

This comment has been minimized.

Show comment
Hide comment
@geemus

geemus Nov 27, 2011

Member

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!

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

This comment has been minimized.

Show comment
Hide comment
@camelpunch

camelpunch Nov 28, 2011

Contributor

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?

Contributor

camelpunch commented Nov 28, 2011

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

This comment has been minimized.

Show comment
Hide comment
@geemus

geemus Nov 28, 2011

Member

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?

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

This comment has been minimized.

Show comment
Hide comment
@camelpunch

camelpunch Nov 28, 2011

Contributor

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

Contributor

camelpunch commented Nov 28, 2011

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

This comment has been minimized.

Show comment
Hide comment
@camelpunch

camelpunch Nov 28, 2011

Contributor

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.

Contributor

camelpunch commented Nov 28, 2011

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

This comment has been minimized.

Show comment
Hide comment
@geemus

geemus Nov 28, 2011

Member

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.

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