I'm working on a standardized error reporting interface
(https://github.com/rails/rails/issues/43472) and it has the same need
for a `context` than Active Record's query logs.
Just like query logs, when reporting an error you want to know what the
current controller or job is, etc.
So by extracting it we can allow both API to use the same store.
Error messages from assert_enqueued_with and assert_performed_with
shows which other jobs are enqueued or performed when you get an
error. We can improve these messages to make it clearer why the job
didn't match. This one error messages now have three different formats
based on why the job didn't match
1. Didn't match because no jobs are queued at all. This now reports,
```
No performed job found with {:job=>HelloJob, :args=>[]}
No jobs where performed
```
2. Didn't match because that job class was not queued. This now reports,
```
No performed job found with {:job=>MultipleKwargsJob, :args=>[#<Person:0x00007fe38f9f8100 @id=11>]}
No jobs of class MultipleKwargsJob where performed, job classes performed: HelloJob
```
3. Doesn't match due to arguments, queue, priority or other reason. This now reports
```
No performed job found with {:job=>HelloJob, :args=>[#<Person:0x00007fe3a89fc2c8 @id=11>]}
Potential matches: {"job_class"=>"HelloJob", "job_id"=>"f8636fd9-c7a0-4565-9198-17e175f30f0e", "provider_job_id"=>nil, "queue_name"=>"default", "priority"=>nil, "arguments"=>[{"_aj_globalid"=>"gid://aj/Person/9"}], "executions"=>0, "exception_executions"=>{}, "locale"=>"en", "timezone"=>nil, "enqueued_at"=>"2021-10-27T23:19:54Z", :job=>HelloJob, :args=>[#<Person:0x00007fe3a89dce00 @id="9">], :queue=>"default", :priority=>nil}
```
Which matches the old error message, but only reports jobs that where
queued of the same class as the job you are asserting was queued.
This remove the null object as discussed in
8af78700d2.
Since it pretends to be nil but acts as thruthy in boolean context
it cause more confusion than it clean code.
`update_context` is removed in favor of `set_context` without
a block.
The ModuleSerializer does not support serializing anonymous classes
because when we try to deserialize the anonymous class, it wouldn't
know which class to use (since class name is nil).
For this reason, ModuleSerialzier now raises an error if the class
name is nil. Previously, ModuleSerializer would raise an `undefined
method `constantize' for nil:NilClass` error during deserialization.
It's not clear why the deserialization failed from the error.
In this commit, we raise an explicit error when trying to serialize
an anonymous class indicating this behaviour is not supported.
This commit restores the test deleted in
cd22ecbfc2
Active Job should not test things about autoloading, this would
belong to the railties test suite probably. However, there, it feels
a bit too distant from here.
Imperfect, but on a second thought I believe this trade-off is better.
I found an unexpected use of assertion in the block of `assert_raise`
when I implemented https://github.com/rubocop/rubocop-minitest/pull/137.
It is expected to be asserted after an exception is raised in
`assert_raise` block, but in actually it is not asserted after an
exception is raised. Therefore, this PR removes or updates assertions
that have not been asserted after an exception has raised.
This PR will add `rubocop-minitest` and enable
`Minitest/UnreachableAssertion` cop to able similar auto-detection,
but will remove `rubocop-minitest` from this PR if you don't like it.
* Remove spring as a default installation option
Faster computers have meant that most apps won't see a big benefit from Spring on small to moderate size apps. Thus the pain of dealing with the occasional spring issue is no longer warranted by default.
* Errant end
* No longer an option
* Additional spring removals
* Pointer to docs is enough
AJ infers adapater class names, and loads them. How are those classes made
available to AJ is a user's concern.
Perhaps they loaded the adapter with require, perhaps they have the class in the
autoload_once_paths. It does not matter, it is the user responsibility to make
the class available _somehow_, and AJ can assume that.
In some applications, some classes of errors may be raised during the
execution of a job which the developer would want to retry forever.
These classes of errors would most likely be infrastructure problems that
the developer knows will be resolved eventually but may take a variable
amount of time or errors where due to application business logic, there
could be something temporarily blocking the job from executing, like a
resource that is needed for the job being locked for a lengthy amount of
time.
While an arbitrarily large number of attempts could previously be passed,
this is inexpressive as sometimes the developer may just need the job to
continue to be retried until it eventually succeeds. Without this,
developers would need to include additional code to handle the situation
where the job eventually fails its attempts limit and has to be re-enqueued
manually.
As with many things this should be used with caution and only for errors
that the developer knows will definitely eventually be resolved, allowing
the job to continue.
[Daniel Morton + Rafael Mendonça França]
Follow up to https://github.com/rails/rails/pull/37313
- Adds regression tests
- Logs a warning in cases where assertions are nested in a way that's likely to be confusing
RDoc Markup does not support backticks the way Markdown does to mark up
inline code. Additionally, `<tt>` must be used to mark up inline code
that includes spaces or certain punctuation characters (e.g. quotes).
Rafael Mendonça França