Closed edwinthinks closed 2 years ago
I'm unable to repro this, even with bundle exec rspec --bisect spec/system/distribution_system_spec.rb
Will attempt to review the examples manually and trace through where the errors might be occurring. @edwinthinks Is this limited to specific environments / situational?
It isn't clear, @armahillo; I've only personally seen it occur in CI.
A side note to your comment, I'am wondering if we want to redesign the test to be not dependent on a file to make this more resilent?
It isn't clear, @armahillo; I've only personally seen it occur in CI.
OK!
A side note to your comment, I'am wondering if we want to redesign the test to be not dependent on a file to make this more resilent?
Yeah that's what I was thinking too
@armahillo I was thinking maybe as a way to side step this issue is to avoid the DistributionPDF class by using the invoice theme - https://adminlte.io/themes/v3/pages/examples/invoice.html that they can print. What do you think?
Oh yeah I am always a fan of <link rel="stylesheet" media="print" type="text/css" src=".../path/to/print.css" />
I would consider this to be a non-trivial, but worthwhile conversion to explore.
One caveat I'd have is that the output becomes more client-dependent, and will require more extensive testing, particularly on non-desktop clients. But I don't think that should be an obstacle large enough to block this.
OK I was able to repro (sort of) by extracting
logo_image = if @organization.logo.attached?
StringIO.open(@organization.logo.download)
else
Organization::DIAPER_APP_LOGO
end
to a private memoizing method and then raising the exception in it:
private
def logo_image
raise Errno::ENOENT
@logo_image ||= if @organization.logo.attached?
StringIO.open(@organization.logo.download)
else
Organization::DIAPER_APP_LOGO
end
end
It's a little louder than it is in CI, but it will work for at least determining that the stubbing I'm about to do addresses the issue.
These tests are ambivalent to the mailer async jobs, so I'm going to stub out those schedule methods. I think this points to a separate issue of responsibilities (like, should ~schedule_reminder_email
~ send_notification
be in the controller or should it be in the service object?) but those are out of scope for this issue.
Attempting to stub it out and seeing if that addresses the issue.
After fixing these two, it's now failing for two different specs (on the :print method)
Is there an existing issue for this?
Current Behavior
We randomly see this spec fail:
Expected Behavior
The specs should always pass or always fail.
Steps To Reproduce
N/A
Environment
Criteria for Completion
Anything else?
There are some options that we could explore which would make this more resilent. Stubbing is an option that may better ensure that this doesn't occur randomly
Code of Conduct