#*arr sync failure without resolution.

46 messages · Page 1 of 1 (latest)

quartz stone
#

I posted a bug on the github, but a bot auto closed it and said to report it here, which is an interesting choice for bug tracking.

In the attached image there is a request that seerr knows is NOT on either radarr or sonarr - why it didn't make it to the *arr is unknown but this happens. What I consider the problem is when the *arr sync happens it should add the request (because it knows it isn't on the arr as shown by the image)

keen sparrow
#

Its not a bug.

#

Bugs are things reproducible and messed up on the app so it affects everyone. None of us can recreate it. There are several thousand users with seerr using it normally without facing this. Its vry likely that its your specific instance related.

#

I need logs

#

Not screenshots.

#

Need your full logs of when you request so I can see the issue.

quartz stone
#

https://github.com/seerr-team/seerr/issues/2664

I updated the original issue with what appears to be happening.
In short - if tags are enabled and there is some reason the retrieval fails from the arr then seerr doesn't update the item to FAILED, so the UI doesn't alert the user nor do you get a retry button like you would for other failure scenarios. Which is a silent (to the user) failure to add to the arr.

GitHub

Description In the event a request doesn't properly add to an *arr Seerr knows it isn't added, but does nothing about it. Version 3.1 Steps to Reproduce A sync fails for some unknown reason...

wanton hatch
quartz stone
#

catch the error and proceed with the remainder of the functions
workaround is disable tags

#

try {
if (radarrSettings.tagRequests) {
const radarrTags = await radarr.getTags();
...
}
} catch (tagError) {
logger.warn('Could not fetch tags, proceeding without', {
label: 'Media Request',
requestId: entity.id,
errorMessage: tagError.message,
});
}

something like that

wanton hatch
quartz stone
#

look at the issue I reported on git hub

#

it spells it out

keen sparrow
quartz stone
#

yes the afterInsert error is how I found the issue

#

that error line notably does not report the item that failed, so when I checked the logs nothing returned of use.. I had to go read them all

keen sparrow
#

Yeah we have a 10,000ms failure set for api connections. We did make it configurable in settings > network to make it possible to increase it

quartz stone
#

any event I disabled tags

keen sparrow
#

You could try increasing it

#

To 20,000ms

#

And see why it fails

keen sparrow
keen sparrow
#

Why we offer increasing too

quartz stone
#

why it failed is not really the point - if you just catch the error and proceed then at least the UI will note it failed

#

the failure isn't the issue with seerr the issue with seerr is that it doesn't display it failed

keen sparrow
quartz stone
#

in the UI

keen sparrow
#

We would like to find out why its failing

#

For somw people

#

And why for some people, increasing the timeout works for them.

#

It proceeds normally for them when timeout is increased to 20+

quartz stone
#

in that circumstance the people have throughput issues I'd assume..

In this specific circumstance it is because I updated the container to seerr and nginx/docker did not like the hostname change, so it didn't attached it properly to the network that it can see the arrs

#

which woudl have continued to fail at 20, 30, 5 mins, etc

#

Again the problem with Seerr isn't the why it is the lack of displaying an issue.

keen sparrow
quartz stone
#

if tags are disabled it will mark the item failed, with tags it crashes out before doing that

keen sparrow
#

We will review and merge c:

quartz stone
#

Wrote it up. Got Error.
Pull request creation failed. Validation failed: must be a collaborator
Template reset.
I'll just disable tags.

keen sparrow
#

You dont have to be a collaborator to open a pull request...

#

Literally there are several hundreds of prs opened rn...

#

Also why is your tags failing?