Sync stuck on scanning

#1

I’ve just upgraded to insync-3.8.7.50516 from a much older version, but am now unable to sync any files. The app is just stuck on “Scanning” but never seems to achieve anything. I had a look into the log files and the following error is continuously reported:

js: Failed to load https://app.posthog.com/decide/?v=2&ip=1&_=1708638594428&ver=1.26.0: The value of the ‘Access-Control-Allow-Origin’ header in the response must not be the wildcard ‘*’ when the request’s credentials mode is ‘include’. Origin ‘file://’ is therefore not allowed access. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.
js: Bad HTTP status: 0
js: Enqueued failed request for retry in 96000
js: ResizeObserver loop limit exceeded

Any suggestions? Restarting the app several times did no good.

#2

I’m having a similar issue. My syncing got stuck on one file for about … three weeks. Insync support told me it might be because I have symlinks.

There are no symlinks in my folders though so it’s not that. Then they asked for my logs.

After about two weeks they eventually got back to me and said:

“our team looked into the logs you sent. You were encountering some upload issues when this error showed up in your log files: ‘Operation too slow. Less than 1 bytes/sec transferred the last 80 seconds’. This error is usually caused by a large transfer that causes a delay in the network.”

So, basically, they’ve just responded to my support request by repeating it back to me, just in more technical language, and without offering any actual solution. Or am I supposed to read between the lines and only have small files?

Does anyone know of a better syncing out there for Google Drive, one that supports syncing or Shared Drives, and which has business-grade support?

I’ve just about reached my limit of manually dragging files up and down between my PCs and the cloud, and being stonewalled and gaslighted by Insync support.

#3

Hi @Richard_Luke,

My apologies for the troubles you’ve continued to face on our app trying to get things back in order.

I’ve escalated this to our engineer to see if there are any files or other underlying factors which halted the sync process.

#4

@tim1mw Hi! A ResizeObserver is a function we use to track resizing of certain UI elements. We use it for elements that are anchored to something (like dropdowns), to make sure that they are still anchored to to them if they ever move. The error is saying that this function was not able to deliver all observations within a given time frame.

This message is benign and should not be the cause of the stuck syncing issue. There is something else causing the problem, which we’d like to investigate. Could you let me know if you’ve sent your logs to support@insynchq.com? If not, please follow the instructions here and send us two things:

  • logs.db
  • out.txt

Thank you!

#5

I’m sending the logs now. Right now the constant “scanning” message has gone away, but the log still shows this error:

js: Bad HTTP status: 0
js: Enqueued failed request for retry in 48000
js: Failed to load https://app.posthog.com/decide/?v=2&ip=1&_=1708638594428&ver=1.26.0: The value of the ‘Access-Control-Allow-Origin’ header in the response must not be the wildcard ‘*’ when the request’s credentials mode is ‘include’. Origin ‘file://’ is therefore not allowed access. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

and I’ve got files which I can see in the cloud that haven’t synced to my local drive and vice-versa, so syncing is totally broken at the moment.

#6

Hi Tim,

I’ve forwarded the additional information to our engineers for their investigation. Thank you!

#7

Bonjour,
Same PB on a Debian 12 with insync 3.8.7.50516

1 Like
#8

@martignagoj Bonjour!

Could you please send the specific details of the issue to support@insynchq.com with the link to this post? Please also include a screenshot of what directory Insync is stuck on. You can check by clicking “Scanning…” at the bottom right.

#9

I’m getting precisely the same error as tim1mw, Richard_Luke and martignagoj on Manjaro with insync version 3.8.7.5016. Did anyone get a solution?

#10

Hello @escape_the_sun!

There are a few error messages mentioned in this thread (resizeObserver loop, Operation too slow, and Bad HTTP status: 0) – could you specify which one?

Thank you very much!

#11

It’s an endless loop of
js: Bad HTTP status: 0
js: Enqueued failed request for retry in 6000
js: ResizeObserver loop limit exceeded
js: ResizeObserver loop limit exceeded
js: Failed to load https…
The https address only has a different value for the ?ip= key

Also at the top of the log, after a couple of warnings. Lines 8-129 are all “js: ResizeObserver loop limit exceeded” This then repeats from line 136 till 188. That’s when that above mentioned loop begins

#12

I am also having the same issue - it is been like this for weeks or months now. Insynch is basically broken for me and it is very frustrating. A few files might sync when the program starts then it gets stuck on scanning. Example of the error is similar to those above:

js: ResizeObserver loop limit exceeded
js: ResizeObserver loop limit exceeded
js: Failed to load https://app.posthog.com/decide/?v=2&ip=1&_=1711542098968&ver=1.26.0: The value of the ‘Access-Control-Allow-Origin’ header in the response must not be the wildcard ‘*’ when the request’s credentials mode is ‘include’. Origin ‘file://’ is therefore not allowed access. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.
**js: Bad HTTP status: 0 **
js: Enqueued failed request for retry in 24000

#13

I am also getting basically the same message on Zorin 17.1 (ubuntu 22.04-based).

js: Failed to load https://app.posthog.com/e/?ip=1&_=1711703005398&ver=1.26.0: The value of the ‘Access-Control-Allow-Origin’ header in the response must not be the wildcard '’ when the request’s credentials mode is ‘include’. Origin ‘file://’ is therefore not allowed access. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.*
*js: Bad HTTP status: 0 *
js: Enqueued failed request for retry in 384000

Nothing is being synced, but changes have been made. Hope to get a resolution on this soon.

#14

Hello and thank you for your active participation on this thread! I truly apologize for the issues you are all facing as of late. I’ve escalated this to our engineer for further investigation.

Thank you for your utmost patience!

#15

Hello all!

As an update, if you see an error with this line: Failed to load https://app.posthog.com/decide/?v=2&ip=1&_=1711542098968&ver=1.26.0, this was caused by a change that PostHog deployed: https://posthog.com/questions/cors-error-decide-endpoint

Rest assured that this issue should not break your sync in any way and is not related to stuck syncing issues. For now, users can ignore it. Furthermore, errors in the out.txt file are frontend-specific most of the time (not always, as sometimes logs get written to the out.txt file) and aren’t related to the actual syncing mechanism.

Thank you!

#16

@rt1870 In your case, however, your logs reveal that there are a few SSL and auth token errors.

For the SSL errors:

  • These are possibly caused by a proxy or firewall – could you check if a proxy or firewall/antivirus might be blocking Insync?

For the authentication token errors:

  • I sent you an email for privacy as I’m going to reference your email address for this one. Thank you!
#17

Is there any update on this? Quite a few people seem to have this problem and I’ve now been without a functioning Insync for over a month now.

Also, while the error relating to PostHog might not be the cause of the sync problem, I am concerned that I am seeing it at all. PostHog seems to be a seems to be an analytics service, however I have opted out of “send usage data to Insync”, so I would like to know what these calls to Posthog are for. On the face of it seems that analytics data is still being sent.

#18

Hi @tim1mw! I have also responded to your follow up via email and would like to apologize once more for the delays in our updates. I’m following this up with our engineers.

As for the PostHog issue - extremely valid question! I have confirmed with our engineer that it’s only initializing the PostHog instance/module, but it’s not sending out any analytics. I hope this info helps!

#19

As PostHog is not the issue, but my sync is not working, is there additional information that needs to be sent in order to solve this problem? I have not received an email from you.

Thanks!

Folders removed from local drive for no reason
#20

Not sure why this hasn’t been posted here, but the advice I got from support was to run this command:

sudo ln -s /etc/ssl/certs/ca-bundle.crt /etc/ssl/certs/ca-certificates.crt

To fix a problem with a certificate location, this worked and InSync is now syncing again.

1 Like