I agree that would be a bug Ivan, but please try to confirm what happened
actually through logs ?
Now that I checked, I do recall one similar case actually, where template
seems to be present physically on storage (images itself that is - can you
also confirm your templates are present on SS, besi
Well, we don't remove templates usually, just rename them and reset public,
featured flags.
I'll check, but suppose, that template api removal call shouldn't produce
the case like this? How this could be achieved thru API, when storage_ref
is removed, but template is in place?
The records for cer
Assuming it's not Assange :), perhaps check with teammates if any changes
on these templates were done - are your records completely missing or just
altered in bad way ?
Can you double check the API log for any delete template API calls ?
On Mon, 15 Apr 2019 at 17:39, Ivan Kudryavtsev
wrote:
>
Andrija,
yes, I have the case with missing records in 'template_store_ref'. What I
don't get is how it could happen...
пн, 15 апр. 2019 г. в 11:24, Andrija Panic :
> Hi Ivan,
>
> is it possible that your DB got somehow corrupted or that you are missing
> records in template_store_ref etc - this
Hi Ivan,
is it possible that your DB got somehow corrupted or that you are missing
records in template_store_ref etc - this might be the reason why SSVM is
trying to download templates again - if you check the logs for
non-problematic templates, you will see something like "template already on
st
To follow up. When SSVM boots it tries to redownload all the templates from
original sources this leads to next oucomes:
- if the source is not available, the result is:
No route to host (Host unreachable) - If the template is changed on source:
then it leads to MD5 sum error.
Any ideas, why SSVM
