Establishing connection to maker hangs

The maker seems to be running normally.
Starting the taker, the UI is up but it does not connect to the maker.
No logs on either side show that the taker tried to connect
2021-11-30 01:40:46  INFO Lock transaction published with txid c96d8ac6ebed953d885c416b0f7295d27c115f21b340d94a8999ef27e21b1515
2021-11-30 01:40:47 DEBUG Taker actor system ready
2021-11-30 01:40:48  INFO Connected to BitMex realtime API
2021-11-30 01:40:48 DEBUG Resolved umbrel.local:9999 to [<IP_ADDRESS>:9999,[fe80::829c:39f3:c31e:35c2]:9999]
2021-11-30 01:40:48  INFO No connection to the maker, attempting to connect:
2021-11-30 01:40:48  WARN 🔧 Configured for release.
2021-11-30 01:40:48  WARN address: <IP_ADDRESS>
2021-11-30 01:40:48  WARN port: 8000
2021-11-30 01:40:48  WARN workers: 4
2021-11-30 01:40:48  WARN ident: Rocket
2021-11-30 01:40:48  WARN limits: bytes = 8KiB, data-form = 2MiB, file = 1MiB, form = 32KiB, json = 1MiB, msgpack = 1MiB, string = 8KiB
2021-11-30 01:40:48  WARN temp dir: /tmp
2021-11-30 01:40:48  WARN keep-alive: 5s
2021-11-30 01:40:48  WARN tls: disabled
2021-11-30 01:40:48  WARN shutdown: ctrlc = true, force = true, signals = [SIGTERM], grace = 2s, mercy = 3s
2021-11-30 01:40:48  WARN log level: critical
2021-11-30 01:40:48  WARN cli colors: true
2021-11-30 01:40:48  WARN 📬 Routes:
2021-11-30 01:40:48  WARN (index) GET /<_paths..> text/html
2021-11-30 01:40:48  WARN (dist) GET /assets/<file..>
2021-11-30 01:40:48  WARN (feed) GET /api/feed
2021-11-30 01:40:48  WARN (get_health_check) GET /api/alive
2021-11-30 01:40:48  WARN (post_withdraw_request) POST /api/withdraw
2021-11-30 01:40:48  WARN (post_order_request) POST /api/cfd/order
2021-11-30 01:40:48  WARN (margin_calc) POST /api/calculate/margin
2021-11-30 01:40:48  WARN (post_cfd_action) POST /api/cfd/<id>/<action>
2021-11-30 01:40:48  WARN 📡 Fairings:
2021-11-30 01:40:48  WARN Shield (liftoff, response, singleton)
2021-11-30 01:40:48  INFO 🛡 Shield:
2021-11-30 01:40:48  WARN 🚀 Rocket has launched from http://<IP_ADDRESS>:8000
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T03:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-12-01T02:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T20:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T08:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T14:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T15:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T21:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T09:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T10:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T04:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T22:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T16:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T11:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T23:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T05:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-12-01T00:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-12-01T01:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T12:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T13:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T17:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T06:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T07:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T18:00:00.price?n=20
2021-11-30 01:40:52 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T19:00:00.price?n=20
2021-11-30 01:41:06 DEBUG Found relevant Bitcoin transaction txid=c96d8ac6ebed953d885c416b0f7295d27c115f21b340d94a8999ef27e21b1515 status=in mempool
2021-11-30 01:41:45  INFO GET /alive:
2021-11-30 01:42:15  WARN Error on websocket stream: WebSocket protocol error: Connection reset without closing handshake
2021-11-30 01:42:15  WARN Failed to read quote from websocket
2021-11-30 01:43:20  INFO GET /alive:
2021-11-30 01:43:45  INFO GET /alive:
^C2021-11-30 01:44:02  WARN Received SIGINT. Requesting shutdown.
2021-11-30 01:44:02  INFO Received shutdown request. Waiting for pending I/O...

maker log
2021-11-30 12:26:36  INFO Initialized logger
2021-11-30 12:26:36  INFO Running version: 0.1.2
2021-11-30 12:26:39  INFO Authentication details: username='maker' password='61e098d3791aaa2c64b90cc67dfceadcaa7100e39a57426a2aa5b23034fb5906', noise_public_key='69a42aa90da8b065b9532b62bff940a3ba07dbbb11d4482c7db83a7e049a9f1e'
2021-11-30 12:26:39  INFO Listening on <IP_ADDRESS>:9999
2021-11-30 12:26:40 ERROR Broadcasting transaction failed. Txid: 83fed9c0677fb30324494598bd5bf6e337f6a737d217893984bb6a4a5ff1ffd3. Raw transaction:<PHONE_NUMBER>01028d96dd5c90f512f36dc0e00da71b0f31a4ffbffd627b2ed5a17c34d75ef561d90000000000ffffffff92191b86ad41d9c25dafa276331debcd9bf3782f6b2cc6ac9a009c27669fe33f0100000000ffffffff03df65000000000000220020e00980a75447cfeb32059a78c7e5457fae209a2b88bc1055f5dae52c2d6c3491d151020000000000160014f32ec9844f11a0c09e491d8073a35f462234f8e955270100000000001600147ff6eac06f3db0e0db09d6458f88fba22dc6cd9a0247304402200610bc3a508f0e79b69725ce33c8508d750ad7b7a13ed4c1fcf2add622efe5d2022054c974f56d77beae0258305938809a90dbf3fcd97152348df99217e6dfe886820121027a317b986bceb60b5a65a71e11294ab96cdf10f0ae73998d7962b2370838be820247304402205fadab625736750a0da5174efe61866e3886b8c5ae6bbdb119810c55a2035c6b02201cee69e7c9470845c3c3da8c23471174cd1f69035a77b8d3ea9e483d653d4758012102be4bfaa2abac6a187c6d5432da5720a447b315928d3b56c8a9c335db9b9f7ee400000000: Electrum(Protocol(String("sendrawtransaction RPC error: {\"code\":-25,\"message\":\"bad-txns-inputs-missingorspent\"}")))
2021-11-30 12:26:41 DEBUG Fetching attestation for /x/BitMEX/BXBT/2021-11-30T01:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T03:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T04:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T05:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T06:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T16:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T11:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T07:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T08:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T09:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T21:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T17:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T12:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T10:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T18:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T19:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T20:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T22:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T14:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Maker actor system ready
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T23:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T15:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-12-01T01:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-11-30T13:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-12-01T00:00:00.price?n=20
2021-11-30 12:26:41 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-12-01T02:00:00.price?n=20
2021-11-30 12:26:42  INFO Fetched new attestation for /x/BitMEX/BXBT/2021-11-30T01:00:00.price?n=20
2021-11-30 12:26:42 DEBUG Learnt latest oracle attestation for event: /x/BitMEX/BXBT/2021-11-30T01:00:00.price?n=20
2021-11-30 12:26:43  INFO Connected to BitMex realtime API
2021-11-30 12:26:43  WARN 🔧 Configured for release.
2021-11-30 12:26:43  WARN address: <IP_ADDRESS>
2021-11-30 12:26:43  WARN port: 8000
2021-11-30 12:26:43  WARN workers: 4
2021-11-30 12:26:43  WARN ident: Rocket
2021-11-30 12:26:43  WARN limits: bytes = 8KiB, data-form = 2MiB, file = 1MiB, form = 32KiB, json = 1MiB, msgpack = 1MiB, string = 8KiB
2021-11-30 12:26:43  WARN temp dir: /tmp
2021-11-30 12:26:43  WARN keep-alive: 5s
2021-11-30 12:26:43  WARN tls: disabled
2021-11-30 12:26:43  WARN shutdown: ctrlc = true, force = true, signals = [SIGTERM], grace = 2s, mercy = 3s
2021-11-30 12:26:43  WARN log level: critical
2021-11-30 12:26:43  WARN cli colors: true
2021-11-30 12:26:43  WARN 📬 Routes:
2021-11-30 12:26:43  WARN (index) GET /<_paths..> text/html
2021-11-30 12:26:43  WARN (dist) GET /assets/<file..>
2021-11-30 12:26:43  WARN (maker_feed) GET /api/feed
2021-11-30 12:26:43  WARN (get_health_check) GET /api/alive
2021-11-30 12:26:43  WARN (post_withdraw_request) POST /api/withdraw
2021-11-30 12:26:43  WARN (post_sell_order) POST /api/order/sell
2021-11-30 12:26:43  WARN (post_cfd_action) POST /api/cfd/<id>/<action>
2021-11-30 12:26:43  WARN 🥅 Catchers:
2021-11-30 12:26:43  WARN (unauthorized) 401
2021-11-30 12:26:43  WARN (unauthorized) /api 401
2021-11-30 12:26:43  WARN 📡 Fairings:
2021-11-30 12:26:43  WARN Shield (liftoff, response, singleton)
2021-11-30 12:26:43  INFO 🛡 Shield:
2021-11-30 12:26:43  WARN 🚀 Rocket has launched from http://<IP_ADDRESS>:8000
2021-11-30 12:26:43 ERROR Error when trying to publish CET: Cannot publish CET in state Pending Open
2021-11-30 12:26:43 ERROR Cannot transition to OpenCommitted because of unexpected state Open Committed
2021-11-30 12:26:43  INFO GET /api/feed text/event-stream:
2021-11-30 12:26:44  INFO POST /api/order/sell application/json:
2021-11-30 12:26:46 DEBUG Noise protocol responder handshake is complete
2021-11-30 12:26:46  INFO New taker connected taker_id=7b451067e235fdf35b758fad8842281c039e7914c5e880e8d608f2f1e09fbb45 address=<IP_ADDRESS>:54851
2021-11-30 12:26:52 DEBUG Noise protocol responder handshake is complete
2021-11-30 12:26:52  INFO New taker connected taker_id=2d9ef5b81d303c9bba1715815a7cc5fa5c91af0542b691d02ab31a46bfa40d7a address=<IP_ADDRESS>:54971
2021-11-30 12:27:01 DEBUG Found relevant Bitcoin transaction txid=d43db0eb8badcb72b1a3c9e354bb9242e167b03672dd74265ab6f615fa2bf769 status=confirmed with 2 blocks
2021-11-30 12:27:15  INFO POST /api/order/sell application/json:
2021-11-30 12:27:36 ERROR Closing connection to taker 7b451067e235fdf35b758fad8842281c039e7914c5e880e8d608f2f1e09fbb45
2021-11-30 12:27:46 DEBUG Noise protocol responder handshake is complete
2021-11-30 12:27:46  INFO New taker connected taker_id=7b451067e235fdf35b758fad8842281c039e7914c5e880e8d608f2f1e09fbb45 address=<IP_ADDRESS>:54858
2021-11-30 12:28:03 DEBUG Noise protocol responder handshake is complete
2021-11-30 12:28:03  INFO New taker connected taker_id=4d6457ba4f39267b08b02d5f03f17dcaed7ddefedd8a39c3636b1e46e1018e06 address=<IP_ADDRESS>:61215
2021-11-30 12:28:15  INFO POST /api/order/sell application/json:
2021-11-30 12:28:25 ERROR Closing connection to taker 7b451067e235fdf35b758fad8842281c039e7914c5e880e8d608f2f1e09fbb45
2021-11-30 12:29:01 DEBUG Got notification for new block block_height=2105766
2021-11-30 12:29:01 DEBUG Bitcoin transaction status changed txid=d43db0eb8badcb72b1a3c9e354bb9242e167b03672dd74265ab6f615fa2bf769 new_status=confirmed with 3 blocks old_status=confirmed with 2 blocks
2021-11-30 12:29:07 DEBUG Noise protocol responder handshake is complete
2021-11-30 12:29:07  INFO New taker connected taker_id=ba4a7001bb1debc4e355f971e7e87409281865691ae64cbd9c8cfac1a07da442 address=<IP_ADDRESS>:42612
2021-11-30 12:29:15  INFO POST /api/order/sell application/json:
2021-11-30 12:29:15  INFO Failed to send CurrentOrder to taker, removing connection taker_id=7b451067e235fdf35b758fad8842281c039e7914c5e880e8d608f2f1e09fbb45
2021-11-30 12:30:15  WARN Error on websocket stream: WebSocket protocol error: Connection reset without closing handshake
2021-11-30 12:30:15  WARN Failed to read quote from websocket
2021-11-30 12:33:42  INFO GET / text/html:
2021-11-30 12:33:42  INFO GET /assets/index.08fbfe68.css text/css:
2021-11-30 12:33:42  INFO GET /assets/index.478e7f1a.js:
2021-11-30 12:33:42  INFO GET /assets/vendor.68f88f6e.js:
2021-11-30 12:33:42  INFO GET /assets/vendor.68f88f6e.js:
2021-11-30 12:33:42  INFO GET /api/feed text/event-stream:
2021-11-30 12:33:42  INFO GET /favicon.svg image/avif:
2021-11-30 12:33:42 ERROR No matching routes for GET /favicon.svg image/avif.
2021-11-30 12:35:03 ERROR Failed to write message Heartbeat to socket: Broken pipe (os error 32)

2021-11-30 12:36:39  INFO GET / text/html:
2021-11-30 12:36:39  INFO GET /assets/index.478e7f1a.js:
2021-11-30 12:36:39  INFO GET /assets/index.08fbfe68.css text/css:
2021-11-30 12:36:39  INFO GET /assets/vendor.68f88f6e.js:
2021-11-30 12:36:39  INFO GET /assets/vendor.68f88f6e.js:
2021-11-30 12:36:39  INFO GET /api/feed text/event-stream:
2021-11-30 12:36:39  INFO GET /favicon.svg image/avif:
2021-11-30 12:36:39 ERROR No matching routes for GET /favicon.svg image/avif.
2021-11-30 12:38:03  INFO POST /api/order/sell application/json:
2021-11-30 12:38:06  INFO GET / text/html:
2021-11-30 12:38:06  INFO GET /assets/index.478e7f1a.js:
2021-11-30 12:38:06  INFO GET /assets/index.08fbfe68.css text/css:
2021-11-30 12:38:06  INFO GET /assets/vendor.68f88f6e.js:
2021-11-30 12:38:07  INFO GET /assets/vendor.68f88f6e.js:
2021-11-30 12:38:07  INFO GET /api/feed text/event-stream:
2021-11-30 12:38:08  INFO GET /favicon.svg image/avif:
2021-11-30 12:38:08 ERROR No matching routes for GET /favicon.svg image/avif.
2021-11-30 12:38:10  INFO POST /api/order/sell application/json:
2021-11-30 12:40:22  INFO GET / text/html:
2021-11-30 12:40:22  INFO GET /assets/index.478e7f1a.js:
2021-11-30 12:40:22  INFO GET /assets/index.08fbfe68.css text/css:
2021-11-30 12:40:22  INFO GET /assets/vendor.68f88f6e.js:
2021-11-30 12:40:22  INFO GET /assets/vendor.68f88f6e.js:
2021-11-30 12:40:22  INFO GET /api/feed text/event-stream:
2021-11-30 12:40:23  INFO GET /favicon.svg image/avif:
2021-11-30 12:40:23 ERROR No matching routes for GET /favicon.svg image/avif.
2021-11-30 12:40:26  INFO POST /api/order/sell application/json:
2021-11-30 12:40:32  INFO GET / text/html:
2021-11-30 12:40:32  INFO GET /assets/index.478e7f1a.js:
2021-11-30 12:40:32  INFO GET /assets/index.08fbfe68.css text/css:
2021-11-30 12:40:32  INFO GET /assets/vendor.68f88f6e.js:
2021-11-30 12:40:33  INFO GET /assets/vendor.68f88f6e.js:
2021-11-30 12:40:33  INFO GET /api/feed text/event-stream:
2021-11-30 12:40:33  INFO GET /favicon.svg image/avif:
2021-11-30 12:40:33 ERROR No matching routes for GET /favicon.svg image/avif.
2021-11-30 12:43:35  INFO GET / text/html:
2021-11-30 12:43:35  INFO GET /assets/index.478e7f1a.js:
2021-11-30 12:43:35  INFO GET /assets/index.08fbfe68.css text/css:
2021-11-30 12:43:35  INFO GET /assets/vendor.68f88f6e.js:
2021-11-30 12:43:36  INFO GET /assets/vendor.68f88f6e.js:
2021-11-30 12:43:36  INFO GET /api/feed text/event-stream:
2021-11-30 12:43:36  INFO GET /favicon.svg image/avif:
2021-11-30 12:43:36 ERROR No matching routes for GET /favicon.svg image/avif.

I can see that the taker has been running for only about a minute in your logs. Can you verify that it actually never connected or is it simply just in the process of connecting and has not yet run into a timeout?

I've updated the title to reflect the actual problem. There is no error reported meaning we don't actually know for sure whether or not it "cannot establish" the connection.

I can see that the taker has been running for only about a minute in your logs. Can you verify that it actually never connected or is it simply just in the process of connecting and has not yet run into a timeout?

I've updated the log with the last few lines I had before terminating it. In this case it was running just shy of 4 minutes. Maybe @da-kami has some more logs from his taker?

I've updated the title to more closely reflect problem. There is no error reported meaning we don't actually know for sure whether or not it "cannot establish" the connection.

sounds reasonable.

Tried to reproduce this, but was unable to at the moment. Stopping here for now.

wups, didn't want to close this .
It just happened again. The maker seem to have died, maybe a deadlock situation. This is the last log which might be relevant:
2021-11-30 14:57:15  INFO Failed to send CurrentOrder to taker, removing connection taker_id=7b451067e235fdf35b758fad8842281c039e7914c5e880e8d608f2f1e09fbb45
2021-11-30 14:57:16  INFO POST /api/order/sell application/json:
2021-11-30 15:00:04 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-12-01T05:00:00.price?n=20
2021-11-30 15:00:13 DEBUG Got notification for new block block_height=2105780
2021-11-30 15:20:13 DEBUG Got notification for new block block_height=2105781
2021-11-30 15:29:13 DEBUG Got notification for new block block_height=2105782
2021-11-30 15:49:13 DEBUG Got notification for new block block_height=2105783

afterwards nothing.

I am having trouble establishing a connection to the maker again.
I never see a Connection Established message. This is weird because connecting is wrapped in a timeout now.
@thomaseizinger I think we have a deadlock somewhere, where in some cases messages are just not being passed on. I could not track down where yet.
2021-12-02 22:16:30 DEBUG daemon: Taker actor system ready
2021-12-02 22:16:30 DEBUG daemon::bitmex_price_feed: Connecting to BitMex realtime API
2021-12-02 22:16:31  INFO daemon::bitmex_price_feed: Connected to BitMex realtime API
2021-12-02 22:16:31 DEBUG taker: Resolved <IP_ADDRESS>:9999 to [<IP_ADDRESS>:9999]
2021-12-02 22:16:31 DEBUG daemon::connection: No connection to the maker
2021-12-02 22:16:31 DEBUG daemon::connection: Connecting to maker address=<IP_ADDRESS>:9999
2021-12-02 22:16:31  WARN rocket::launch: 🔧 Configured for release.
2021-12-02 22:16:31  WARN rocket::launch_: address: <IP_ADDRESS>
2021-12-02 22:16:31  WARN rocket::launch_: port: 8000
2021-12-02 22:16:31  WARN rocket::launch_: workers: 4
2021-12-02 22:16:31  WARN rocket::launch_: ident: Rocket
2021-12-02 22:16:31  WARN rocket::launch_: limits: bytes = 8KiB, data-form = 2MiB, file = 1MiB, form = 32KiB, json = 1MiB, msgpack = 1MiB, string = 8KiB
2021-12-02 22:16:31  WARN rocket::launch_: temp dir: /tmp
2021-12-02 22:16:31  WARN rocket::launch_: keep-alive: 5s
2021-12-02 22:16:31  WARN rocket::launch_: tls: disabled
2021-12-02 22:16:31  WARN rocket::launch_: shutdown: ctrlc = true, force = true, signals = [SIGTERM], grace = 2s, mercy = 3s
2021-12-02 22:16:31  WARN rocket::launch_: log level: critical
2021-12-02 22:16:31  WARN rocket::launch_: cli colors: true
2021-12-02 22:16:31  WARN rocket::launch: 📬 Routes:
2021-12-02 22:16:31  WARN rocket::launch_: (index) GET /<_paths..> text/html
2021-12-02 22:16:31  WARN rocket::launch_: (dist) GET /assets/<file..>
2021-12-02 22:16:31  WARN rocket::launch_: (feed) GET /api/feed
2021-12-02 22:16:31  WARN rocket::launch_: (get_health_check) GET /api/alive
2021-12-02 22:16:31  WARN rocket::launch_: (post_withdraw_request) POST /api/withdraw
2021-12-02 22:16:31  WARN rocket::launch_: (post_order_request) POST /api/cfd/order
2021-12-02 22:16:31  WARN rocket::launch_: (margin_calc) POST /api/calculate/margin
2021-12-02 22:16:31  WARN rocket::launch_: (post_cfd_action) POST /api/cfd/<id>/<action>
2021-12-02 22:16:31  WARN rocket::launch: 📡 Fairings:
2021-12-02 22:16:31  WARN rocket::launch_: Shield (liftoff, response, singleton)
2021-12-02 22:16:31  INFO rocket::shield::shield: 🛡 Shield:
2021-12-02 22:16:31  WARN rocket::launch: 🚀 Rocket has launched from http://<IP_ADDRESS>:8000
2021-12-02 22:16:35  INFO rocket::server: GET /alive:
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T03:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T23:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T13:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T14:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T08:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T00:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T09:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T10:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T15:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T11:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T01:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T16:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T02:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T12:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T19:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T20:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T17:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T18:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T21:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T04:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T06:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T07:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T22:00:00.price?n=20
2021-12-02 22:16:35 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-03T05:00:00.price?n=20
2021-12-02 22:16:40  INFO rocket::server: GET /alive:
2021-12-02 22:16:45  INFO rocket::server: GET /alive:
2021-12-02 22:16:48  INFO rocket::server: GET / text/html:
2021-12-02 22:16:48  INFO rocket::server: GET /assets/index.151ea18f.js:
2021-12-02 22:16:48  INFO rocket::server: GET /assets/index.08fbfe68.css text/css:
2021-12-02 22:16:48  INFO rocket::server: GET /assets/vendor.fa58af1e.js:
2021-12-02 22:16:48  INFO rocket::server: GET /assets/vendor.fa58af1e.js:
2021-12-02 22:16:48  INFO rocket::server: GET /api/feed text/event-stream:
2021-12-02 22:16:48  INFO rocket::server: GET /assets/logo_nav_bar_black.c442b25d.svg image/avif:
2021-12-02 22:16:48  INFO rocket::server: GET /assets/logo.a37cce62.svg image/avif:
2021-12-02 22:16:55  INFO rocket::server: GET /alive:
2021-12-02 22:17:00  INFO rocket::server: GET /alive:
2021-12-02 22:17:00  INFO rocket::server: GET /alive:
2021-12-02 22:17:00  INFO rocket::server: GET /alive:
2021-12-02 22:17:20  INFO rocket::server: GET /alive:
2021-12-02 22:17:22  INFO rocket::server: GET / text/html:
2021-12-02 22:17:22  INFO rocket::server: GET /assets/index.151ea18f.js:
2021-12-02 22:17:22  INFO rocket::server: GET /assets/index.08fbfe68.css text/css:
2021-12-02 22:17:22  INFO rocket::server: GET /assets/vendor.fa58af1e.js:
2021-12-02 22:17:22  INFO rocket::server: GET /assets/vendor.fa58af1e.js:
2021-12-02 22:17:22  INFO rocket::server: GET /api/feed text/event-stream:
2021-12-02 22:17:22  INFO rocket::server: GET /assets/logo_nav_bar_black.c442b25d.svg image/avif:
2021-12-02 22:17:22  INFO rocket::server: GET /assets/logo.a37cce62.svg image/avif:
2021-12-02 22:17:35  INFO rocket::server: GET /alive:
2021-12-02 22:17:35  INFO rocket::server: GET /alive:
2021-12-02 22:17:50  INFO rocket::server: GET /alive:
2021-12-02 22:17:50  INFO rocket::server: GET /alive:
2021-12-02 22:18:00  INFO rocket::server: GET /alive:
2021-12-02 22:18:15  WARN daemon::bitmex_price_feed: Connection to BitMex realtime API failed: WebSocket protocol error: Connection reset without closing handshake: Connection reset without closing handshake
2021-12-02 22:18:15 DEBUG daemon::bitmex_price_feed: Connecting to BitMex realtime API
2021-12-02 22:18:16  INFO daemon::bitmex_price_feed: Connected to BitMex realtime API
2021-12-02 22:18:35  INFO rocket::server: GET /alive:
2021-12-02 22:18:35  INFO rocket::server: GET /alive:
2021-12-02 22:18:40  INFO rocket::server: GET /alive:
2021-12-02 22:18:55  INFO rocket::server: GET /alive:
2021-12-02 22:19:15  INFO rocket::server: GET /alive:
2021-12-02 22:19:20  INFO rocket::server: GET /alive:
2021-12-02 22:19:20  INFO rocket::server: GET /alive:
2021-12-02 22:19:25  INFO rocket::server: GET /alive:
2021-12-02 22:19:25  INFO rocket::server: GET /alive:
2021-12-02 22:19:31  INFO rocket::server: GET /alive:
2021-12-02 22:19:31  INFO rocket::server: GET /alive:
2021-12-02 22:19:31  INFO rocket::server: GET /alive:
2021-12-02 22:19:31  INFO rocket::server: GET /alive:
2021-12-02 22:19:40  INFO rocket::server: GET /alive:
2021-12-02 22:19:40  INFO rocket::server: GET /alive:
2021-12-02 22:19:40  INFO rocket::server: GET /alive:
2021-12-02 22:19:40  INFO rocket::server: GET /alive:
2021-12-02 22:19:40  INFO rocket::server: GET /alive:
2021-12-02 22:20:00  INFO rocket::server: GET /alive:
2021-12-02 22:20:00  INFO rocket::server: GET /alive:
2021-12-02 22:20:00  INFO rocket::server: GET /alive:
2021-12-02 22:20:00  INFO rocket::server: GET /alive:
2021-12-02 22:20:00  INFO rocket::server: GET /alive:
2021-12-02 22:20:10  INFO rocket::server: GET /alive:
2021-12-02 22:20:10  INFO rocket::server: GET /alive:
2021-12-02 22:20:10  INFO rocket::server: GET /alive:
2021-12-02 22:20:10  INFO rocket::server: GET /alive:
2021-12-02 22:20:10  INFO rocket::server: GET /alive:
2021-12-02 22:20:15  WARN daemon::bitmex_price_feed: Connection to BitMex realtime API failed: WebSocket protocol error: Connection reset without closing handshake: Connection reset without closing handshake
2021-12-02 22:20:15 DEBUG daemon::bitmex_price_feed: Connecting to BitMex realtime API
2021-12-02 22:20:16  INFO daemon::bitmex_price_feed: Connected to BitMex realtime API
2021-12-02 22:20:20  INFO rocket::server: GET /alive:
2021-12-02 22:20:20  INFO rocket::server: GET /alive:
2021-12-02 22:20:20  INFO rocket::server: GET /alive:
2021-12-02 22:20:30  INFO rocket::server: GET /alive:
2021-12-02 22:20:30  INFO rocket::server: GET /alive:
2021-12-02 22:20:40  INFO rocket::server: GET /alive:
2021-12-02 22:20:40  INFO rocket::server: GET /alive:
2021-12-02 22:20:40  INFO rocket::server: GET /alive:
2021-12-02 22:20:40  INFO rocket::server: GET /alive:
2021-12-02 22:20:55  INFO rocket::server: GET /alive:

Ideas for steps forward:

Create and setup a simple application that connects to the maker and records the maker's heartbeats. If the maker cannot be reached then ping us (or ping some task automated to restart the maker).
Add log analysis tool to the maker so we gather more information when this problem happens and what goes wrong.

Create and setup a simple application that connects to the maker and records the maker's heartbeats. If the maker cannot be reached then ping us (or ping some task automated to restart the maker).

You could run that tool locally in a cronjob and if it fails to connect, restart the maker as a result. Should be fairly easy to wire together using systemd services :)

Create and setup a simple application that connects to the maker and records the maker's heartbeats. If the maker cannot be reached then ping us (or ping some task automated to restart the maker).

You could run that tool locally in a cronjob and if it fails to connect, restart the maker as a result. Should be fairly easy to wire together using systemd services :)
Edit: I forgot that we are releasing via docker now. Shouldn't be too hard to also restart the docker container.

This is under the assumption that the local connection the maker is broken as well, but I think that is a fair assumption for now :)

We can't really do anything here at the moment, because the issue is not reproduceable. Removing it from the Umbrel milestone but keeping the ticket open for now.

@thomaseizinger : this turns out to be a critical bug. We ran into this again where the maker seemly hangs.
It's hard to say if this is the problem but the maker log says that a taker tried to connect twice and keeps connecting
Dec 14 23:48:00 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:48:00 DEBUG daemon::monitor: Got notification for new block block_height=714184
Dec 14 23:48:15 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:48:15  INFO rocket::server: POST /api/order/sell application/json:
Dec 14 23:48:45 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:48:45 DEBUG daemon::noise: Noise protocol responder handshake is complete
Dec 14 23:48:45 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:48:45  INFO daemon::maker_inc_connections: New taker connected taker_id=c9fcad805164d53e1cd7e3aaab616b30cbe98eb4c279441530bfe28ed9be5375 address=<IP_ADDRESS>:33602
Dec 14 23:48:45 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:48:45  WARN daemon::maker_cfd: Taker already connected: Identity(PublicKey(MontgomeryPoint([201, 252, 173, 128, 81, 100, 213, 62, 28, 215, 227, 170, 171, 97, 107, 48, 203, 233, >
Dec 14 23:49:15 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:49:15  INFO rocket::server: POST /api/order/sell application/json:
Dec 14 23:50:05 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:50:05 DEBUG daemon::noise: Noise protocol responder handshake is complete
Dec 14 23:50:05 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:50:05  INFO daemon::maker_inc_connections: New taker connected taker_id=c9fcad805164d53e1cd7e3aaab616b30cbe98eb4c279441530bfe28ed9be5375 address=x.x.x.x:36862
Dec 14 23:50:05 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:50:05  WARN daemon::maker_cfd: Taker already connected: Identity(PublicKey(MontgomeryPoint([201, 252, 173, 128, 81, 100, 213, 62, 28, 215, 227, 170, 171, 97, 107, 48, 203, 233, >
Dec 14 23:50:15 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:50:15  INFO rocket::server: POST /api/order/sell application/json:
D

@thomaseizinger : this turns out to be a critical bug. We ran into this again where the maker seemly hangs.
It's hard to say if this is the problem but the maker log says that a taker tried to connect twice and keeps connecting
Dec 14 23:48:00 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:48:00 DEBUG daemon::monitor: Got notification for new block block_height=714184
Dec 14 23:48:15 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:48:15  INFO rocket::server: POST /api/order/sell application/json:
Dec 14 23:48:45 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:48:45 DEBUG daemon::noise: Noise protocol responder handshake is complete
Dec 14 23:48:45 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:48:45  INFO daemon::maker_inc_connections: New taker connected taker_id=c9fcad805164d53e1cd7e3aaab616b30cbe98eb4c279441530bfe28ed9be5375 address=<IP_ADDRESS>:33602
Dec 14 23:48:45 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:48:45  WARN daemon::maker_cfd: Taker already connected: Identity(PublicKey(MontgomeryPoint([201, 252, 173, 128, 81, 100, 213, 62, 28, 215, 227, 170, 171, 97, 107, 48, 203, 233, >
Dec 14 23:49:15 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:49:15  INFO rocket::server: POST /api/order/sell application/json:
Dec 14 23:50:05 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:50:05 DEBUG daemon::noise: Noise protocol responder handshake is complete
Dec 14 23:50:05 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:50:05  INFO daemon::maker_inc_connections: New taker connected taker_id=c9fcad805164d53e1cd7e3aaab616b30cbe98eb4c279441530bfe28ed9be5375 address=x.x.x.x:36862
Dec 14 23:50:05 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:50:05  WARN daemon::maker_cfd: Taker already connected: Identity(PublicKey(MontgomeryPoint([201, 252, 173, 128, 81, 100, 213, 62, 28, 215, 227, 170, 171, 97, 107, 48, 203, 233, >
Dec 14 23:50:15 mainnet-maker 40c318dfaba8[358]: 2021-12-15 10:50:15  INFO rocket::server: POST /api/order/sell application/json:
D

To add a bit more context from the taker side:
Both maker and taker containers had been running without a restart for several days. My taker was running within Umbrel. I brought up the UI and everything seemed fine (in retrospect we noticed that the price to the maker seemed outdated), we did not see any errors. The UI did not report that we are not connected to a maker.
We restarted taker and maker containers. I had one faile
I grepped the logs for errors. I don't see any relevant errors besides one that I had upon restarting (but I think that one is related to a maker restart):
2021-12-15 22:16:11 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2021-12-22T10:00:00.price?n=20
2021-12-15 22:16:15  WARN daemon::connection: Failed to establish connection: Connection reset by peer (os error 104) address=<IP_ADDRESS>:9999
2021-12-15 22:16:15  WARN daemon::connection: Tried connecting to 1 addresses without success, retrying in 5 seconds
2021-12-15 22:16:20 DEBUG daemon::connection: Connecting to maker address=<IP_ADDRESS>:9999

There are not error messages concerning a maker disconnect (from 09.12. till 16.12.).

I still think that the problem is not related to the connection actually being broken, but the maker running into a deadlock somehow, so incoming messages are not processed correctly.

I still think that the problem is not related to the connection actually being broken, but the maker running into a deadlock somehow, so incoming messages are not processed correctly.

I verify this, we need more logs. None of the above logs show heartbeats for example. It would be good to see whether or not those are still sent or not.

I still think that the problem is not related to the connection actually being broken, but the maker running into a deadlock somehow, so incoming messages are not processed correctly.

I verify this, we need more logs. None of the above logs show heartbeats for example. It would be good to see whether or not those are still sent or not.

I agree, that is why I run the taker on trace now. Hopefully that will help track it down. I suspect that the taker still receives heartbeats (otherwise I should see a disconnected warning in the UI...). Hopefully I can prove it soon ;)

For debugging purposes:
RUST_LOG="info,maker=info,rocket=info,daemon::send_to_socket=trace,daemon=info" will make the maker print all messages sent to a socket. We will keep it running for a while to see if there is anything obvious.

I'm not sure it is related, but today during the demo the connection was dropped:
Maker log
2021-12-17 09:24:09 DEBUG daemon::maker_cfd: Maker accepts order order_id=77dd2f11-d70d-4d52-8f66-189a256baa36
2021-12-17 09:24:09  INFO daemon::setup_maker: Maker accepts an order order_id=77dd2f11-d70d-4d52-8f66-189a256baa36
2021-12-17 09:24:09 TRACE daemon::send_to_socket: Sending 'ConfirmOrder'
2021-12-17 09:24:10  INFO daemon::setup_contract: Exchanged setup parameters
2021-12-17 09:24:10  INFO rocket::server: POST /api/order/sell application/json:
2021-12-17 09:24:11  INFO daemon::setup_contract: Created CFD transactions
2021-12-17 09:24:11 TRACE daemon::send_to_socket: Sending 'Protocol'
2021-12-17 09:24:11 TRACE daemon::send_to_socket: Sending 'CurrentOrder'
2021-12-17 09:24:11 TRACE daemon::send_to_socket: Sending 'CurrentOrder'
2021-12-17 09:24:11 TRACE daemon::send_to_socket: Sending 'CurrentOrder'
2021-12-17 09:24:11 TRACE daemon::send_to_socket: Sending 'Protocol'
2021-12-17 09:24:12 TRACE daemon::send_to_socket: Sending 'Heartbeat'
2021-12-17 09:24:13 TRACE daemon::send_to_socket: Sending 'Heartbeat'
2021-12-17 09:24:13 TRACE daemon::send_to_socket: Sending 'Heartbeat'
2021-12-17 09:24:15  INFO rocket::server: POST /api/order/sell application/json:
2021-12-17 09:24:15 TRACE daemon::send_to_socket: Sending 'CurrentOrder'
2021-12-17 09:24:15 TRACE daemon::send_to_socket: Sending 'CurrentOrder'
2021-12-17 09:24:15 TRACE daemon::send_to_socket: Sending 'CurrentOrder'
2021-12-17 09:24:17 TRACE daemon::send_to_socket: Sending 'Heartbeat'
2021-12-17 09:24:18 TRACE daemon::send_to_socket: Sending 'Heartbeat'
2021-12-17 09:24:18 TRACE daemon::send_to_socket: Sending 'Heartbeat'
2021-12-17 09:24:22 TRACE daemon::send_to_socket: Sending 'Heartbeat'
2021-12-17 09:24:23 TRACE daemon::send_to_socket: Sending 'Heartbeat'
2021-12-17 09:24:23 TRACE daemon::send_to_socket: Sending 'Heartbeat'
2021-12-17 09:24:24 ERROR daemon::maker_inc_connections: Failed to read incoming messages from taker taker_id=9d4eb09b464ebda4c1e41e73b54f12bb8cb3ba8e9e1004af50a7dafcaeb6643a
2021-12-17 09:24:24  INFO daemon::maker_inc_connections: Dropping connection taker_id=9d4eb09b464ebda4c1e41e73b54f12bb8cb3ba8e9e1004af50a7dafcaeb6643a
2021-12-17 09:24:27 TRACE daemon::send_to_socket: Sending 'Heartbeat'

Taker log
2021-12-16 22:24:08  INFO daemon::taker_cfd: Taking current order: Order { id: OrderId(Hyphenated(77dd2f11-d70d-4d52-8f66-189a256baa36)), trading_pair: BtcUsd, position: Short, price: Price(48726.93), min_quantity: Usd(100), max_quantity: Usd(1000), leverage: Leverage(2), liquidation_price: Price(32484.62), creation_timestamp: Timestamp(1639693395), settlement_interval: Duration { seconds: 604800, nanoseconds: 0 }, origin: Theirs, oracle_event_id: BitMexPriceEventId { timestamp: OffsetDateTime { utc_datetime: PrimitiveDateTime { date: Date { year: 2021, ordinal: 357 }, time: Time { hour: 23, minute: 0, second: 0, nanosecond: 0 } }, offset: UtcOffset { hours: 0, minutes: 0, seconds: 0 } }, digits: 20 }, fee_rate: 11 }
2021-12-16 22:24:09  INFO daemon::setup_taker: Order got accepted order_id=77dd2f11-d70d-4d52-8f66-189a256baa36
2021-12-16 22:24:11  INFO daemon::setup_contract: Exchanged setup parameters
2021-12-16 22:24:12  INFO rocket::server: POST /api/calculate/margin application/json:
2021-12-16 22:24:16  INFO rocket::server: POST /api/calculate/margin application/json:
2021-12-16 22:24:17  INFO rocket::server: POST /api/calculate/margin application/json:
2021-12-16 22:24:17  INFO daemon::setup_contract: Created CFD transactions
2021-12-16 22:24:17  INFO daemon::setup_contract: Exchanged CFD transactions
2021-12-16 22:24:23  INFO daemon::setup_contract: Verified all signatures
2021-12-16 22:24:24 DEBUG daemon::connection: No connection to the maker
thread 'rocket-worker-thread' panicked at 'wire messages only to arrive in connected state', daemon/src/connection.rs:332:22
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
2021-12-16 22:24:25 ERROR daemon::taker_cfd: Contract setup failed: Error {
    context: "Failed to send Msg2",
    source: Disconnected,

afterwards, no connection anymore.

so it happened again, unfortunatelly I cannot find when it started.
The maker keeps sending heartbeats but internally something is broken. For example, I cannot post a new order: The endpoint gets called but no new order is being created (the uuid of the order I get on the feed does not change).
Maker log is pretty much useless, all it shows is the heartbeat:
2021-12-18 19:54:16 TRACE daemon::send_to_socket: Sending 'Heartbeat'
2021-12-18 19:54:20 TRACE daemon::send_to_socket: Sending 'Heartbeat'
2021-12-18 19:54:21 TRACE daemon::send_to_socket: Sending 'Heartbeat'
2021-12-18 19:54:25 TRACE daemon::send_to_socket: Sending 'Heartbeat'
2021-12-18 19:54:26 TRACE daemon::send_to_socket: Sending 'Heartbeat'
2021-12-18 19:54:30 TRACE daemon::send_to_socket: Sending 'Heartbeat'
2021-12-18 19:54:31 TRACE daemon::send_to_socket: Sending 'Heartbeat'

Here some more logs. It looks like it "just stopped working" after 20:12  .

That should give us an idea if there is any task that is being blocked.

In the meantime, I suggest we just restart every hour or so.

Can you compile the binary according to these instructions and attach tokio-console when it happens?
That should give us an idea if there is any task that is being blocked.

That's hard because this is happening on our server with the released version and I'm not sure if anyone was able to reproduce it locally yet.

That's hard because this is happening on our server with the released version and I'm not sure if anyone was able to reproduce it locally yet.

Can we not temporarily deploy a fork?

That's hard because this is happening on our server with the released version and I'm not sure if anyone was able to reproduce it locally yet.

Can we not temporarily deploy a fork?

I'll see if I can reproduce it locally first.

That's hard because this is happening on our server with the released version and I'm not sure if anyone was able to reproduce it locally yet.

Can we not temporarily deploy a fork?

I'll see if I can reproduce it locally first.

So I have the tokio-console running locally and gave all threads a name. I'll let it running locally to see if the problem happens locally as well but sofar I cannot say that I can learn a whole lot from this console 😬

So I have the tokio-console running locally and gave all threads a name. I'll let it running locally to see if the problem happens locally as well but sofar I cannot say that I can learn a whole lot from this console grimacing

Amazing! Let's see what it produces. I have never used it myself either but hopefully we can learn something from it!

I had it running locally over night and the problem did not happen :/ My guess, maybe it has something todo with release mode, so I'll rebuild and restart in release mode to see if that helps.
What's more worrying is that the quote did not update since Dec 19, 2021 8:49:00 PM, roughly 2h after start.:  #925

Latest change did not help unfortunately. I'll add the automated restart for now.

Latest change (for the 0.3.1 release) did not help unfortunately. I'll add the automated restart for now.

I'll backport #927 later.

Uptime ~50 minutes and no more orders being send out :(
2021-12-22 16:23:15 TRACE daemon::maker_inc_connections: Sent new order: Some(OrderId(Hyphenated(fb9cba4f-9f67-4170-b5df-cbd4401704fc))) taker_id=c9fcad805164d53e1cd7e3aaab616b30cbe98eb4c279441530bfe28ed9be5375
2021-12-22 16:23:15 TRACE daemon::maker_inc_connections: Sent new order: Some(OrderId(Hyphenated(fb9cba4f-9f67-4170-b5df-cbd4401704fc))) taker_id=766ff734dad13ae9286969981eb69772f140d0f14bcc37c3fc3a5214e25b1b08
2021-12-22 16:23:15 TRACE daemon::maker_inc_connections: Sent new order: Some(OrderId(Hyphenated(fb9cba4f-9f67-4170-b5df-cbd4401704fc))) taker_id=9d4eb09b464ebda4c1e41e73b54f12bb8cb3ba8e9e1004af50a7dafcaeb6643a
2021-12-22 16:23:15 TRACE daemon::maker_inc_connections: Sent new order: Some(OrderId(Hyphenated(fb9cba4f-9f67-4170-b5df-cbd4401704fc))) taker_id=d4cb45f05d06bfdf277349490200b15dfa69dcff47aab1201836958a5db6163f
2021-12-22 16:24:15  INFO rocket::server: POST /api/order/sell application/json:
2021-12-22 16:24:17 DEBUG daemon::monitor: Got notification for new block block_height=715196
2021-12-22 16:25:15  INFO rocket::server: POST /api/order/sell application/json:
2021-12-22 16:26:15  INFO rocket::server: POST /api/order/sell application/json:
2021-12-22 16:26:57 DEBUG daemon::monitor: Got notification for new block block_height=715197

This is probably unrelated, but in addition to the maker not reacting the taker does (sometimes) not reconnect (stops reconnecting timely):
2021-12-29 04:52:27  WARN daemon::connection: Failed to establish connection: Connection reset by peer (os error 104) address=<IP_ADDRESS>:9999
2021-12-29 04:52:27  WARN daemon::connection: Tried connecting to 1 addresses without success, retrying in 5 seconds
2021-12-29 04:52:32 DEBUG daemon::connection: Connecting to maker address=<IP_ADDRESS>:9999
2021-12-29 04:52:32 DEBUG daemon::noise: Noise protocol initiator handshake is complete
2021-12-29 04:52:32  INFO daemon::connection: Established connection to maker address=<IP_ADDRESS>:9999
2021-12-29 04:52:42 DEBUG daemon::connection: No connection to the maker
2021-12-29 04:52:42 DEBUG daemon::connection: Connecting to maker address=<IP_ADDRESS>:9999
2021-12-29 04:54:12  INFO rocket::server: GET / text/html:
2021-12-29 04:54:12  INFO rocket::server: GET /assets/index.1c44b86e.js:
2021-12-29 04:54:12  INFO rocket::server: GET /assets/index.08fbfe68.css text/css:
2021-12-29 04:54:12  INFO rocket::server: GET /assets/vendor.64f20ccd.js:
2021-12-29 04:54:12  INFO rocket::server: GET /assets/vendor.64f20ccd.js:
2021-12-29 04:54:12  INFO rocket::server: GET /api/feed text/event-stream:
2021-12-29 04:54:12  INFO rocket::server: GET /assets/logo_nav_bar_black.c442b25d.svg image/avif:
2021-12-29 04:54:13  INFO rocket::server: GET /assets/logo.a37cce62.svg image/avif:
2021-12-29 04:55:42 DEBUG daemon::monitor: Got notification for new block block_height=716220
2021-12-29 04:56:20  INFO rocket::server: GET /alive:
2021-12-29 04:56:40  INFO rocket::server: GET /alive:
2021-12-29 04:57:42 DEBUG daemon::monitor: Got notification for new block block_height=716221
2021-12-29 04:57:50  INFO rocket::server: GET /alive:
2021-12-29 04:58:39  INFO rocket::server: GET /alive:
2021-12-29 04:58:45  INFO rocket::server: GET /alive:
2021-12-29 04:58:53  INFO rocket::server: GET /alive:
2021-12-29 04:59:00  INFO rocket::server: GET /alive:
2021-12-29 05:00:02 DEBUG daemon::oracle: Fetching announcement for /x/BitMEX/BXBT/2022-01-05T06:00:00.price?n=20
2021-12-29 05:00:13  WARN daemon::connection: Failed to establish connection: Connection reset by peer (os error 104) address=<IP_ADDRESS>:9999
2021-12-29 05:00:13  WARN daemon::connection: Tried connecting to 1 addresses without success, retrying in 5 seconds
2021-12-29 05:00:18 DEBUG daemon::connection: Connecting to maker address=<IP_ADDRESS>:9999
2021-12-29 05:00:21 DEBUG daemon::noise: Noise protocol initiator handshake is complete
2021-12-29 05:00:21  INFO daemon::connection: Established connection to maker address=<IP_ADDRESS>:9999

Note: Eventually the taker did re-connect because the maker restarted and closed the connection it seems.

Update: I have a good feeling about the changes introduced in https://github.com/itchysats/itchysats/commit/d0d1f0f835a9179b4029a964e7456ab42048106c. I've disabled the automated restart and it's been running for several hours now without issues: orders are being sent out to all connected takers.
Please monitor your takers and let me know if you see something odd. Otherwise, I think we can close this ticket 🥳
cc: @da-kami / @klochowicz / @thomaseizinger

Good news, lets optimistically close this then!


Align all nodes/CollectionViewCells from bottom ?

HEy Dian,
Is there is built-in support that can align collectionview cells(providers) from bottom ?
(By default, when you add a new provider/cell, it will be added from top of the screen and following last provider/cell. My quest here is if there is a built-in support or easy way to achieve align from bottom: first cell go to bottom of the screen and second following that on top of it ? )

👍  .


Update UG with labels and some tips

Ignore the first commit, it has been reversed.

Conflicts resolved


Fix: Attempted to read or write protected memory. This is often an indication that other memory is corrupt

Рахмет!

Release 0.5.0


Node.js not found after upgrade to Version 17.7.0 Preview 3.0

Open any solution

Expected behavior
Pylance working

Hi there, thanks for the issue. This is a known issue and the workaround is documented here: https://developercommunity.visualstudio.com/t/Pylance-language-server-isnt-starting-i/10411774
It will be fixed in 17.7 preview 4. Thanks!


nyc-test wraps itself again and again

Multiple tests in test/nyc-test instantiated NYC and call wrap(), wrapping the current process. This leads to poor test isolation. Each test should probably be run in its own process.

I think this is (at least partly) the source of my trouble with capture-require


fix(client): border visibility for form control in nightmode

[x ] I have read freeCodeCamp's contribution guidelines.
[x ] My pull request has a descriptive title (not a vague title like Update index.md)
[x ] My pull request targets the master branch of freeCodeCamp.
[x ] None of my changes are plagiarized from another source without proper attribution.
[x ] All the files I changed are in the same world language (for example: only English changes, or only Chinese changes, etc.)
[x ] My changes do not use shortened URLs or affiliate links.

Closes #37375
What has been done
I took a look at #37375 issue. Like @ojeytonwilliams suggested, I'm throwing little dark background (#0a0a23) and light text (#ffffff) on form control elements. Also the border color during focus is now visible in night mode.
I tried to attach the screenshot of the webpage in night mode. But unfortunately github has some issues in uploading it. Please take a look and any suggestions are welcomed. :)

Can you possibly throw a screenshot of a before and after for us?

P.S: About the checkboxes in the PR templates (first post on this thread)

-[ ] ...
-[x] ...

becomes:

[ ] ...
[x] ...

- [x ] ...

becomes:

[x ] ...

Nice work.

Can you possibly throw a screenshot of a before and after for us?
Edit: Nevermind you tried.

I tried to attach the screenshot of the webpage in night mode. But unfortunately github has some issues in uploading it.

You can drag and drop any image file into the text are on this thread and should work?
P.S: About the checkboxes in the PR templates (first post on this thread)
-[ ] ...
-[x] ...

becomes:
* [ ]  ...

* [x]  ...

- [x ] ...

becomes:
* [x ] ...

Yeah, I have noticed only after giving the PR. Will correct myself from the next time :)


Troubleshooting : istioctl proxy-config improvements

istioctl proxy-config is an excellent tool. It allows to query pilot for ads delivered to all proxies:
istioctl proxy-config pilot mesh ads
It allows to query the actual Envoy config on a specific proxy (localhost:15000/config_dump) with a command like this
istioctl proxy-config endpoint pod-name
It would be great to add a "all" command that can get the

config_dump from all Envoys
-the pilot ads config
kubectl get all --all-namespaces
-anything else we need , depending on the  platforms

I would like to use a single command like "istioctl proxy-config all" , and redirect it to an archive utility and get all the troubleshooting info I need.
Later, I would like an option to have hyperlinks, so I can browse listeners etc from a web browser (this is covered by #2751 )
I would also like to request users to get a snapshot of their istioctl proxy-config after installing istio, and a snapshot if an issue arrises,  so we can compare the two. This could be automated.

cc @douglas-reid @sakshigoel12

It definitely would be useful! I'm in the process of trying to simplify the proxy-config command into something a bit more user friendly based on feedback from people.
I would suggest this functionality has its own dedicated command. That way users don't have to remember some magic incantation of flags to get an entire dump and we don't overload proxy-config. I've been refactoring some  of the interfaces so most of the code required is now in re-usable libraries anyway.
A simple istioctl mesh-dump [<archive-name>] that dumps all Envoy config dumps into an archive of one per file is probably a good starter point. We can then advance to hyperlinking in the next iteration.

@liamawhite sgtm

At a minimum we need reasonable documentation.


Question about the configuration of the environment variable CR_TEAM_NAME

I know I'm in the early stages, so the documentation is probably not quite complete yet. I manually had to create the team "terminusCR", otherwise the change requests got an error:

2023-07-18 22:17:44 DEBUG 2023-07-18T20:17:44.931Z the change request db already exists API Error @type api:DbCreateErrorResponse api:message Unknown organization name: terminusCR api:status api:not_found Code: 404 url: http://terminusdb-server:6363/api/db/terminusCR/devs__KaPNetDB__CR

So I looked in the docker-compose.yml and saw the entry for the environment variable CR_TEAM_NAME=terminusCR. Can this name be some existing team, or is this necessary to keep it that way, because otherwise it would interfere with the teams databases?

we removed the CR_TEAM_NAME variable in dockers compose configuration.
the terminusCR team will be the default team for CR, it will be created automatically if it does not exists.
we are release a new version very soon


too much verbosity in dependencies for package.json

when deploying a nodejs function via serverless I get this very "weird" output format.  We should do some parsing/formatting.

we should just print the content of dependencies in  a package.json

+1. As the dependency file is now only being shown with -o yaml/json, they still must be "fillet"


dc_suffix is applied to Ec2 snitches

If using AWS, data centers are configured based on the suffix.
This PR applies the datacenter attribute to the dc_suffix property if using any Ec2 snitch.

@dcparker88, any idea on the failure reason? I'm not sure that's something related to my changes.

not sure what the travis failures are, but they don't look related to your code. :+1:


Reload page after showing preview during restoration

Hi,
There are cases where sometime It would be nice to, after restoration, show the cache preview and then refresh the page. I currently opt out from cache, but the 'wow' fast feeling when clicking back is gone.
I was wondering if there was any way to achieve this? or if it's a feature that could be included in Trubolinks at some point?
Thanks,
Benoit

This was duplicated by a more recent issue which includes a possible solution: https://github.com/turbolinks/turbolinks/issues/413 Hope that helps.


Fix build on FreeBSD

(Changes by @mneumann with edits by @jemc to make it continue
to work on non-FreeBSD platforms as well)

This PR is a replacement for #208.

@mneumann - please review and test on FreeBSD again, when you get the chance.

tested on FreeBSD. works like a charm


runner check doesnt seem to function properly

In your example the check method simply throws an exception.
This exception isn't caught anywhere and meteor treats it as a server crash.
Also if you have multiple mediums in a courier if one medium throws an exception, then none of the mediums run.
I've tried simply returning false from the check method but that doesnt seem to work.

Sorry, missed this. I will take a look when I get a chance. Given that is has been so long, did you find a fix for this?


Initialize Release 160.0.0

Explanation
Major version releases

@metamask-queued-request-controller to v0.13.0

Patch release

@metamask/selected-network-controller to v15.0.1

Checklist

[ ] I've updated the test suite for new or updated code as appropriate
[ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
[ ] I've highlighted breaking changes using the "BREAKING" category above as appropriate

Can we name this PR "Release 160.0.0"? The release workflow won't activate unless the PR title matches the patterns set here: https://github.com/MetaMask/core/blob/main/.github/workflows/main.yml#L38


Fix azure-pipeline tests

This PR fixes common test issues:

browser.close() was not called after test
target="_blank" caused wd to open a second chrome window, wich was not closed by browser.close()
Factory test only closed last instance of browser

Hey @kaylangan
I have a few questions regarding azure-pipelines.

How to set the log encoding. Currently our logs have issues displaying properly:

should look more like this:

Currently we are having issues with chrome. Somehow it crashes every now and then. This happens only on windows related ci systems. Maybe you have some hint to point me in the right direction.

Closing for now in favor of https://github.com/zeit/next.js/pull/5388


Create NayLaMin

Hello

Hi

Hi how do I create a clx wallet

hello anyone can help me how to get clx address wallet?? huhu

Any problems

Unable to withdraw anyway cryptolux going down
Nandi
On Fri, 22 Mar 2019, 22:56 BIGCRYPTO001<EMAIL_ADDRESS>wrote:

Any problems
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/CryptoLuxCLX/clx-wallet/pull/4#issuecomment-475780093,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AtnwII1JkbSFXvXJ_phZn7ZCopNS1z8fks5vZUOMgaJpZM4Ytuh2
.

I need clx wallet plase

Hello I'm dragging clx From your site

Why coz the site is dead

becasuse the all online earning sites are fakes .  so don't struggless for
online earning. 😏😒😔d'nt waste your money ....All sites are scamers
On Thu, 10 Oct 2019, 4:29 pm Nandi79<EMAIL_ADDRESS>wrote:

Why coz the site is dead
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/CryptoLuxCLX/clx-wallet/pull/4?email_source=notifications&email_token=AKZG4TZW2RI7LJLMURQUN4TQN4GYRA5CNFSM4GFW5B3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEA34VFA#issuecomment-540527252,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKZG4T7MP5XQGTOYH6AC2QLQN4GYRANCNFSM4GFW5B3A
.


Added timber_transients_slug filter

If you are using i18n, you can use this filter

Thanks @ruscon! I changed this to timber/transient/slug to match the filter syntax we have going on elsewhere.

thx


[SUGGESTION] Web Interface for GPT-Engineer

This idea of GPT-Engineer is great. If we make a web interface for this project, we might even be able to gather up even more contributers.
Coding will be made easier, more efficient than ever. Showing off our idea on the website will be great.

I will be working on the web interface and will be using Flask, HTML, CSS, Bootstrap. If anybody has any other idea, then they can help me out.

I need help in designing the website, what webpages it will have and functionality it will exhibit. I have a few ideas as follows:-

Index Page
About Us Page
Getting Started Page
Documentation Page
Blog Page
Community Page
I am taking Pandas Website as an inspiration.

Should a new repository be started or we should continue with the current repo from the folder gpt-engineer/web(This folder is not created yet.)?

I need help in designing the website, what webpages it will have and functionality it will exhibit. I have a few ideas as follows:-

Index Page
About Us Page
Getting Started Page
Documentation Page
Blog Page
Community Page
I am taking Pandas Website as an inspiration.

i use html as main.

Should a new repository be started or we should continue with the current repo from the folder gpt-engineer/web(This folder is not created yet.)?

I'd suggest to close this issue, and start a new repo where you use GPT-engineer as a dependency.
I look forward to testing it ou 💪

Hears good. I will do the same.
This time at the moment ate so creazy. All is changing, all comes new. Disruption 100%.
In 5 year look every back, an say: why i not see this.
Gesendet von Outlook für Androidhttps://aka.ms/AAb9ysg

From: hannesdelbeke @.>
Sent: Saturday, July 1, 2023 3:11:34 PM
To: AntonOsika/gpt-engineer @.>
Cc: Subscribed @.***>
Subject: Re: [AntonOsika/gpt-engineer] [SUGGESTION] Web Interface for GPT-Engineer (Issue #456)
Should a new repository be started or we should continue with the current repo from the folder gpt-engineer/web(This folder is not created yet.)?
I'd suggest to close this issue, and start a new repo where you use GPT-engineer as a dependency.
I look forward to testing it ou 💪
—
Reply to this email directly, view it on GitHubhttps://github.com/AntonOsika/gpt-engineer/issues/456#issuecomment-1615647219, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A7BOG3JBIDNVTD3RNTHMJLLXN7LTNANCNFSM6AAAAAAZZ5WLHU.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

@hannesdelbeke I don't have a paid account to OpenAI API

I have done my Initial Commit of the website.
To see the website run the command python3 web/web_main.py while in the gpt-engineer directory.

Great idea. I know two friends working on this also.
Do you want to move this convo to GH discussions / Discord to make issues cleaner though?

Yeah! That's a great idea.

Great idea. I know two friends working on this also.
Do you want to move this convo to GH discussions / Discord to make issues cleaner though?
I think GH discussions is good.

Great idea. I know two friends working on this also.
Do you want to move this convo to GH discussions / Discord to make issues cleaner though?

I think Github Discussions is great.

Opened discussions on Web Interface for GPT-Engineer

This would be an incredible feature. The ability to pre-define specific requirements and best routes of development and save presets of those setting environments would be great. That way people can build dev workflows by loading preset of specific dev details before giving GPT-Egineer it's prompt. It would also help guide gpt-engineer to have a better context for its pre-dev questions. Knowing in advance more contextual detail of what the user is looking for.
Can't wait to try this out. thanks everyone.

Housekeeping here: I see that this issue has been stale for a while and its not totally clear to me whether:

This is being developed as part of gpt-engineer
This is being developed as a separate repo with gpt-engineer as a dependency
Anything at all is still being developed

Adding the triage flag.

Closing due to overdue triage label


[release-1.10] Run UPDATE_BRANCH=release-1.10 ./bin/update_deps.sh

Pick up other dependencies
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Pull Request Attributes
Please check any characteristics that apply to this pull request.
[ ] Does not have any user-facing changes. This may include CLI changes, API changes, behavior changes, performance improvements, etc.

@ericvn: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio_release-1.10
b72ca39c4fe443fc5360bb10f8822221083e26ae
link
/test release-notes_istio_release-1.10

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest


Fix issues with extension sync

Short description of what this resolves:
This PR fixes issues that prevented extensions from being synced properly.
Changes proposed in this pull request:

Properly throw an error when one occurs
Scan for missing extensions correctly

Checklist:

[x] I have read the contribution guidelines.

We need to sync the map function by using async/await in the following line.
https://github.com/shanalikhan/code-settings-sync/blob/v3.3.0/src/service/pluginService.ts#L225
Can you improve this and send me PR.
Delete extension seems to working fine, i will test more.
The current output:
[x] - EXTENSION: beautify - INSTALLING

[x] - EXTENSION: debugger-for-chrome - INSTALLING

[x] - EXTENSION: team - INSTALLING
    - EXTENSION: debugger-for-chrome - INSTALLED.
      1 OF 3 INSTALLED

    - EXTENSION: team - INSTALLED.
      2 OF 3 INSTALLED

    - EXTENSION: beautify - INSTALLED.
      3 OF 3 INSTALLED

``

@shanalikhan The problem with syncing the two is that Promise.all executes the installations in parallel. The only way I could think of to resolve this would be to use blocking code, which is not recommended for a VSCode extension because it can freeze the extension host. What I suggest we do is just remove the log stating that an extension is installing and only leaving the one that says that it was installed. What do you think?

just remove the log stating that an extension is installing

For the user point of view, we must show which extension is installing and installed completely.

it can freeze the extension host
Yes , we should not use that.
What about we can use simple for loop instead of map and other stuff. Explore other ways.
You can look into the previous code in master branch, how in CLI i'm holding the next installation CLI command that waits for previous command to complete.

But we need to show what is going to install and what has been installed.

What about we can use simple for loop instead of map and other stuff.

That is an example of blocking code. For loops prevent other code from running until it is finished, and extension installation takes a long time.
I'm currently testing a way of potentially replicating the for loop's outcome using async/await.

@shanalikhan Here's a PR that will sync the INSTALLING and INSTALLED messages: #910


Creates a broken config (npm install fails)

Steps to reproduce:

mkdir repro
cd repro
npm init
(fill in the details for npm init)
npm init @eslint/config@latest
Give the following answers:

✔ How would you like to use ESLint? · problems
✔ What type of modules does your project use? · commonjs
✔ Which framework does your project use? · none
✔ Does your project use TypeScript? · typescript
✔ Where does your code run? · browser
The config that you've selected requires the following dependencies:

<EMAIL_ADDRESS>globals, @eslint/js, typescript-eslint
✔ Would you like to install them now? · No / Yes
✔ Which package manager do you want to use? · npm

Expected result: working config of eslint
Actual result: a dependency setup that makes it impossible to install. Running npm install gives the following error:
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/eslint
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!   peer<EMAIL_ADDRESS>|| ^7.0.0 || >=8.0.0" from<EMAIL_ADDRESS>npm ERR!   node_modules/@eslint-community/eslint-utils
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!     node_modules/typescript-eslint/node_modules/@typescript-eslint/utils
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!       node_modules/typescript-eslint
npm ERR!         dev<EMAIL_ADDRESS>from the root project
npm ERR!       2 more (@typescript-eslint/eslint-plugin, @typescript-eslint/type-utils)
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/typescript-eslint
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Conflicting peer dependency<EMAIL_ADDRESS>npm ERR! node_modules/eslint
npm ERR!   peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/typescript-eslint
npm ERR!     dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

I'm using npm 8.19.4

I can't reproduce this with npm 10.5.0. I see the same lines, but as npm WARN instead of npm ERR!. Can you check if there's a npm WARN using --force line after you choose package manager?
<EMAIL_ADDRESS>globals, @eslint/js, typescript-eslint
√ Would you like to install them now? · No / Yes
√ Which package manager do you want to use? · npm
☕Installing...
npm WARN using --force Recommended protections disabled.
npm WARN ERESOLVE overriding peer dependency
...

I'm seeing identical results to @kuba-orlik while attempting setup with the following settings:
❯ npm init @eslint/config@latest
✔ How would you like to use ESLint? · problems
✔ What type of modules does your project use? · esm
✔ Which framework does your project use? · none
✔ Does your project use TypeScript? · typescript
✔ Where does your code run? · browser
The config that you've selected requires the following dependencies:

<EMAIL_ADDRESS>globals, @eslint/js, typescript-eslint
✔ Would you like to install them now? · No / Yes
✔ Which package manager do you want to use? · npm
☕Installing...

added 86 packages, changed 1 package, and audited 681 packages in 3s

If I attempt an npm install after this step, I end up with the same dependency tree error.
I've attempted this with npm versions 9.8.1 and 10.7.0 with the same results.
In answer to @mdjermanovic's question, it doesn't appear that --force was used in the installation. I should also add that using --force does circumvent the issue, and that after the fact it appears to work as expected, so far as I can tell.

Hey guys...
I'm here just to report the same problem, I noticed the error by chance a few minutes ago using this config:
"devDependencies": {
    "@eslint/js": "^9.4.0",
    "eslint": "^9.4.0",
    "globals": "^15.4.0",
    "typescript": "^5.2.2",
    "typescript-eslint": "^7.13.0",
    "vite": "^5.2.0"
  }

But I fixed the error using theses versions (used in another project without the error):
"devDependencies": {
    "@eslint/js": "^9.2.0",
    "eslint": "^8.57.0",
    "globals": "^15.1.0",
    "typescript": "^5.2.2",
    "typescript-eslint": "^7.13.0",
    "vite": "^5.2.0"
  }

I think something happend in the @latest package...

I couldn't reproduce any of these errors. @aladdin-add any ides what could be happening here? Could it be that npm init @eslint/config@latest still runs some cached version even though there's @latest at the end?

I was able to repro:

npm i<EMAIL_ADDRESS>typescript-eslint -D -f: no errors

$ npm i<EMAIL_ADDRESS>typescript-eslint -D -f
npm warn using --force Recommended protections disabled.
npm warn ERESOLVE overriding peer dependency
npm warn While resolving<EMAIL_ADDRESS>npm warn Found<EMAIL_ADDRESS>npm warn node_modules/eslint
npm warn   peer<EMAIL_ADDRESS>|| ^7.0.0 || >=8.0.0" from<EMAIL_ADDRESS>....

npm i => errors:

npm i
npm error code ERESOLVE
npm error ERESOLVE could not resolve
npm error
npm error While resolving<EMAIL_ADDRESS>npm error Found<EMAIL_ADDRESS>npm error node_modules/eslint
npm error   dev<EMAIL_ADDRESS>from the root project
npm error   peer<EMAIL_ADDRESS>|| ^7.0.0 || >=8.0.0" from<EMAIL_ADDRESS>...

users have to use --force in every installing. I was wondering if we can suggest adding force=true in .npmrc to avoid it.

I was able to repro:

npm i<EMAIL_ADDRESS>typescript-eslint -D -f: no errors

$ npm i<EMAIL_ADDRESS>typescript-eslint -D -f
npm warn using --force Recommended protections disabled.
npm warn ERESOLVE overriding peer dependency
npm warn While resolving<EMAIL_ADDRESS>npm warn Found<EMAIL_ADDRESS>npm warn node_modules/eslint
npm warn   peer<EMAIL_ADDRESS>|| ^7.0.0 || >=8.0.0" from<EMAIL_ADDRESS>....

npm i => errors:

$ npm i
npm error code ERESOLVE
npm error ERESOLVE could not resolve
npm error
npm error While resolving<EMAIL_ADDRESS>npm error Found<EMAIL_ADDRESS>npm error node_modules/eslint
npm error   dev<EMAIL_ADDRESS>from the root project
npm error   peer<EMAIL_ADDRESS>|| ^7.0.0 || >=8.0.0" from<EMAIL_ADDRESS>...

users have to use --force in every installing. I was wondering if we can suggested adding force=true in .npmrc to avoid it.

Ah, so the problem is not that @eslint/create-config fails to install dependencies, but that it leaves a setup where when doing npm install afterwards, it will fail?

right!

Thanks, I see now that I totally misread the original post.

if we can suggest adding force=true in .npmrc to avoid it.

Maybe we could suggest adding overrides like we did in the eslint.org repo?

also works for me! 👍

Okay, marking as accepted.


Use rolling muhash for UTXO set hash

This PR is an update to #10434. It implements a rolling UTXO set hash using the Muhash algorithm. The hash is accessible through the gettxoutsetinfo RPC call.
Design info:
UtxoSetHash is functioning as an Index (subclass of BaseIndex). It maintains the current Muhash object m_muhash that is updated with changes in the blockchain. It also saves 256bit digests of the Muhash for every block.
An alternative design could have hooked into ValidationInterface directly and used a flat-file structure for persistence instead of the DB. Thoughts on these alternatives welcome.
Find more details in the Proposal.
Known todos:

[ ] No finished implementations of rolling versions of ECMH and LtHash to compare
[ ] variable names including hash may refer to an instance of MuHash3072 or UtxoSetHash or a 256bit hash digest. This may be confusing and I want to clean this up naming all instances of MuHash something including muhash and everything referring to 256bit hashes something named digest
[ ] WriteBlock and ReverseBlock method could be considerably DRYed up
[ ] In order to make gettxoutsetinfo respond instantly, the other statistics that are collected by looping over the UTXO set will need to be updated on a rolling basis as well: total_amount, bogosize, txouts, transactions

Can you set the base branch to master for this?

@jnewbery moved my work in progress over here: https://github.com/ChaincodeResidency/bitcoin/pull/28


Wrong date is returned when looking at historical data

Hello! I love this service, but I found something that looks like a bug. If this is intentional then an explanation would be highly appreciated! Maybe it's just me...
I compared the data to other exchange rate API's (fixer.io) and the other API's seemed to display the data as expected. Is this related to opening dates in the bank, or lack of historical data for given date prehaps?
https://api.exchangeratesapi.io/2018-12-31 (looks correct)
https://api.exchangeratesapi.io/2019-01-01 (gives me data for 2018-12-31)
https://api.exchangeratesapi.io/2019-01-02 (looks correct)

Closing the issue. After some more digging I found the opening hours of ECB's TARGET, and it explained why this happens: https://www.ecb.europa.eu/home/contacts/working-hours/html/index.en.html


sourcetrail: 2019.1.11 -> 2019.2.25

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/sourcetrail/versions.
meta.description for sourcetrail is: '"A cross-platform source explorer for C/C++ and Java"'.
meta.homepage for sourcetrail is: '"https://www.sourcetrail.com"

Checks done (click to expand)

built on NixOS
/bin/sh passed the binary check.
1 of 1 passed binary check by having a zero exit code.
0 of 1 passed binary check by having the new version present in output.
found 2019.2.25 with grep in /nix/store/n1v3vfkb994wnmhbqza2rdaxqpg46b20-sourcetrail-2019.2.25
directory tree listing: https://gist.github.com/dc775ba5ca79d8d98b6ccc480b8d9b56
du listing: https://gist.github.com/3fbf10282d0223ee56d2f7d95b6ecd44

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)
1 package rebuild(s)
1 x86_64-linux rebuild(s)
0 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
0 aarch64-linux rebuild(s)
First fifty rebuilds by attrpath
sourcetrail

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/n1v3vfkb994wnmhbqza2rdaxqpg46b20-sourcetrail-2019.2.25 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A sourcetrail https://github.com/r-ryantm/nixpkgs/archive/07b42d860e2652945462b1f33b8f588f8cea294a.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/n1v3vfkb994wnmhbqza2rdaxqpg46b20-sourcetrail-2019.2.25
ls -la /nix/store/n1v3vfkb994wnmhbqza2rdaxqpg46b20-sourcetrail-2019.2.25/bin

cc @midchildan for testing.

There's a slightly newer version released, so it might be better to update to the latest version. The newly added python indexing feature also needs some digging to get it working. Aside from that, C/C++ indexing seems to work as before.

Actually, I've just managed to get the python indexing feature working. Would you folks please take a look at #63525?

merged https://github.com/NixOS/nixpkgs/pull/63525 instead


http://emacs-bootstrap.com not available

The Website doesn't seem to work at the moment.

I'm getting back into emacs and remembered this site, but it also does not load for me. To be specific, the domain http://emacs-bootstrap.com loads up a site that looks like blog spam (rindent.com).
The WHOIS shows:
   Updated Date: 2019-11-06T11:08:53Z
   Creation Date: 2016-11-05T18:51:04Z
   Registry Expiry Date: 2020-11-05T18:51:04Z

@avelino are you the current maintainer? Did the domain expire and get grabbed by a squatter? It lists as expiring in a few months, maybe it can be recovered then?

@rakanalh help pls

I have shut down the server on linode and have no plans to restore it. I am happy to transfer ownership of the domain to whoever wants to host the app.

I have shut down the server on linode and have no plans to restore it. I am happy to transfer ownership of the domain to whoever wants to host the app.

@rakanalh set this DNS on domain

ivan.ns.cloudflare.com
sara.ns.cloudflare.com

I configure the environment in vim-bootstrap hosting

Done

@rakanalh upgrade dns to:

greg.ns.cloudflare.com
selah.ns.cloudflare.com

site on here: https://emacs-bootstrap.herokuapp.com/

Updated the DNS records.

Thanks y'all for getting it back online. It works fine for me now at https://emacs-bootstrap.com/. 🙇♂


Simplify service tracking by using kapi.NamespaceAll

We don't need to track services per-namespace; we can just use the namespace kapi.NamespaceAll (aka ""), like "oc get --all-namespaces" does.
Closes #158
@pravisankar

Good stroke. I was searching for this one in the beginning but couldn't think of this obvious one.
Lgtm.

Nice, clean solution.
lgtm


Reconstruct image from pncc and uv_tex

Is there a feature that reconstructing an image from a pncc serialization and uv texture image?

Not yet.


Add whitespace to generated license file, add file extension to licen…

…se parameter

🤖 AutoRest automatic publish job 🤖
> will publish once PR gets merged

🤖 AutoRest automatic feature coverage report 🤖
feature set version 2.4.2
❌ General: 0%
no tests were run for this category
✔ Azure: 100%

🤖 AutoRest automatic feature coverage report 🤖
feature set version 2.4.2
❌ General: 0%
no tests were run for this category
✔ Azure: 100%


[Usersnap] I have two instances of LACE extensions.  Original for main-net an...

Add a comment: I have two instances of LACE extensions. Original for main-net and the one I just created to test SanchoNet. The calls to connect wallet conflict. Unable to register as a drep as the connected wallet attempts to access Original/Mainnet wallet
Screen size: 1202 x 677
Browser: Chrome 120 (Windows 10)
Referer: SanchoNet Govtool
Open #21 in Usersnap

Can't retest as Lace Sanchnet doesn't seem to be working


Fix mouseEvent.screenX and screenY so that it doesn't fail in Tor Browser.

We need to use selenium to generate a mouse click (or mouseover or similar), instead of creating a fake mouse event from JS.


Default FelixConfiguration RouteTableRange when using AWS CNI

Cherry-pick aws cni fix to 1.19
Default range to 65-99

Move GKE ROUTETABLERANGE to be set like for AWS
Move FelixConfig to watch for all variants

Description

For PR author

[ ] Tests for change.
[ ] If changing pkg/apis/, run make gen-files
[ ] If changing versions, run make gen-versions

For PR reviewers
A note for code reviewers - all pull requests must have the following:

[ ] Milestone set according to targeted release.
[ ] Appropriate labels:

kind/bug if this is a bugfix.
kind/enhancement if this is a a new feature.
enterprise if this PR applies to Calico Enterprise only.

Picking #1447

I think this also needs https://github.com/tigera/operator/pull/1408 to fix CI. Feel free to add the pick to this PR, just keep the commits separate.


Stop use one-hot encoder to categorical feature if it's numeric

might under-perform lgbm trainer if we do so

https://github.com/microsoft/FLAML/discussions/409

BTW, column boat here is textual, but best results are received if it is specified as a number.
https://github.com/microsoft/FLAML/discussions/409#discussioncomment-2093969

For best performance, may need more investigation. It seems Model Builder aggressively marks numeric cols as categories, but removing them seems to lower performance at least in one of my datasets. It may be related to number of categories, < 10 or <5 may perform better as one-hot encoding. Even better, some future version might test different pipelines.

Nevermind, I can not be sure yet because the validation data is not the same, so could just depend on how test data got chosen.

@LittleLittleCloud What is the priority of this? Do you need input from PM?


Error thrown when a external ledger is used

When an external ledger is used on Issuer-Kit and on VC-Authn-OIDC project and the usage of a pre-configured mobile wallet like Esatus (with the external ledger previously added)  the mobile application receives an error right after scan the QR code to login on the "vc-authn-oidc demo application".
Please find the stacktrace error below:
controller_1     | {"event": "Traceback (most recent call last):\n  File \"/usr/local/lib/python3.11/site-packages/starlette/middleware/base.py\", line 78, in call_next\n    message = await recv_stream.receive()\n              ^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/usr/local/lib/python3.11/site-packages/anyio/streams/memory.py\", line 97, in receive\n    return self.receive_nowait()\n           ^^^^^^^^^^^^^^^^^^^^^\n  File \"/usr/local/lib/python3.11/site-packages/anyio/streams/memory.py\", line 90, in receive_nowait\n    raise EndOfStream\nanyio.EndOfStream\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n  File \"/app/api/main.py\", line 90, in logging_middleware\n    response: Response = await call_next(request)\n                         ^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/usr/local/lib/python3.11/site-packages/starlette/middleware/base.py\", line 84, in call_next\n    raise app_exc\n  File \"/usr/local/lib/python3.11/site-packages/starlette/middleware/base.py\", line 70, in coro\n    await self.app(scope, receive_or_disconnect, send_no_error)\n  File \"/usr/local/lib/python3.11/site-packages/starlette/middleware/cors.py\", line 83, in __call__\n    await self.app(scope, receive, send)\n  File \"/usr/local/lib/python3.11/site-packages/starlette/middleware/exceptions.py\", line 79, in __call__\n    raise exc\n  File \"/usr/local/lib/python3.11/site-packages/starlette/middleware/exceptions.py\", line 68, in __call__\n    await self.app(scope, receive, sender)\n  File \"/usr/local/lib/python3.11/site-packages/fastapi/middleware/asyncexitstack.py\", line 21, in __call__\n    raise e\n  File \"/usr/local/lib/python3.11/site-packages/fastapi/middleware/asyncexitstack.py\", line 18, in __call__\n    await self.app(scope, receive, send)\n  File \"/usr/local/lib/python3.11/site-packages/starlette/routing.py\", line 718, in __call__\n    await route.handle(scope, receive, send)\n  File \"/usr/local/lib/python3.11/site-packages/starlette/routing.py\", line 276, in handle\n    await self.app(scope, receive, send)\n  File \"/usr/local/lib/python3.11/site-packages/starlette/routing.py\", line 66, in app\n    response = await func(request)\n               ^^^^^^^^^^^^^^^^^^^\n  File \"/usr/local/lib/python3.11/site-packages/fastapi/routing.py\", line 237, in app\n    raw_response = await run_endpoint_function(\n                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/usr/local/lib/python3.11/site-packages/fastapi/routing.py\", line 163, in run_endpoint_function\n    return await dependant.call(**values)\n           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/app/api/routers/presentation_request.py\", line 50, in send_connectionless_proof_req\n    if 'text/html' in req.headers.get('accept'):\n       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\nTypeError: argument of type 'NoneType' is not iterable\n", "logger": "api.main", "level": "error", "timestamp": "2023-10-30T17:19:41.924874Z"}

Additional information: Both projects shared same  Keycloak instance, and the ngrok tunnels were started according to receive calls from the mobile application. Below an example of my configuration:
authtoken: <Your_Personal_Ngrok_Token>
tunnels:
  issuer-agent:
    addr: 8021
    proto: http
    bind-tls: true
  vc-authn-controller:
    addr: 5000
    proto: http
    bind-tls: true
  vc-authn-aca-py:
    addr: 8030
    proto: http
    bind-tls: true
version: "1"

@sgroh did you add the new ledger to the list of ledgers the agent will be connecting to? See https://github.com/bcgov/vc-authn-oidc/blob/0ac2f324a6686c243c37135f8396bb88c3e6ba8d/docker/agent/config/ledgers.yaml

@esune yes I did, actually I remove all and add only one pointing to my private ledger:
- id: My-Own-Von-Network
  is_production: true
  is_write: true
  genesis_url: 'https://<MY_HOST>/genesis'

Regarding the wallet I've also tried with Lissi Wallet and the error is exactly the same.
As you mentioned the error is exactly when in code it asks if the request's headers has on accept 'text/html'... Seems to be blowing up right there.

My guess is that both eSatus and Lissi (both based on aries-framework-dotnet) are not sending compatible request headers.
@popkinj do you have any input on whether we should be updating the code to handle things differently, or the changes should potentially come upstream in aries-framework-dotnet when making the request?

My guess is that both eSatus and Lissi (both based on aries-framework-dotnet) are not sending compatible request headers. @popkinj do you have any input on whether we should be updating the code to handle things differently ~, or the changes should potentially come upstream in aries-framework-dotnet when making the request~ ?

Yes.... It's possible the headers are slightly different. If the header is requesting JSON we assume the qrcode is being scanned by a wallet. If requesting HTML then it is most likely a regular camera app. Can we capture the headers in all scenarios so I can have a look :eyes: ? There could be something non-standard... or possibly something I didn't account for. :thinking:

Hi @popkinj below are the headers that I could capture from the request previous the error:
"host" : "-free.app"
"user-agent" : "Dalvik/2.1.0 (Linux; U; Android 13; SM-G998B Build/TP1A.220624.014"
"accept-encoding" : "identity"
"x-forwarded-for" : "
"x-forwarded-host" : "-free.app"
"x-forwarded-proto" : "https"
Can I help with any other input here?

@popkinj you are welcome.
No, that information is from Esatus Wallet.
On Lissi Wallet things become a bit weird, right after I scan the QR code to login in the vc-authn-oidc demo application, the mobile application receives a Customer Card, but I never was redirected to the demo portal as a logged user.

@popkinj you are welcome. No, that information is from Esatus Wallet.
On Lissi Wallet things become a bit weird, right after I scan the QR code to login in the vc-authn-oidc demo application, the mobile application receives a Customer Card, but I never was redirected to the demo portal as a logged user.

That is a little strange.
Thanks for the feedback. I think I know what's going on. Will keep you posted.

K... I've been able to duplicate the issue in the Esatus Wallet.... and can see what's happening. There's definitely no accept header. Working on a solution.

@popkinj if it looks like the effort to fix this is disproportionate to the benefit, considering aries-framework-dotnet is not maintained anymore, let's reassess.
@sgroh one thing you could do is opening an issue in https://github.com/hyperledger/aries-mobile-agent-react-native requesting the a feature to be able to add/remove ledgers like eSatus/Lissi allow you to do - that could be interesting and beneficial for others too.

It was a small fix. I'm including it in 374

@sgroh look out for the next release of vc-authn OR just pull and build from main once #374 is merged. I would still add the recommendation in Bifold as it seems like a good idea.

It was a small fix. I'm including it in 374

@popkinj since #374 is taking more time than expected, can you please make a separate PR with the quick fix for this, so that we can merge it to main?


Update baseline version to 21.5.53619.54979

Closing the PR as we're uptaking v. 22.1, so the baseline version will be 22.0