Doing `throw <myExceptionVariable>` causes the stack trace information
to be rewritten (we don't want this). Wrapping in a new exception object
like `AggregateException` fixes that but also makes the printed
exception look messier.
Instead, simply return a bool to indicate if `HandleException()`
processed the the exception; if not, then we can rethrow from outside
the method.
Old cache directories previously included the instance name in the hash
generation. Code to support migration from this old path has been
removed.
Relates to #202.
Qualities are very high-stakes: They are error prone to modify across
multiple configuration files. The user is not able to control ordering
that way. To reduce the chances of users shooting themselves in the
foot, we only allow 1 file to uniformly set qualities.
Two separate duplicate checks have been introduced:
1. Within the same YAML file, YamlDotNet has been instructed to error on
duplicate keys.
2. Between different YAML files, custom logic enforces that there should
be no duplicate instance names.
This replacement is necessary to support parallelized unit tests.
TestCorrelator as well as even the InMemory sink rely on static objects,
which makes multithreaded tests impossible.
A score set is a collection of scores defined by a single custom format
JSON data file in the TRaSH Guides. Score sets provide a way to define
"themes" for scores that get used across multiple custom formats.
This feature adds the `score_sets` property to the top-level
`quality_profiles` objects.
When unable to connect to a service, we no longer send a confusing
message saying capabilities could not be obtained. This also involved
removing nullability in a few places to simplify logic an error
handling.
This version of `System.IO.Abstractions` adds constructor options to
`MockFileSystem` that allows the removal of a hack put in place to
remove the temp directory so it does not interfere with unit test
expectations.
When qualities are not specified by the user, qualities are not modified
if the profile exists in the service. If the profile does not exist yet,
then an error is shown. Qualities are required when the profile is being
created.
The `qualityprofile` API still performs validation on `cutoff` even when
`upgradeAllowed` is set to `false`. Because of this, we must still set
`cutoff` even if the user didn't specify `upgrade_allowed` and
`until_quality` in their configs. We do so by finding the first item in
the Items list, regardless of what that is. This fixes the HTTP 400 we
get when invoking the API with a `null` value for `cutoff`.
The assignment logic in the DTO objects changes the end result of what
gets synced. The preview and stat logic now first assigns config values
to the old DTO object to get a more accurate preview of what the new
values will be.
Initial implementation with sync support for the following fields:
- Name
- Upgrade Allowed
- Min Format Score
- Cutoff
- Cutoff Format Score
- Items
Quality profiles are always created if they are defined under
`quality_profiles` at the top-level. Within a quality profile
configuration, Recyclarr will not modify quality profile fields if those
corresponding properties in the config are omitted.
Previously, the exception stack trace was omitted to simplify the
console output. However, some situations occurred where an exception was
logged but I couldn't tell where it came from. This made certain rare
bugs impossible to fix.
My philosophy at this point is: If something exceptional happens, we
don't really care about a "clean" console output anymore...
With `delete_old_custom_formats: false` and
`replace_existing_custom_formats: false`, if you comment out a CF in
your configuration, sync, uncomment it and sync again, you get an error
about duplicate CFs. This is because, once a CF is removed from the
configuration, it's also removed from the cache.
This change makes the cache more flexible. As long as a CF (created by
Recyclarr) exists either in the config OR in the service itself, it will
be kept in the cache. This means that temporarily disabling CFs in
configuration won't cause ownership issues.
As long as there's a valid clone available and no other git commands
fail, we allow `git fetch` to fail and proceed processing commands. Even
if internet connectivity is down, that shouldn't necessarily prevent
sync from functioning.
The primary motivation for this change is that we expect the Trash
Guides repo to be relocated soon and I do not want that to cause the
program to stop working between the change and when I can update the
URL.
When doing a `sync --preview`, new custom formats are not created and
thus they never get an ID greater than `0`. Because of this, a
dictionary that tracks duplicates based on ID would result in warnings
about duplicate scores that made no sense.
We now index by Trash ID instead of Format ID, which is more accurate.
Robert Dailey