Searching FreeKeene/freekeene/free keene does not return correct result #68

New issue

Closed

opened 2018-05-10 00:27:48 +02:00 by tzarebczan · 3 comments

tzarebczan commented

2018-05-10 00:27:48 +02:00

(Migrated from github.com)

I would expect lbry://@FreeKeene in the results

tiger5226 commented

2018-05-10 01:16:02 +02:00

(Migrated from github.com)

I checked the API

https://lighthouse.lbry.io/search?s=@freekeene

No dice! So I went to lbrycrd since this is where lighthouse gets claims from.

I checked lbrycrd with following query:

MacBook-Pro:~ Mark$ curl -v --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getclaimsforname", "params": ["@freekeene"] }' -H 'content-type: application/json;' http://lbry:lbry@127.0.0.1:9245/

Below is the result of the query

{"result":{"nLastTakeoverHeight":0,"claims":[],"supports without claims":[]},"error":null,"id":"curltest"}

The wierd thing is I do have it in chainquery

https://chainquery.lbry.io/api/SQL?query=SELECT%20*%20FROM%20chainquery.claim%20WHERE%20name%20=%20%22@freekeene%22

with the following result:

{
  "TimeSpent": "2.944948ms",
  "Status": 200,
  "Data": [
    {
      "author": null,
      "bid_state": "Controlling",
      "certificate": "{\"version\":1,\"keyType\":3,\"publicKey\":\"MFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAEvAdmSZF9G2ZLSfccon9344hvV3Mejvq5jSAq2tyX48JkdeW3apgEUaEg9ROLio/lrSad5ckbIUPyZb2x7IACZA==\"}",
      "claim_id": "27aad3c089dac2dbd205492d2cab32b7981f22d8",
      "claim_type": 2,
      "content_type": null,
      "created": "2018-05-06T00:24:01Z",
      "description": null,
      "effective_amount": "1000000.00000000",
      "fee": "0.00000000",
      "fee_address": "",
      "fee_currency": null,
      "height": 0,
      "id": 137582,
      "is_filtered": 0,
      "is_n_s_f_w": 0,
      "language": null,
      "modified": "2018-05-06T00:24:01Z",
      "name": "@FreeKeene",
      "publisher_id": null,
      "publisher_sig": null,
      "sd_hash": null,
      "thumbnail_url": null,
      "title": null,
      "transaction_by_hash_id": "e905c8c42f6f728572d1d7bfe0d6f8559be0a594b63ffb4802cdef6f6bca3b4a",
      "transaction_time": 1525565773,
      "valid_at_height": 365392,
      "value_as_hex": "08011002225e0801100322583056301006072a8648ce3d020106052b8104000a03420004bc076649917d1b664b49f71ca27f77e3886f57731e8efab98d202adadc97e3c26475e5b76a980451a120f5138b8a8fe5ad269de5c91b2143f265bdb1ec800264",
      "value_as_json": null,
      "version": "_0_0_1",
      "vout": 0
    }
  ],
  "RedirectURL": "",
  "Error": null
}

So now that I have the claimid I put this query into lbrycrd

curl -v --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getclaimbyid", "params": ["27aad3c089dac2dbd205492d2cab32b7981f22d8"] }' -H 'content-type: application/json;' http://lbry:lbry@127.0.0.1:9245/

I get a result...

{"result":{"name":"@FreeKeene","value":"\b\u0001\u0010\u0002\"^\b\u0001\u0010\u0003\"X0V0\u0010\u0006\u0007*\u0086H\u00ce=\u0002\u0001\u0006\u0005+\u0081\u0004\u0000\n\u0003B\u0000\u0004\u00bc\u0007fI\u0091}\u001bfKI\u00f7\u001c\u00a2\u007fw\u00e3\u0088oWs\u001e\u008e\u00fa\u00b9\u008d *\u00da\u00dc\u0097\u00e3\u00c2du\u00e5\u00b7j\u0098\u0004Q\u00a1 \u00f5\u0013\u008b\u008a\u008f\u00e5\u00ad&\u009d\u00e5\u00c9\u001b!C\u00f2e\u00bd\u00b1\u00ec\u0080\u0002d","claimId":"27aad3c089dac2dbd205492d2cab32b7981f22d8","txid":"e905c8c42f6f728572d1d7bfe0d6f8559be0a594b63ffb4802cdef6f6bca3b4a","n":0,"amount":1000000,"effective amount":1000000,"height":365392},"error":null,"id":"curltest"}

So I think this might be an example of case sensitivity. Not sure why it is showing up yet in search.

I checked the API https://lighthouse.lbry.io/search?s=@freekeene No dice! So I went to lbrycrd since this is where lighthouse gets claims from. I checked lbrycrd with following query: ``` MacBook-Pro:~ Mark$ curl -v --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getclaimsforname", "params": ["@freekeene"] }' -H 'content-type: application/json;' http://lbry:lbry@127.0.0.1:9245/ ``` Below is the result of the query ``` {"result":{"nLastTakeoverHeight":0,"claims":[],"supports without claims":[]},"error":null,"id":"curltest"} ``` The wierd thing is I do have it in chainquery https://chainquery.lbry.io/api/SQL?query=SELECT%20*%20FROM%20chainquery.claim%20WHERE%20name%20=%20%22@freekeene%22 with the following result: ``` { "TimeSpent": "2.944948ms", "Status": 200, "Data": [ { "author": null, "bid_state": "Controlling", "certificate": "{\"version\":1,\"keyType\":3,\"publicKey\":\"MFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAEvAdmSZF9G2ZLSfccon9344hvV3Mejvq5jSAq2tyX48JkdeW3apgEUaEg9ROLio/lrSad5ckbIUPyZb2x7IACZA==\"}", "claim_id": "27aad3c089dac2dbd205492d2cab32b7981f22d8", "claim_type": 2, "content_type": null, "created": "2018-05-06T00:24:01Z", "description": null, "effective_amount": "1000000.00000000", "fee": "0.00000000", "fee_address": "", "fee_currency": null, "height": 0, "id": 137582, "is_filtered": 0, "is_n_s_f_w": 0, "language": null, "modified": "2018-05-06T00:24:01Z", "name": "@FreeKeene", "publisher_id": null, "publisher_sig": null, "sd_hash": null, "thumbnail_url": null, "title": null, "transaction_by_hash_id": "e905c8c42f6f728572d1d7bfe0d6f8559be0a594b63ffb4802cdef6f6bca3b4a", "transaction_time": 1525565773, "valid_at_height": 365392, "value_as_hex": "08011002225e0801100322583056301006072a8648ce3d020106052b8104000a03420004bc076649917d1b664b49f71ca27f77e3886f57731e8efab98d202adadc97e3c26475e5b76a980451a120f5138b8a8fe5ad269de5c91b2143f265bdb1ec800264", "value_as_json": null, "version": "_0_0_1", "vout": 0 } ], "RedirectURL": "", "Error": null } ``` So now that I have the claimid I put this query into lbrycrd ``` curl -v --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getclaimbyid", "params": ["27aad3c089dac2dbd205492d2cab32b7981f22d8"] }' -H 'content-type: application/json;' http://lbry:lbry@127.0.0.1:9245/ ``` I get a result... ``` {"result":{"name":"@FreeKeene","value":"\b\u0001\u0010\u0002\"^\b\u0001\u0010\u0003\"X0V0\u0010\u0006\u0007*\u0086H\u00ce=\u0002\u0001\u0006\u0005+\u0081\u0004\u0000\n\u0003B\u0000\u0004\u00bc\u0007fI\u0091}\u001bfKI\u00f7\u001c\u00a2\u007fw\u00e3\u0088oWs\u001e\u008e\u00fa\u00b9\u008d *\u00da\u00dc\u0097\u00e3\u00c2du\u00e5\u00b7j\u0098\u0004Q\u00a1 \u00f5\u0013\u008b\u008a\u008f\u00e5\u00ad&\u009d\u00e5\u00c9\u001b!C\u00f2e\u00bd\u00b1\u00ec\u0080\u0002d","claimId":"27aad3c089dac2dbd205492d2cab32b7981f22d8","txid":"e905c8c42f6f728572d1d7bfe0d6f8559be0a594b63ffb4802cdef6f6bca3b4a","n":0,"amount":1000000,"effective amount":1000000,"height":365392},"error":null,"id":"curltest"} ``` So I think this might be an example of case sensitivity. Not sure why it is showing up yet in search.

tiger5226 commented

2018-05-10 02:16:10 +02:00

(Migrated from github.com)

It seems since 2018-05-04 01:33:24 nothing is syncing with elastic search. I can't find 1 channel after that time that appears in the search results. The sync loop of lighthouse had stopped. I restarted the service and all the queries are now successful.

https://lighthouse.lbry.io/search?s=free%20keene

tiger5226 commented

2018-05-10 02:37:21 +02:00

(Migrated from github.com)

After reviewing the logs in detail:

Apr 30 02:14:33 lighthouse node[3379]: 2018-04-30T02:14:32.855Z - info: WARNING: 2018-04-30T02:14:32Z
Apr 30 02:14:33 lighthouse node[3379]:   Unable to revive connection: http://localhost:9200/
Apr 30 02:14:33 lighthouse systemd[1]: lighthouse.service: Main process exited, code=exited, status=1/FAILURE
Apr 30 02:14:33 lighthouse systemd[1]: lighthouse.service: Unit entered failed state.
Apr 30 02:14:33 lighthouse systemd[1]: lighthouse.service: Failed with result 'exit-code'.
Apr 30 02:14:34 lighthouse systemd[1]: lighthouse.service: Service hold-off time over, scheduling restart.
Apr 30 02:14:34 lighthouse systemd[1]: Stopped "Lighthouse server".
Apr 30 02:14:34 lighthouse systemd[1]: Started "Lighthouse server".
Apr 30 02:15:34 lighthouse node[3442]: Elasticsearch WARNING: 2018-04-30T02:15:34Z
Apr 30 02:15:34 lighthouse node[3442]:   Unable to revive connection: http://localhost:9200/
Apr 30 02:15:34 lighthouse node[3442]: Elasticsearch WARNING: 2018-04-30T02:15:34Z
Apr 30 02:15:34 lighthouse node[3442]:   No living connections
Apr 30 02:15:52 lighthouse node[3442]:   <-- GET /status

It appears that the sync hasn't run since the last deployment. After the issues with elasticsearch node, the sync loop failed because elastic search was not started yet. The Search API worked when tested though because between the service restarts lighthouse connected to the elastic search node. However, since the sync process is just a loop, if it is interrupted like it was it will never restart until the service is restarted.

After reviewing the logs in detail: ``` Apr 30 02:14:33 lighthouse node[3379]: 2018-04-30T02:14:32.855Z - info: WARNING: 2018-04-30T02:14:32Z Apr 30 02:14:33 lighthouse node[3379]: Unable to revive connection: http://localhost:9200/ Apr 30 02:14:33 lighthouse systemd[1]: lighthouse.service: Main process exited, code=exited, status=1/FAILURE Apr 30 02:14:33 lighthouse systemd[1]: lighthouse.service: Unit entered failed state. Apr 30 02:14:33 lighthouse systemd[1]: lighthouse.service: Failed with result 'exit-code'. Apr 30 02:14:34 lighthouse systemd[1]: lighthouse.service: Service hold-off time over, scheduling restart. Apr 30 02:14:34 lighthouse systemd[1]: Stopped "Lighthouse server". Apr 30 02:14:34 lighthouse systemd[1]: Started "Lighthouse server". Apr 30 02:15:34 lighthouse node[3442]: Elasticsearch WARNING: 2018-04-30T02:15:34Z Apr 30 02:15:34 lighthouse node[3442]: Unable to revive connection: http://localhost:9200/ Apr 30 02:15:34 lighthouse node[3442]: Elasticsearch WARNING: 2018-04-30T02:15:34Z Apr 30 02:15:34 lighthouse node[3442]: No living connections Apr 30 02:15:52 lighthouse node[3442]: <-- GET /status ``` It appears that the sync hasn't run since the last deployment. After the issues with elasticsearch node, the sync loop failed because elastic search was not started yet. The Search API worked when tested though because between the service restarts lighthouse connected to the elastic search node. However, since the sync process is just a loop, if it is interrupted like it was it will never restart until the service is restarted.

This discussion has been locked. Commenting is limited to contributors.