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

feat: (Clisk) Catch and log downloadFileInWorker errors #927

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

doubleface
Copy link
Contributor

If there was an error in the downloadFileInWorker function, it would
cause the whole clisk konnector run to fail

Now, the error is caught and a warning error will be visible in the
konnector logs.

This is also coherent with the behavior of node konnectors.

Checklist

Before merging this PR, the following things must have been done:

  • Faithful integration of the mockups at all screen sizes
  • Tested on iOS
  • Tested on Android
  • Localized in English and French
  • All changes have test coverage
  • Updated README & CHANGELOG, if necessary

If there was an error in the downloadFileInWorker function, it would
cause the whole clisk konnector run to fail

Now, the error is caught and a warning error will be visible in the
konnector logs.

This is also coherent with the behavior of node konnectors.
Copy link
Contributor

@Crash-- Crash-- left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the execution is marked as successful, even though we failed to download the file? Right? So we'll have a lastSuccessDate to the date of execution and if we then want to optimize by recovering only what was done after the last success date, we'll be stuck.

If the download has failed we should:

  • Retry once or twice
  • If after those retries it still fails, then we should throw an error.

I really don't like the fact we don't tell the user that something was not working as expected.

@doubleface
Copy link
Contributor Author

@Crash-- But if we fail in the download of a file, we would not try to download the other files, which seems to me to be a poorer service. Is it really what we want ?

FYI we have a retry option in saveFiles but which is set to 0 by default (this comes from the nodejs implementation).

@Crash--
Copy link
Contributor

Crash-- commented Sep 12, 2023

@Crash-- But if we fail in the download of a file, we would not try to download the other files, which seems to me to be a poorer service. Is it really what we want ?

I don't have proposed anything like that ;). I just say that we should throw an error somewhere and don't tell the user that everything was good. There is a lot of possibility here.

To move forward:

  • How can we have an error when downloading? What would be the causes?
    • Internet connexion : After a retry, if there is still an internet connexion issue, then we should not try to download other files and we should stop
    • Server down: Same
    • Other causes ?

@doubleface
Copy link
Contributor Author

doubleface commented Sep 15, 2023

@Crash--

How can we have an error when downloading? What would be the causes?

  • Internet connexion : After a retry, if there is still an internet connexion issue, then we should not try to download other > files and we should stop
  • Server down: Same
  • Other causes ?
  • a type of file unexpected by the konnector for a type of account we don't have
  • a temporary server side error, caused by too many file downloads in a row (retry will help here)

@Crash--
Copy link
Contributor

Crash-- commented Sep 15, 2023

a type of file unexpected by the konnector for a type of account we don't have

In that case, what should we do? Be silent? Throw an error? Let's see with the product team.

@acezard acezard removed their request for review January 17, 2024 13:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants