Released: https://rubygems.org/gems/que-scheduler/versions/3.4.2

Bumps fugit from 1.3.8 to 1.3.9. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/floraison/fugit/blob/master/CHANGELOG.md">fugit's changelog</a>.</em></p> <blockquote> <h2>fugit 1.3.9 released 2020-09-17</h2> <ul> <li>Prevent "New York skip", <a href="https://github-redirect.dependabot.com/floraison/fugit/issues/43">gh-43</a>, thanks <a href="https://github.com/honglooker">@honglooker</a></li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/floraison/fugit/commit/38e727935fe19258ac2b47136770ea75ac5e5bcf"><code>38e7279</code></a> Release 1.3.9</li> <li><a href="https://github.com/floraison/fugit/commit/21be38c716670b5b72466e3401e56030387f50d4"><code>21be38c</code></a> Refine in_active_support_zone spec helper</li> <li><a href="https://github.com/floraison/fugit/commit/6792de1492dbe6ea21eb86523345607782f6630d"><code>6792de1</code></a> Prevent cron skip when not DST transition, <a href="https://github-redirect.dependabot.com/floraison/fugit/issues/43">gh-43</a></li> <li><a href="https://github.com/floraison/fugit/commit/0a06950e29ef7ccc69f9dd49c9c2f72217aa9f24"><code>0a06950</code></a> Complete issue template</li> <li><a href="https://github.com/floraison/fugit/commit/798c037bc1110c07be3bd49bc31dbe3d26a8874c"><code>798c037</code></a> Add initial spec for <a href="https://github-redirect.dependabot.com/floraison/fugit/issues/43">gh-43</a>, just to be sure</li> <li><a href="https://github.com/floraison/fugit/commit/efb7eb7ff39b23e0eb15451764c7caab98de49a0"><code>efb7eb7</code></a> Prepare 1.3.9</li> <li>See full diff in <a href="https://github.com/floraison/fugit/compare/v1.3.8...v1.3.9">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Pull request limits (per update run and/or open at any time)
• Automerge options (never/patch/minor, and dev/runtime dependencies)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

</details>

I'll do a new build later this week.

Hello. We have an Hanami API app that uses Que. Recently we tried to add que-scheduler for running scheduled jobs, but its Que job throws the following error:

gems/que-scheduler-3.4.1/lib/que/scheduler/scheduler_job.rb:64:in `enqueue_self_again': undefined method `beginning_of_minute' for 2020-09-14 16:22:59.13245 +0600:Time (NoMethodError)
    from gems/que-scheduler-3.4.1/lib/que/scheduler/scheduler_job.rb:28:in `block in run'
    from gems/que-scheduler-3.4.1/lib/que/scheduler/db.rb:22:in `block in transaction'
    from gems/que-0.14.3/lib/que.rb:174:in `block in transaction'

I assume the reason is because que-scheduler code uses ActiveSupport core extensions for Time while they were not properly loaded, which is fine for Rails applications (because Rails loads them anyway) but it is likely to break in a non-Rails app.

Versions

  * que (0.14.3)
  * que-scheduler (3.4.1)
  * activesupport (6.0.3.2)

Thanks very much for this...

I will look into removing active_support too! https://github.com/hlascelles/que-scheduler/issues/214

Related to https://github.com/hlascelles/que-scheduler/pull/213, it may be that active_support is only used in a few places and can be removed.

Bumps actionview from 6.0.3.2 to 6.0.3.3. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/rails/rails/releases">actionview's releases</a>.</em></p> <blockquote> <h2>6.0.3.3</h2> <h2>Active Support</h2> <ul> <li>No changes.</li> </ul> <h2>Active Model</h2> <ul> <li>No changes.</li> </ul> <h2>Active Record</h2> <ul> <li>No changes.</li> </ul> <h2>Action View</h2> <ul> <li>[CVE-2020-8185] Fix potential XSS vulnerability in the <code>translate</code>/<code>t</code> helper.</li> </ul> <h2>Action Pack</h2> <ul> <li>No changes.</li> </ul> <h2>Active Job</h2> <ul> <li>No changes.</li> </ul> <h2>Action Mailer</h2> <ul> <li>No changes.</li> </ul> <h2>Action Cable</h2> <ul> <li>No changes.</li> </ul> <h2>Active Storage</h2> <ul> <li>No changes.</li> </ul> <h2>Action Mailbox</h2> <!-- raw HTML omitted --> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/rails/rails/blob/v6.0.3.3/actionview/CHANGELOG.md">actionview's changelog</a>.</em></p> <blockquote> <h2>Rails 6.0.3.3 (September 09, 2020)</h2> <ul> <li> <p>[CVE-2020-8185] Fix potential XSS vulnerability in the <code>translate</code>/<code>t</code> helper.</p> <p><em>Jonathan Hefner</em></p> </li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/rails/rails/commit/070d4afacd3e9721b7e3a4634e4d026b5fa2c32c"><code>070d4af</code></a> v6.0.3.3</li> <li><a href="https://github.com/rails/rails/commit/4ca2027d70ddbab141300e2b8331d2d775c63154"><code>4ca2027</code></a> Fix XSS vulnerability in <code>translate</code> helper</li> <li>See full diff in <a href="https://github.com/rails/rails/compare/v6.0.3.2...v6.0.3.3">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

That looks really good. Would love to give it live try. Will try a local build.

Bumps activerecord from 6.0.3.2 to 6.0.3.3. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/rails/rails/blob/v6.0.3.3/activerecord/CHANGELOG.md">activerecord's changelog</a>.</em></p> <blockquote> <h2>Rails 6.0.3.3 (September 09, 2020)</h2> <ul> <li>No changes.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/rails/rails/commit/070d4afacd3e9721b7e3a4634e4d026b5fa2c32c"><code>070d4af</code></a> v6.0.3.3</li> <li>See full diff in <a href="https://github.com/rails/rails/compare/v6.0.3.2...v6.0.3.3">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Pull request limits (per update run and/or open at any time)
• Automerge options (never/patch/minor, and dev/runtime dependencies)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

</details>

Confirm by changing [ ] to [x] below to ensure that it's a bug:

• [x] I've gone though the User Guide and the API reference
• [x] I've searched for previous similar issues and didn't find any solution

The bug When the ~/.kube/config file is unparsable, aws eks returns unhelpful errors:

aws eks update-kubeconfig --name foo

'name'

The above is the entire output, just the word "name", with exit code 255.

SDK version number

❯ aws --version
aws-cli/2.0.46 Python/3.8.5 Linux/5.4.0-42-generic source/x86_64.linuxmint.20

Platform/OS/Hardware/Device Mint Linux

To Reproduce (observed behavior)

1. Have a corrupt ~/.kube/config
2. Attempt to update it.

My config file was of the form:

❯ cat ~/.kube/config                                                         
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: THECERTBASE64
    server: https://SOMETHING.sk1.eu-west-1.eks.amazonaws.com
  name: arn:aws:eks:eu-west-1:1234567890:cluster/foo
- cluster:
    certificate-authority-data:% 

Expected behavior A better error should indicate the config file is a problem.

Additional context I do not know how the cluster config became corrupted, it has never been edited manually.

To fix the issue, just move the config file and allow it to be recreated by trying again: mv ~/.kube/config ~/.kube/config.bak

It is clear in the documentation that when serializing a T::Struct with values that are nil (or missing), it will yield a Hash where that key is missing altogether.

require 'sorbet-runtime'

class MyTStruct < T::Struct
  const :bar, T.nilable(String)
end

# With T::Struct (and no value) we do not see a `bar` key
obj = MyTStruct.new
obj.serialize # => { }

# With T::Struct (and nil value) we do not see a `bar` key
obj = MyTStruct.new(bar: nil)
obj.serialize # => { }

This behaviour may be a surprise to those who may be expecting T::Struct to work either like a "more principled" Hash, or even like a Struct (which confusingly work differently to each other too).

# With Hash (and no value) we do not see a `bar` key
obj = { }
# => { }
# With Hash (and nil value) we *do* see a `bar` key
obj = { bar: nil }
# => { :bar=>nil }


MyStruct = Struct.new(:bar)
# With Struct (and no value) we *do* see a `bar` key
my_struct = MyStruct.new
my_struct.to_h # => {:bar=>nil}
# With Struct (and nil value) we *do* see a `bar` key
my_struct = MyStruct.new(nil)
my_struct.to_h # => {:bar=>nil}

I can see in the codebase that was done for payload space reasons. Stripe's requirements are almost certainly different to mine, but was it worth introducing a third way for a "structish" object to work for this performance requirement?

Digression: Hash says "if you tell me the value is nil, then I know it is nil and can say so when serialized, otherwise I will not claim to know what it is". ie, no information is lost. Setting something to nil is not the same as "not setting a value to anything". I find the Hash implementation the most sensible if we group all these tools together as "tools providing the same function", which I know they aren't of course.

My main question would be: would you accept a PR to make this behaviour configurable, or at least provide easier access to that part of the code flow so it could be altered by using a mixin? Or are we just using them wrong?

I can well understand that adding this feature to match Hash would require not only holding nil values, but also tracking which values "have been set". We would probably get sufficient benefit for our needs if we changed it to match Struct so we get explicit keys with "defaults of nil".

Great, thank you for the detail. We will add our own :+1:.

We upgraded to Rails 5 and saw an issue using this code*.

class ApplicationController < ActionController::Base
  def index
    RestClient.get("/service", params: params)
  end
end

In Rails 4 the params is_a Hash so it is processed, but in Rails 5 it is a ActionController::Parameters, so it is ignored, as decided by this line of code in RestClient:

        if key.to_s.downcase == 'params' &&
            (value.is_a?(Hash) || value.is_a?(RestClient::ParamsArray))

The silent "loss" of params almost certainly indicates a code problem that should be addressed by the user of RestClient.

Would you accept a PR to either log WARN or raise an error if params cannot be processed?

* There is other code not shown that permits the params, but it does not affect this issue.

It is clear in the documentation that when serializing a T::Struct with values that are nil (or missing), it will yield a Hash where that key is missing altogether.

require 'sorbet-runtime'

class MyTStruct < T::Struct
  const :bar, T.nilable(String)
end

# With T::Struct (and no value) we do not see a `bar` key
obj = MyTStruct.new
obj.serialize # => { }

# With T::Struct (and nil value) we do not see a `bar` key
obj = MyTStruct.new(bar: nil)
obj.serialize # => { }

This behaviour may be a surprise to those who may be expecting T::Struct to work either like a "more principled" Hash, or even like a Struct (which confusingly work differently to each other too).

# With Hash (and no value) we do not see a `bar` key
obj = { }
# => { }
# With Hash (and nil value) we *do* see a `bar` key
obj = { bar: nil }
# => { :bar=>nil }


MyStruct = Struct.new(:bar)
# With Struct (and no value) we *do* see a `bar` key
my_struct = MyStruct.new
my_struct.to_h # => {:bar=>nil}
# With Struct (and nil value) we *do* see a `bar` key
my_struct = MyStruct.new(nil)
my_struct.to_h # => {:bar=>nil}

I can see in the codebase that was done for payload space reasons. Stripe's requirements are almost certainly different to mine, but was it worth introducing a third way for a "structish" object to work for this performance requirement?

Digression: Hash says "if you tell me the value is nil, then I know it is nil and can say so when serialized, otherwise I will not claim to know what it is". ie, no information is lost. Setting something to nil is not the same as "not setting a value to anything". I find the Hash implementation the most sensible if we group all these tools together as "tools providing the same function", which I know they aren't of course.

My main question would be: would you accept a PR to make this behaviour configurable, or at least provide easier access to that part of the code flow so it could be altered by using a mixin? Or are we just using them wrong? I can well understand that adding this feature would require not only holding nil values, but also tracking which values "have been set".

Actually, a much simpler solution - we could add a trigger on the table so that when a row is deleted, and if it has job_class "Que::Scheduler::SchedulerJob", then do a select to check there is another one scheduled.

If there isn't, then it is being deleted in error, and the trigger can raise an exception.

Could you do a section in the README comparing it directly to que?

As I understand it they are both high performance, postgres backed, ruby language async job workers with retries, named queues and the DB ACID guarantees. We've used que for years and it works very well.

It would be great to hear the pros and cons of each!

I know what you mean. I don't have a simple answer to this, as que-scheduler leverages the stability and HA of a distributed task processing system - que itself. There is no way for "itself" to know that it has been deleted, there is no other "process" involved.

I would say something like "no-one should be deleting jobs from your DB if they don't know what they are doing", but I understand mistakes can happen.

I think it probably dovetails with this issue: https://github.com/hlascelles/que-scheduler/issues/161

Once we have a diagnostics command, then it can be added as a healthcheck. Assuming your app also has a healthcheck endpoint like okcomputer then it could be configured to start erroring if the scheduler job is missing / failing. Actually on second thoughts that would make the health check think the service is unhealthy and kill it if you are using autoscaling. Maybe the healthcheck could "autoheal" and enqueue a new scheduler job (though that too could be considered a side-effect of a GET).

Slightly more aggressive ideas could be: whenever an event triggered job happens it could always first check the scheduler. But that might be overkill / use more resources.

Does any of the above sound useful?

In any regard, the command to run in a console to "get it back" is Que::Scheduler::SchedulerJob.enqueue, but that will enqueue 2 if one already exists - but don't worry, it has "duplicate scheduler" checking in place so it won't start double scheduling.

Much of this already exists: https://github.com/hlascelles/que-scheduler/blob/master/lib/que/scheduler/state_checks.rb#L64

It might be nice to expose it as a healthcheck endpoint (that won't error during a deploy).

Bumps fugit from 1.3.6 to 1.3.8. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/floraison/fugit/blob/master/CHANGELOG.md">fugit's changelog</a>.</em></p> <blockquote> <h2>fugit 1.3.8 released 2020-08-06</h2> <ul> <li>Parse 'every day at 8:30' and ' at 8:30 pm', <a href="https://github-redirect.dependabot.com/floraison/fugit/issues/42">gh-42</a></li> </ul> <h2>fugit 1.3.7 released 2020-08-05</h2> <ul> <li>Parse 'every 12 hours at minute 50', <a href="https://github-redirect.dependabot.com/floraison/fugit/issues/41">gh-41</a></li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/floraison/fugit/commit/042cb586ce87e31b252c20a339dc66a09315d3a6"><code>042cb58</code></a> Release 1.3.8</li> <li><a href="https://github.com/floraison/fugit/commit/a7390449f0af6c6959ac688e73349819458a3642"><code>a739044</code></a> Accept "every day at 8:30" and "at 8:30 pm", <a href="https://github-redirect.dependabot.com/floraison/fugit/issues/42">gh-42</a></li> <li><a href="https://github.com/floraison/fugit/commit/6e5140dc1da6e947b1587247cc0f7a9633ca35cd"><code>6e5140d</code></a> Prepare 1.3.8</li> <li><a href="https://github.com/floraison/fugit/commit/153518589b61b95208e6935014f2e39b8c544c27"><code>1535185</code></a> Release 1.3.7</li> <li><a href="https://github.com/floraison/fugit/commit/91b6540f5cdf02da9cdca693f687a88db0734341"><code>91b6540</code></a> Prepare 1.3.7</li> <li><a href="https://github.com/floraison/fugit/commit/d6bd308397537f30912be88bc29868c68f402c58"><code>d6bd308</code></a> Parse 'every 12 hours at minute 50', <a href="https://github-redirect.dependabot.com/floraison/fugit/issues/41">gh-41</a></li> <li><a href="https://github.com/floraison/fugit/commit/e4c99b7511c254a82ba32cb46a7af403feb390e0"><code>e4c99b7</code></a> State dependency status to rufus-scheduler</li> <li>See full diff in <a href="https://github.com/floraison/fugit/compare/v1.3.6...v1.3.8">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Pull request limits (per update run and/or open at any time)
• Automerge options (never/patch/minor, and dev/runtime dependencies)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

</details>

The add_primary_key feature exists but isn't documented. Almost missed it...

@dependabot ignore this dependency

This is still an issue for us. What do people think @pcai @olleolleolle?

Gem 3.4.1 released.

Gem 3.4.1 released.

Hello,

I've been trying to run que-scheduler and I ran into this issue

NoMethodError: The property 'args' is not defined for Que::Scheduler::EnqueuedJobType.

This is following the same instructions on the Readme.

I've tried adding arguments purposely to the jobs and inside que_schedule.yml

I dug into the code and noticed this

 class EnqueuedJobType < Hashie::Dash
      property :args
      property :queue
      property :priority
      property :run_at, required: true
      property :job_class, required: true
      property :job_id, required: true
    end

Args are defined but somehow the scheduler when creating the job, cant seem to add the arguments to the class. Possibly from args: data.fetch(:arguments) (to_enqueue.rb)

The fix I've done was to revert back to 3.2.8 and then everything was working again.

Closed via https://github.com/hlascelles/que-scheduler/pull/205 and https://github.com/hlascelles/que-scheduler/pull/206

Gem 3.4.1 released.

Thank you @Sylphias for the initial report and @redscode for the solution to this issue. It seems that it only occurred when a particular version of Que, and I believe only some versions of Hashie, and only when using Rails.

As @redscode found, when using Que with Rails, the job Que.json_converter is set to :with_indifferent_access.to_proc, but only under version 0.x.

However by 1.x that had been removed. And not using Rails it uses a method called INDIFFERENTIATOR.

Ultimately the best solution is to force using a non-"with_indifferent_access" hash, using symbols, everywhere. This PR builds on https://github.com/hlascelles/que-scheduler/pull/205 by adding a full "Rails loaded" test suite and an additional fix.

As a side note, I now feel Hashie::Dash may not be the most suitable library for handling value objects in this way, so I will do a PR soon to remove it, especially since 3.6.0 the Hashie::Dash class breaks a fundamental hash contract.

Using Hashie::Dash as the value object library doesn't really suit the use case, and since 3.6.0 it breaks a fundamental hash contract.

Using Sorbet Struct might be a good option.

PR with tests for the above created: https://github.com/hlascelles/que-scheduler/pull/206

Hi!

I recently upgraded from v3.2.3 to v3.4.0 with my version of que remaining at v0.14.3 and ran into this issue https://github.com/hlascelles/que-scheduler/issues/175

After doing some digging I discovered that the attrs hash on Que::Job can sometimes have indifferent access as seen below: https://github.com/que-rb/que/blob/45e68691f2599c13b401e2d70cde6f6fbfcac708/lib/que/railtie.rb#L10

transform_keys(&:to_sym) works with no issues, however when this hash is passed to Hashie::Dash through creating a new EnqueuedJobType it dies here: https://github.com/hashie/hashie/blob/b24d6dca2c545637bc3cc3ac4d89f565fc27a9d0/lib/hashie/dash.rb#L199

As looping through the attributes uses the string keys which causes the error on self[att].

This commit will convert the HashWithIndifferentAccess to a standard hash leaving only sym keys at the end of the transform. Whilst being safe to regular hashes.

@dependabot ignore this minor version

Bumps rubocop-rspec from 1.40.0 to 1.41.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/rubocop-hq/rubocop-rspec/releases">rubocop-rspec's releases</a>.</em></p> <blockquote> <h2>RuboCop RSpec v1.41.0</h2> <ul> <li>Extend the list of Rails spec types for <code>RSpec/DescribeClass</code>. (<a href="https://github.com/pirj">@pirj</a>)</li> <li>Fix <code>FactoryBot/AttributeDefinedStatically</code> to allow <code>#traits_for_enum</code> without a block. ([<a href="https://github.com/harrylewis">@harrylewis</a>][])</li> <li>Improve the performance of <code>FactoryBot/AttributeDefinedStatically</code>, <code>RSpec/InstanceVariable</code>, <code>RSpec/LetSetup</code>, <code>RSpec/NestedGroups</code> and <code>RSpec/ReturnFromStub</code>. ([<a href="https://github.com/andrykonchin">@andrykonchin</a>][])</li> </ul> <!-- raw HTML omitted --> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/rubocop-hq/rubocop-rspec/blob/master/CHANGELOG.md">rubocop-rspec's changelog</a>.</em></p> <blockquote> <h2>1.41.0 (2020-07-03)</h2> <ul> <li>Extend the list of Rails spec types for <code>RSpec/DescribeClass</code>. ([<a href="https://github.com/pirj">@pirj</a>][])</li> <li>Fix <code>FactoryBot/AttributeDefinedStatically</code> to allow <code>#traits_for_enum</code> without a block. ([<a href="https://github.com/harrylewis">@harrylewis</a>][])</li> <li>Improve the performance of <code>FactoryBot/AttributeDefinedStatically</code>, <code>RSpec/InstanceVariable</code>, <code>RSpec/LetSetup</code>, <code>RSpec/NestedGroups</code> and <code>RSpec/ReturnFromStub</code>. ([<a href="https://github.com/andrykonchin">@andrykonchin</a>][])</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/rubocop-hq/rubocop-rspec/commit/e6857d8d79f0fade6bfdb238d56f48cc691228e4"><code>e6857d8</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/rubocop-hq/rubocop-rspec/issues/953">#953</a> from rubocop-hq/release</li> <li><a href="https://github.com/rubocop-hq/rubocop-rspec/commit/44e7d6e04932054369706b610affaa1bab22dd46"><code>44e7d6e</code></a> Bump version to v1.41.0</li> <li><a href="https://github.com/rubocop-hq/rubocop-rspec/commit/6e1d698a52bb4f151d46f5e8fe6bd2af4fa75122"><code>6e1d698</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/rubocop-hq/rubocop-rspec/issues/951">#951</a> from andrykonchin/optimize-performance-let-setup</li> <li><a href="https://github.com/rubocop-hq/rubocop-rspec/commit/28eab5afecf9a56995618c578b755a0b21a1425f"><code>28eab5a</code></a> RSpec/LetSetup Optimize #on_block callback</li> <li><a href="https://github.com/rubocop-hq/rubocop-rspec/commit/5551988c51b292a51d94613c4e02a2a7911c7523"><code>5551988</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/rubocop-hq/rubocop-rspec/issues/950">#950</a> from andrykonchin/optimize-performance-nested-groups</li> <li><a href="https://github.com/rubocop-hq/rubocop-rspec/commit/85b0399e3de64ee4b902c74270d35d1baf83e13a"><code>85b0399</code></a> RSpec/NestedGroups Optimize #on_top_level_describe callback</li> <li><a href="https://github.com/rubocop-hq/rubocop-rspec/commit/172dfe8e9c8ebdb3cb0a369429f91173196e8e58"><code>172dfe8</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/rubocop-hq/rubocop-rspec/issues/934">#934</a> from mockdeep/rf-shared_groups</li> <li><a href="https://github.com/rubocop-hq/rubocop-rspec/commit/7e2d6dcca6615977907c15dbd9270462019ceb26"><code>7e2d6dc</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/rubocop-hq/rubocop-rspec/issues/946">#946</a> from andrykonchin/optimize-performance-instance-variable</li> <li><a href="https://github.com/rubocop-hq/rubocop-rspec/commit/c51c544a673109188721a98b58eef1385ed5e775"><code>c51c544</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/rubocop-hq/rubocop-rspec/issues/949">#949</a> from andrykonchin/optimize-performance-attribute_defi...</li> <li><a href="https://github.com/rubocop-hq/rubocop-rspec/commit/87229cc7ec3025f030e5226ec803c35d708d86cc"><code>87229cc</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/rubocop-hq/rubocop-rspec/issues/944">#944</a> from harrylewis/bugfix/add-new-factory-bot-method-to-...</li> <li>Additional commits viewable in <a href="https://github.com/rubocop-hq/rubocop-rspec/compare/v1.40.0...v1.41.0">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Pull request limits (per update run and/or open at any time)
• Automerge options (never/patch/minor, and dev/runtime dependencies)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

</details>

Good sleuthing, thank you for this. I'll formalise a test for it and get it merged as soon as I can.

Add programmatic license information to the file. Based on common practices found on GitHub and the advice by the REUSE project https://reuse.software/tutorial/

:heart:

OK, sorry, yes that does make sense!

However I think the "success" log line ("No api-versioned files found in specified directory.") is what confused me... I will raise another issue for that. Thanks for looking!

Raised as: https://github.com/FairwindsOps/pluto/issues/99

Consider this file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: testapp
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: testapp

It is "up to date" version-wise.

But running pluto on that dir reports "No api-versioned files found in specified directory.".

❯ pluto detect-files -d .
No api-versioned files found in specified directory.

That's not really true. It did find it (can be seen in verbose logs), it is just that the file is compliant. This can lead you to think that your directory path is wrong.

Even running with --show-all reports nothing.

❯ pluto detect-files -d .  --show-all
No api-versioned files found in specified directory.

It is there though. If I change it to an old api version it is found.

❯ pluto detect-files -d .           
NAME      KIND         VERSION        REPLACEMENT   REMOVED   DEPRECATED  
testapp   Deployment   apps/v1beta1   apps/v1       true      true  

The success message should probably indicate files were found and parsed.

Possibly a separate issue... --show-all working as expected?

We are seeing the following on Linux. It appears that pluto is failing to parse simple valid yaml, and is then reporting success.

1. Have a small yaml file:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: testapp
   

2. Run pluto detect-files -d .
3. See that exit code is 0

❯ pluto version
Version:3.1.2 Commit:20f146def8303190c923c5ec592a135b46da1c1a

Running with no logs it seems to claim no files exist, and there were no errors

❯ pluto detect-files -d .      
No api-versioned files found in specified directory.

❯ echo $?
0

Running with logs, we see the errors, and still a zero exit code

❯ pluto detect-files -d . -v 10
I0703 10:24:39.456542    3213 root.go:114] no additional versions needed
I0703 10:24:39.457064    3213 finder.go:95] processing file: test.yml
I0703 10:24:39.457173    3213 versions.go:114] 
apiVersion: v1
kind: ServiceAccount
metadata:
  name: testapp
I0703 10:24:39.457208    3213 versions.go:117] invalid json: invalid character 'a' looking for beginning of value
No api-versioned files found in specified directory.

❯ echo $?
0

I think there are two problems here.

1. pluto is trying to parse yaml files as JSON. The file can end .yaml or .yml, the error is the same.
2. pluto errors, but neither logs this by default, nor reports it as an exit code.

I can sort of see why the latter came about if you have non-k8s files in a dir structure. But for us the problem is that in our CI pluto started "doing nothing" but we never knew.

Can we have "strict mode" (by default!) that errors if it can't understand everything in a folder?

I may be missing a key bit of config here...

Is there a desire for a helm chart for this? Even just a folder in the main repo which can be referred to.

And... has anyone done that work already?

@dependabot ignore this minor version

Bumps activerecord from 6.0.3.1 to 6.0.3.2. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/rails/rails/blob/v6.0.3.2/activerecord/CHANGELOG.md">activerecord's changelog</a>.</em></p> <blockquote> <h2>Rails 6.0.3.2 (June 17, 2020)</h2> <ul> <li>No changes.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/rails/rails/commit/fbe2433be6e052a1acac63c7faf287c52ed3c5ba"><code>fbe2433</code></a> Preparing for 6.0.3.2 release</li> <li>See full diff in <a href="https://github.com/rails/rails/compare/v6.0.3.1...v6.0.3.2">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Pull request limits (per update run and/or open at any time)
• Automerge options (never/patch/minor, and dev/runtime dependencies)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

</details>