No endpoint found

[bluewww]

First of all, thanks for your awesome extension!

I hit the following bug:
When I visit http://127.0.0.1:23119/zotxt/ I get the message No endpoint found. In emacs org-zotxt-insert-reference-link seems to work fine, but org-zotxt-open-attachment results in

[error] request--callback: peculiar error: 400
Caught error: (error "#s(request-response 400 nil nil (error http 400) parse-error \"http://127.0.0.1:23119/zotxt/items?key=nil&format=paths\" t (:params ((\"key\") (\"format\" . \"paths\")) :parser json-read :success #[128 \"\\302\\300\\303\\301�\\\"\\\"\\207\" [#[(d &rest args) \"\\302�\\303	\\304\\\"\\\"\\207\" [d args deferred:callback-post plist-get :response] 5] (#s(deferred identity deferred:default-errorback deferred:default-cancel #s(deferred (lambda (&rest --cl-rest--) (apply (function #[(G107 G108 response) \"\\302\\304�!	>\\204�\0\\305\\306\\307�D\\\"\\210�\\310H\\311\\234\\236A�\\312\\313
!�J\\\")\\207\" [response cl-struct-request-response-tags paths G107 type-of signal wrong-type-argument request-response 3 0 org-open-file org-zotxt-choose-path] 5]) (quote --arg--) (quote --item-id--) --cl-rest--)) deferred:default-errorback deferred:default-cancel #s(deferred deferred:default-callback zotxt--deferred-handle-error deferred:default-cancel nil nil nil) nil nil) nil nil)) apply append] 6 \"

(fn &rest ARGS2)\"] :error #[128 \"\\302\\300\\303\\301�\\\"\\\"\\207\" [#[(d &rest args) \"\\302�\\303	\\304\\\"\\\"\\207\" [d args deferred:errorback-post plist-get :response] 5] (#s(deferred identity deferred:default-errorback deferred:default-cancel #s(deferred (lambda (&rest --cl-rest--) (apply (function #[(G107 G108 response) \"\\302\\304�!	>\\204�\0\\305\\306\\307�D\\\"\\210�\\310H\\311\\234\\236A�\\312\\313
!�J\\\")\\207\" [response cl-struct-request-response-tags paths G107 type-of signal wrong-type-argument request-response 3 0 org-open-file org-zotxt-choose-path] 5]) (quote --arg--) (quote --item-id--) --cl-rest--)) deferred:default-errorback deferred:default-cancel #s(deferred deferred:default-callback zotxt--deferred-handle-error deferred:default-cancel nil nil nil) nil nil) nil nil)) apply append] 6 \"

(fn &rest ARGS2)\"] :url \"http://127.0.0.1:23119/zotxt/items?key=nil&format=paths\" :response #0 :encoding utf-8) #<killed buffer> \"HTTP/1.0 400 Bad Request
X-Zotero-Version: 5.0.82
X-Zotero-Connector-API-Version: 2
Content-Type: text/plain; charset=UTF-8

which I think is related to the broken endpoint.

I'm using zotero 5.0.82, zotxt 5.0.5 and org-zotxt-mode 20200120.1950 from melpa on Centos 7 and emacs-26.3.

[egh]

Hi @bluewww - thank you for the report!

It is expected that visiting http://127.0.0.1:23119/zotxt/ will return No endpoint found (the endpoints are more specific, e.g. /zotxt/search.

A 400 is an error in zotxt/zotero. can you follow the instructions in https://www.zotero.org/support/debug_output and get some debug output from zotxt? It should be the last debug output you see before you make the call.

[Viehzeug]

I also have the No endpoint found issue. However, for me no calls to the API seem to work.
I run zotxt 5.0.5 on zotero 5.0.82 on Mac OS.

When I run org-zotxt-insert-reference-link it calls something like /zotxt/search?q=test&method=titleCreatorYear&format=quickBib. Performing the same call by hand, curl "http://127.0.0.1:23119/zotxt/search?q=test&method=titleCreatorYear&format=quickBib"
results in

(5)(+0023984): GET /zotxt/search?q=test&method=titleCreatorYear&format=quickBib HTTP/1.1 Host: 127.0.0.1:23119 User-Agent: curl/7.64.1 Accept: */*

(5)(+0000002): HTTP/1.0 404 Not Found X-Zotero-Version: 5.0.82 X-Zotero-Connector-API-Version: 2 Content-Type: text/plain No endpoint found 

And similarly, curl "http://127.0.0.1:23119/zotxt/version" results in

(5)(+0337211): GET /zotxt/version HTTP/1.1 Host: 127.0.0.1:23119 User-Agent: curl/7.64.1 Accept: */*

(5)(+0000001): HTTP/1.0 404 Not Found X-Zotero-Version: 5.0.82 X-Zotero-Connector-API-Version: 2 Content-Type: text/plain No endpoint found 

[egh]

@Viehzeug It seems that zotxt is not being loaded properly, if every request is failing with a 404. If the version endpoint is not loading, something is going wrong quite early in the loading process. Would it be possible to zotero debug logging in the terminal ( see "Logging to a Terminal Window" in https://www.zotero.org/support/debug_output) and see if there is anything relevant? Probably towards the beginning of logging; I think zotxt should load very early.

[Viehzeug]

No entry that mentions zotxt other than the 404 errors and the very beginning where it lists the extensions.
However, I also don't see any entries on my Ubuntu 18. where it works (just tested the version command there; not the org integration).

[Viehzeug]

Just found something interesting: I kept the console open while uninstalling and reinstalling zotxt 5.0.5 and it gives me (3)(+0064324): error reading file in the console. To make sure that I didn't have corrupt file I re-downloaded the xpi and installed it, but I get the same message. Not sure how to further debug this.

While this is a curious issue, it seems unrelated to the one mentioned by @bluewww.

Edit: Just tried to install 5.0.3 and I get the same issue. However, I definitely had a working setup in November/December, but I'm unsure what Version I used back then.

[bluewww]

This is the error log when calling org-zotxt-open-attachment in org-mode:

[...] omitted
(4)(+0000005): REPLACE INTO "better-bibtex" (name, data) VALUES (?, ?) ['better-bibtex', '{"filename":"better-bibtex","collections":["better-bibtex.citekey","better-bibtex.autoexport"],"databaseVersion":1.5,"engineVersion":1.5,"autosave":false,"autosaveInterval":5000,"autosaveHandle":null,"throttledSaves":false,"options":{"env":"NA","serializationMethod":"normal","destructureDelimiter":"$<\n"},"persistenceAdapter":null,"throttledSavePending":false,"throttledCallbacks":[],"verbose":false,"events":{"init":[null],"loaded":[],"flushChanges":[],"close":[],"changes":[],"warning":[]},"ENV":"NA"}']

(4)(+0000014): Committed DB transaction ffrEBjbG

(4)(+0000322): SELECT COUNT(*) FROM settings WHERE setting='mImport' AND key='cleanup'

(3)(+0000819): Scheduling next feed update

(4)(+0000003): SELECT ( CASE WHEN lastCheck IS NULL THEN 0 ELSE strftime('%s', lastCheck) + refreshInterval * 60 - strftime('%s', 'now') END ) AS nextCheck FROM feeds WHERE refreshInterval IS NOT NULL ORDER BY nextCheck ASC LIMIT 1

(3)(+0000004): No feeds with auto-update

(4)(+0000010): SELECT libraryID AS id FROM feeds WHERE refreshInterval IS NOT NULL AND ( lastCheck IS NULL OR (julianday(lastCheck, 'utc') + (refreshInterval/1440.0) - julianday('now', 'utc')) <= 0 )

(3)(+0000005): Running update for feeds:

(3)(+0000001): All feed updates done

(3)(+0000001): Scheduling next feed update

(4)(+0000001): SELECT ( CASE WHEN lastCheck IS NULL THEN 0 ELSE strftime('%s', lastCheck) + refreshInterval * 60 - strftime('%s', 'now') END ) AS nextCheck FROM feeds WHERE refreshInterval IS NOT NULL ORDER BY nextCheck ASC LIMIT 1

(3)(+0000003): No feeds with auto-update

(5)(+0006597): GET /zotxt/items?key=nil&format=paths HTTP/1.1 User-Agent: curl/7.29.0 Host: 127.0.0.1:23119 Accept: */* Accept-Encoding: deflate, gzip

(5)(+0000021): HTTP/1.0 400 Bad Request X-Zotero-Version: 5.0.82 X-Zotero-Connector-API-Version: 2 Content-Type: text/plain; charset=UTF-8 nil not found

(5)(+0000031): GET /zotxt/version HTTP/1.1 User-Agent: curl/7.29.0 Host: 127.0.0.1:23119 Accept: */* Accept-Encoding: deflate, gzip

(5)(+0000002): HTTP/1.0 200 OK X-Zotero-Version: 5.0.82 X-Zotero-Connector-API-Version: 2 Content-Type: application/json; charset=UTF-8 { "version": "5.0.5" }

(3)(+0004235): WebSocket message: {"event":"subscriptionsCreated","subscriptions":[{"apiKey":"********","topics":["/users/5923898","/users/5923898/publications"]},{"topics":["styles","translators"]}],"errors":[]}

(3)(+0008468): Starting full-text content processor

[egh]

@bluewww On further checking, I can see the problem you are seeing is that zotxt-emacs is not finding the key for the entry. I created a new ticket here egh/zotxt-emacs#37

[egh]

@Viehzeug I created a spin off issue for what you are seeing here: #15