Current behavior (9.9.12):

If an authorized connection to Dropbox expires, attempts to use it start creating modal pop-up dialogs that say it has expired and offer to open the connection dialog to re-authorize. A new dialog accumulates every time the connection is used. If the connection is used in a trigger, they accumulate every time the trigger tries to check for applicable files, potentially resulting in a very large number of dialogs (easily enough to make the application unresponsive, especially with how much slower the new UI is than the old one was) until eventually the trigger gets deactivated.

I assume that the number of dialogs that will be accumulated before the trigger ultimately deactivates is the trigger's "on error reconnect attempts" setting plus any caused by other attempts to use the connection (such as time-based triggers) that happen before that limit is reached.

My suggestion is twofold. First, I don't think this error should be able to result in multiple modal dialogs as it currently does.

I'm not sure whether this error can still occur in such a way that it can be resolved without human intervention. I am almost positive that used to be the case - I believe at one point, while dropbox connections were not quite using refresh tokens correctly, I had determined in the course of coming up with a workaround that the connection held an internal property that would cause Visualcron to consider the authorization expired once a certain time had passed and it wouldn't even attempt the connection anymore - but, for a connection not using the Visualcron official Dropbox app, if I remember correctly, I had figured out how to use the API to update the connection automatically. If there's no possibility for the issue to resolve itself once that error occurs, then treating it differently from all other connection errors by immediately disabling the connection potentially makes sense (I, personally, would like to be able to have a significantly higher retry setting for any other kind of error than for this one). If it is at all possible for the error to be recovered from automatically, however, that would probably be a bad idea. However, in neither case does opening the modal dialog *repeatedly* make sense to me. Surely there would be a way for the client to detect that it's already open and not open it again?


Second: when this situation eventually causes the trigger to be disabled, it does not fire a "Trigger Inactivated by Error" that I have set up as a trigger for a monitoring job.

Actually I just realized that the "job events" section in the Visualcron trigger dialog has an "all jobs" selection which I think either didn't exist when I first created that trigger, or wasn't possible to select if no job events were selected. I thought I had a trigger for any trigger being inactivated before that didn't need a job selected, but now I'm not sure, and I'm almost positive I remember a time several versions ago when a job-related trigger with no specific job selected would trigger for all jobs, and then a subsequent time when it was impossible to set up a job-related trigger without selecting one specific job...maybe I'm remembering all of that wrong, but either way I'm almost positive I've never tried a trigger-related trigger with "all jobs" selected for job events, so maybe trigger events are considered a type of job event (it would make sense to me, given that as far as I know there's no way to have a trigger except on a job) and the behavior is already as I expected but I had this monitoring job configured wrong.

Long story short, I think that a trigger being disabled in this manner should fire a "trigger inactivated by error" event, but maybe it already does and I just wasn't watching for it correctly. If so, uh, good job.

Current behavior (9.9.12):

If an authorized connection to Dropbox expires, attempts to use it start creating modal pop-up dialogs that say it has expired and offer to open the connection dialog to re-authorize. A new dialog accumulates every time the connection is used. If the connection is used in a trigger, they accumulate every time the trigger tries to check for applicable files, potentially resulting in a very large number of dialogs (easily enough to make the application unresponsive, especially with how much slower the new UI is than the old one was) until eventually the trigger gets deactivated.

I assume that the number of dialogs that will be accumulated before the trigger ultimately deactivates is the trigger's "on error reconnect attempts" setting plus any caused by other attempts to use the connection (such as time-based triggers) that happen before that limit is reached.

My suggestion is twofold. First, I don't think this error should be able to result in multiple modal dialogs as it currently does.

I'm not sure whether this error can still occur in such a way that it can be resolved without human intervention. I am almost positive that used to be the case - I believe at one point, while dropbox connections were not quite using refresh tokens correctly, I had determined in the course of coming up with a workaround that the connection held an internal property that would cause Visualcron to consider the authorization expired once a certain time had passed and it wouldn't even attempt the connection anymore - but, for a connection not using the Visualcron official Dropbox app, if I remember correctly, I had figured out how to use the API to update the connection automatically. If there's no possibility for the issue to resolve itself once that error occurs, then treating it differently from all other connection errors by immediately disabling the connection potentially makes sense (I, personally, would like to be able to have a significantly higher retry setting for any other kind of error than for this one). If it is at all possible for the error to be recovered from automatically, however, that would probably be a bad idea. However, in neither case does opening the modal dialog *repeatedly* make sense to me. Surely there would be a way for the client to detect that it's already open and not open it again?


Second: when this situation eventually causes the trigger to be disabled, it does not fire a "Trigger Inactivated by Error" that I have set up as a trigger for a monitoring job.

Actually I just realized that the "job events" section in the Visualcron trigger dialog has an "all jobs" selection which I think either didn't exist when I first created that trigger, or wasn't possible to select if no job events were selected. I thought I had a trigger for any trigger being inactivated before that didn't need a job selected, but now I'm not sure, and I'm almost positive I remember a time several versions ago when a job-related trigger with no specific job selected would trigger for all jobs, and then a subsequent time when it was impossible to set up a job-related trigger without selecting one specific job...maybe I'm remembering all of that wrong, but either way I'm almost positive I've never tried a trigger-related trigger with "all jobs" selected for job events, so maybe trigger events are considered a type of job event (it would make sense to me, given that as far as I know there's no way to have a trigger except on a job) and the behavior is already as I expected but I had this monitoring job configured wrong.

Long story short, I think that a trigger being disabled in this manner should fire a "trigger inactivated by error" event, but maybe it already does and I just wasn't watching for it correctly. If so, uh, good job.

Thanks for reporting this,

I am pretty sure that it does fire "trigger inactivated by error" (I have a vague memory of this particular scenario occurring some time ago where it did fire)

If that is not the case, please let me know

I have verified that this does fire the "trigger deactivated by error" when configured correctly (I did not try to go back and verify that changes in the settings UI had caused what used to be a correctly configured trigger to wind up incorrectly configured). I actually need to go back and see if I can figure out whether the fact that it triggered twice per event is because my configuration is weird or not.

I also have strong supporting evidence (technically not definite, but it sure seems pretty conclusive) that I was right about being able to control the number of alerts by adjusting the retry parameters on the trigger.

Unfortunately that is because it happened on both the 9th and the 12th, which is not a sustainable failure rate. If it happens again tomorrow or Friday I'm probably going to have to try switching back to my kludge to see if that seems more reliable than the provided app at keeping the connection functional. That said, I think one of the alerts I got may have indicated an HTTP error specifically, which seems to suggest that this was actually Dropbox authorization dropping out, not the issue I observed previously (from before the switch to using refresh tokens was fully working) where it seemed like Visualcron had an internal timestamp appended to the access token (which I think I remember guessing was based on a misplaced-decimal translation of the access token's lifetime, but I can't remember if I was able to verify that) after which it would stop trying to use the connection. If that's the case, then my approach shouldn't be an improvement.

I also still think that both repeatedly popping up that dialog for any cloud connection error, and having to choose between a fairly persistent on-error-try-again setting (in case of an actual network problem) and one that will stop trying relatively quickly (because this issue, which as far as I can tell simply cannot resolve without manual adjustment, is by far the most common error state), warrant changes.

I have verified that this does fire the "trigger deactivated by error" when configured correctly (I did not try to go back and verify that changes in the settings UI had caused what used to be a correctly configured trigger to wind up incorrectly configured). I actually need to go back and see if I can figure out whether the fact that it triggered twice per event is because my configuration is weird or not.

I also have strong supporting evidence (technically not definite, but it sure seems pretty conclusive) that I was right about being able to control the number of alerts by adjusting the retry parameters on the trigger.

Unfortunately that is because it happened on both the 9th and the 12th, which is not a sustainable failure rate. If it happens again tomorrow or Friday I'm probably going to have to try switching back to my kludge to see if that seems more reliable than the provided app at keeping the connection functional. That said, I think one of the alerts I got may have indicated an HTTP error specifically, which seems to suggest that this was actually Dropbox authorization dropping out, not the issue I observed previously (from before the switch to using refresh tokens was fully working) where it seemed like Visualcron had an internal timestamp appended to the access token (which I think I remember guessing was based on a misplaced-decimal translation of the access token's lifetime, but I can't remember if I was able to verify that) after which it would stop trying to use the connection. If that's the case, then my approach shouldn't be an improvement.

I also still think that both repeatedly popping up that dialog for any cloud connection error, and having to choose between a fairly persistent on-error-try-again setting (in case of an actual network problem) and one that will stop trying relatively quickly (because this issue, which as far as I can tell simply cannot resolve without manual adjustment, is by far the most common error state), warrant changes.

Thank you for this information. Could you please send an email to support@visualcron.com with your findings that you can verify (after you verify it), that way I can connect the ticket directly to the developer team if there is something that needs to be changed in how visualcron handles the token or anything else related.

You mention the token handling, so I presume you mean about the authorization dropping out. (I do apologize for polluting my feature request regarding the dialog behavior with information that may belong in a problem report.)

If I get the time to write something up, I'll consider it, but due to my vacation schedule that's unlikely to be this year, at least in any kind of detail.