waiting for Zotero.Schema.schemaUpdatePromise

[Emiliano Heyns]

I'm waiting for Zotero.Schema.schemaUpdatePromise, but it doesn't seem to resolve even after 20 seconds after startup. Here's what I have. Hints?

Zotero.debug('BBT: attempting start');

if (!Zotero.BBT) {

  Zotero.debug('BBT: starting');

  Zotero.BBT = {};

  Zotero.Promise.coroutine(function*() {

    Zotero.debug('BBT: waiting for schema...');

    yield Zotero.Schema.schemaUpdatePromise;

    Zotero.debug('BBT: schema done');

    require('./better-bibtex.coffee');

    yield Zotero.BBT.init();

  })();

}

[Dan Stillman]

On 7/14/17 6:44 PM, Emiliano Heyns wrote:
> I'm waiting for Zotero.Schema.schemaUpdatePromise, but it doesn't seem
> to resolve even after 20 seconds after startup. Here's what I have. Hints?

We'd need to see the Zotero debug output. Is this with a custom Zotero
build or the release build?

[Emiliano Heyns]

The logs can be found at https://gist.github.com/695355eabbd15b2a4a7585b88f3ebc27 ; this was generated using 5.0.4 release (I only work with release builds) 

[Dan Stillman]

That appears to show you making HTTP requests in the middle of translator installation to a custom connector-server endpoint that then runs code that quits the app…

More generally, make sure you're always running with debug output enabled (either -ZoteroDebugText or the new -ZoteroDebug window) so you know what's happening in Zotero and can use debug output yourself. It should be easy to see here when translator installation is still going and when it finishes.

[Emiliano Heyns]

On further inspection I found I just needed to wait longer; it takes some 30 seconds for the promise to be settled on my system. But that's detectable so not a problem. 

[Dan Stillman]

It should only be anything like that (though generally much less — e.g., was just 7 seconds for me) on the first startup after an upgrade (and I'm going to try to speed up the translatorCache updating). Subsequent translator initialization should be much faster (e.g., a second or two).

[Emiliano Heyns]

On Saturday, July 15, 2017 at 10:01:24 AM UTC+2, Dan Stillman wrote:

On 7/15/17 3:28 AM, Emiliano Heyns wrote:

On Saturday, July 15, 2017 at 2:39:16 AM UTC+2, Dan Stillman wrote:

On 7/14/17 6:44 PM, Emiliano Heyns wrote:
> I'm waiting for Zotero.Schema.schemaUpdatePromise, but it doesn't seem
> to resolve even after 20 seconds after startup. Here's what I have. Hints?

We'd need to see the Zotero debug output. Is this with a custom Zotero
build or the release build?

The logs can be found at https://gist.github.com/695355eabbd15b2a4a7585b88f3ebc27 ; this was generated using 5.0.4 release (I only work with release builds)

That appears to show you making HTTP requests in the middle of translator installation to a custom connector-server endpoint that then runs code that quits the app…

That is fully correct -- the problem was that I issued the shutdown before the schemapromise settled. I changed that now and things start up and shut down as expected, so I'm off to the races it seems.

 

More generally, make sure you're always running with debug output enabled (either -ZoteroDebugText or the new -ZoteroDebug window) so you know what's happening in Zotero and can use debug output yourself. It should be easy to see here when translator installation is still going and when it finishes.

I was not passing that flag (I am now) but the previous log was generated without it. What does the ZoteroDebugFlag do more than generating said log?

[Dan Stillman]

On 7/15/17 4:32 AM, Emiliano Heyns wrote:

 

More generally, make sure you're always running with debug output enabled (either -ZoteroDebugText or the new -ZoteroDebug window) so you know what's happening in Zotero and can use debug output yourself. It should be easy to see here when translator installation is still going and when it finishes.

I was not passing that flag (I am now) but the previous log was generated without it. What does the ZoteroDebugFlag do more than generating said log?

I just meant you should always be running with visible debug output (and -jsconsole too).

-ZoteroDebugText is equivalent to having the debug.log pref enabled.

-ZoteroDebug opens a window — it's more meant for users who encounter problems at startup, but if for some reason you don't want to run from the terminal (or if you're using Windows and haven't installed Cygwin or Git, which have much faster terminals than cmd.exe), it's an option.

[Emiliano Heyns]

I forgot to pass the -ZoteroSkipBundledFiles flag -- startup is down to 5 seconds now. 

[Emiliano Heyns]

On Saturday, July 15, 2017 at 10:41:35 AM UTC+2, Dan Stillman wrote:

On 7/15/17 4:32 AM, Emiliano Heyns wrote:

 

More generally, make sure you're always running with debug output enabled (either -ZoteroDebugText or the new -ZoteroDebug window) so you know what's happening in Zotero and can use debug output yourself. It should be easy to see here when translator installation is still going and when it finishes.

I was not passing that flag (I am now) but the previous log was generated without it. What does the ZoteroDebugFlag do more than generating said log?

I just meant you should always be running with visible debug output (and -jsconsole too).

-ZoteroDebugText is equivalent to having the debug.log pref enabled.

Ah, right, but that's already on in the profile I test with before my tests start -- that explains why I was seeing no difference. STDOUT/STDERR is redirected to a log file and I just tail the log file it generates.

[Dan Stillman]

On 7/15/17 4:42 AM, Emiliano Heyns wrote:

It should only be anything like that (though generally much less — e.g., was just 7 seconds for me) on the first startup after an upgrade (and I'm going to try to speed up the translatorCache updating). Subsequent translator initialization should be much faster (e.g., a second or two).

I forgot to pass the -ZoteroSkipBundledFiles flag -- startup is down to 5 seconds now.

But that's still only necessary to avoid translation initialization after a rebuild or clearing of your data directory. Otherwise, a normal startup should be quite fast.

[Emiliano Heyns]

You're right, the problem was I was resetting the data dir. What gets pulled in during init? The difference between an initialized profile/data and a bare one is 900K vs 20MB.

[Emiliano Heyns]

Is Zotero.Schema.schemaUpdatePromise expected to resolve when the system Zotero is running on is offline? I've been waiting for quite a bit but when I put my system offline, it looks like Zotero.Schema.schemaUpdatePromise does not resolve. Since BBT waits for Zotero.Schema.schemaUpdatePromise to clear before it starts, this would be a problem for me.