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

JRuby 9k fails cuke tests where the output contain non-English characters #417

Closed
wants to merge 1 commit into from

Conversation

stamhankar999
Copy link
Contributor

Summary

JRuby 9.0.5.0 fails cuke tests where the output contain non-English characters.

Details

I tracked this down to an encoding error reported in childprocess when pumping data from the invoked command to the stdout tempfile. My fix is to set the stdout and stderr output files to be in binmode, and then the string matchers for the output declare that the actual result (read from the tempfiles as binary data) is actually UTF-8. This causes no harm in old JRuby or MRI afaict; my cuke tests for my application pass with this fix in place just like they passed before.

Motivation and Context

Cuke tests for the DataStax Ruby driver failed against jruby 9k, a platform we are trying to support now.

How Has This Been Tested?

Sorry, don't have aruba tests. :(

The cuke test that failed (there are several that failed the same way, but I focused on this one): https://github.com/datastax/ruby-driver/blob/master/features/asynchronous_io/executing_queries.feature#L45-L62

The error occurred in the "When it is executed" part:
https://datastax-oss.atlassian.net/browse/RUBY-163

Fixing SpawnProcess.start got past this error, but the "Then" clause started failing with an encoding error. I introduced the force_encoding of actual results in relevant functions to fix that.

I did test that my cuke tests pass on MRI 2.3 and JRuby 1.7.x with these changes, so it doesn't seem like I introduced a regression.

Screenshots (if appropriate):

Types of changes

  • [X ] Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • [ ?] Breaking change (fix or feature that would cause existing functionality to not work as expected)
    I'm not sure if this will break anyone. Changing those matchers to assume 'actual' is utf-8 might be overzealous.

Checklist:

  • I've added tests for my code
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.

…s non-ASCII characters. I tracked this down to an encoding error reported in childprocess when pumping data from the invoked command to the stdout tempfile. My fix is to set the stdout and stderr output files to be in binmode, and then the string matchers for the output declare that the actual result (read from the tempfiles as binary data) is actually UTF-8. This causes no harm in old JRuby or MRI afaict; my cuke tests for my application pass with this fix in place just like they passed before.
@stamhankar999
Copy link
Contributor Author

FYI, I'm running aruba 0.13.0, but I tried upgrading to a newer aruba before digging deep into this and my cukes failed then, too.

@mvz mvz mentioned this pull request Jun 25, 2017
@maxmeyer
Copy link
Member

maxmeyer commented Jul 4, 2017

@enkessler This might help a bit. This seems to be related to the encoding issue.

@maxmeyer
Copy link
Member

maxmeyer commented Jul 4, 2017

@stamhankar999 Sorry for the very late reply. If #434 is finished can you please rebase?

@maxmeyer maxmeyer closed this in 501bbdc Jul 26, 2017
@maxmeyer maxmeyer added this to the 1.0.0-alpha.3 milestone Jul 26, 2017
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

Successfully merging this pull request may close these issues.

2 participants