Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connection error after closing failed items list and opening another list #5652

Closed
imsodin opened this issue Apr 13, 2019 · 1 comment

Comments

Projects
None yet
2 participants
@imsodin
Copy link
Member

commented Apr 13, 2019

  1. Open any list of failed items and close them again.
  2. In another folder open a list of locally changed items (maybe another list or the same folder would also work, but I didn't try).
  3. Close it.

Expected: Nothing
Result: At some point during 2. or 3. a connection error pops up. Refreshing resolves it.

From console:

HTTPError {…}
​config: Object { method: "GET", transformRequest: (1) […], url: "rest/folder/pullerrors?folder=undefined&page=1&perpage=undefined", … }
​data: "no such folder\n"
​headers: function headersGetter()
​status: 404
​<prototype>: {…}

Stack:

refreshFailed (syncthingController.js#656)
$parseFunctionCall (angular.js#12493)
scopeName (angular.js#7773)
goToPage (angular-dirPagination.js#373)
dirPaginationControlsLinkFn (angular-dirPagination.js#339)
$digest (angular.js#14431)
$apply (angular.js#14694)
applyAsyncId (angular.js#14984)
completeOutstandingRequest (angular.js#4959)
timeoutId (angular.js#5347)

Looks like some kind of deferred call by angular.

@imsodin imsodin added the bug label Apr 13, 2019

@imsodin

This comment has been minimized.

Copy link
Member Author

commented May 17, 2019

Currently we are doing a needless api call whenever we open a failed or locally changed files modal (probably all this file list modals), in case of the failed items I just did something slightly differently, so an error resulted. Is anyone interested in getting to the bottom of this, i.e. actually preventing these superfluous calls?

I have no clue where to start. I can do a simple fix to make the call succeed (and do nothing), as all the other calls do.

imsodin added a commit to imsodin/syncthing that referenced this issue Jun 2, 2019

imsodin added a commit to imsodin/syncthing that referenced this issue Jun 2, 2019

imsodin added a commit to imsodin/syncthing that referenced this issue Jun 2, 2019

@calmh calmh closed this in 5541697 Jun 5, 2019

calmh added a commit to calmh/syncthing that referenced this issue Jun 10, 2019

Merge branch 'master' into crashrep
* master:
  lib/connections: Do not leak FDs, fix address copy (fixes syncthing#5767) (syncthing#5768)
  lib/api: Correct logic for errors.jons in support bundle (fixes syncthing#5766)
  all: Remove "large blocks" config (syncthing#5763)
  lib/build: Version 1.2 will be the Fermium Flea
  readme: Remove old, dead link (fixes syncthing#5760)
  gui: Don't call API when no modal is open (fixes syncthing#5652) (syncthing#5759)
  lib/protocol: Prioritize close msg and add close timeout (syncthing#5746)
  gui, man, authors: Update docs, translations, and contributors
  build(deps): bump github.com/lucas-clemente/quic-go (syncthing#5761)
  lib/protocol: Return from ClusterConfig when closed (syncthing#5752)
  build(deps): bump golang.org/x/text from 0.3.0 to 0.3.2 (syncthing#5751)

@calmh calmh added this to the v1.2.0 milestone Jun 10, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.