litd hangs while open channel due to 'stateless_init'

Steps to Reproduce the Issue
Step 1: Run the lightning-terminal Docker container, using version github.com/lightninglabs/lightning-terminal v0.13.993-experimental.
Step 2: Call lnd.initWallet with the stateless_init option enabled, using port 10009.
Step 3: Attempt to open a channel.
Result: Channel opening failed.
Handling gRPC request: /lnrpc.Lightning/OpenChannelSync
2024-09-03 17:57:38 2024-09-03 09:57:38.464 [DBG] RPCS: [/lnrpc.Lightning/OpenChannelSync] requested
2024-09-03 17:57:38 2024-09-03 09:57:38.864 [DBG] RPCS: [openchannel] request to NodeKey(030da9bba7e129efb448cf9ba94ee407aec06bbe7420f24bf77c84bdc8519713bf) allocation(us=10000000, them=0)
2024-09-03 17:57:38 2024-09-03 09:57:38.864 [DBG] RPCS: [openchannel]: using fee of 2500 sat/kw for funding tx
2024-09-03 17:57:38 2024-09-03 09:57:38.866 [INF] FNDG: Initiating fundingRequest(local_amt=0.10000000 BTC (subtract_fees=false), push_amt=0 mSAT, chain_hash=0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206, peer=030da9bba7e129efb448cf9ba94ee407aec06bbe7420f24bf77c84bdc8519713bf, min_confs=1)
2024-09-03 17:57:38 2024-09-03 09:57:38.872 [DBG] TSVR: DeriveTapscriptRoot called
2024-09-03 17:57:41 2024-09-03 09:57:41.779 [INF] LITD: Handling gRPC request: /lnrpc.State/GetState
2024-09-03 17:57:41 2024-09-03 09:57:41.780 [DBG] RPCS: [/lnrpc.State/GetState] requested
2024-09-03 17:57:41 2024-09-03 09:57:41.784 [DBG] GRPC: [transport] [server-handler-transport 0x4000c2fcc0] Closing: finished writing status
2024-09-03 17:57:51 2024-09-03 09:57:51.793 [INF] LITD: Handling gRPC request: /lnrpc.State/GetState
2024-09-03 17:57:51 2024-09-03 09:57:51.797 [DBG] RPCS: [/lnrpc.State/GetState] requested
2024-09-03 17:57:51 2024-09-03 09:57:51.800 [DBG] GRPC: [transport] [server-handler-transport 0x4003414aa0] Closing: finished writing status
2024-09-03 17:58:01 2024-09-03 09:58:01.805 [INF] LITD: Handling gRPC request: /lnrpc.State/GetState
2024-09-03 17:58:01 2024-09-03 09:58:01.807 [DBG] RPCS: [/lnrpc.State/GetState] requested
2024-09-03 17:58:01 2024-09-03 09:58:01.810 [DBG] GRPC: [transport] [server-handler-transport 0x400108fae0] Closing: finished writing status

Hi @lukegao209! It seems like the logs you've included in the description, doesn't really contain the error you've encountered. Would you be able to extend the logs please, so that it includes the error?

there is no error logs.

Ok, understood! Of you can though, it please extend the logs though as there might be some other hints as to what's failing, especially there's anything in the logs that covers the result you've written above:

Result: Channel opening failed.

Also, could please include the full command you used when opening the channel?

When attempting to open a channel, it remains in a waiting state indefinitely, and no errors appear in the logs. Additionally, this issue can be reproduced consistently

Hi again @lukegao209,
I was just able to open a channel successfully on testnet3 with a stateless_init setup of an litd integrated lnd node.
The channel left the "waiting state" as expected, once it had enough confirmations on the blockchain.
I used the following command when opening the channel:
lncli --macaroonpath <PATH_TO_ADMIN_MACAROON> openchannel <node-key> <local-amt> <push-amt>
The wallet had been created in stateless init mode using:
lncli create --stateless_init --save_to <PATH_TO_ADMIN_MACAROON>
Are you sure that:

Your node is fully synced to the chain.
Enough blocks have been mined for the channel open transaction (funding transaction) to confirm sufficiently?

I tested it on regtest following the same steps, and it failed again.
Here are cmd and logs

2024-09-05 13:09:08.180 [DBG] HLCK: invoking success callback
2024-09-05 13:09:42.548 [DBG] LNWL: Filtering block 2482 (473a4c98f782d66e20ca922348858c332a0cbf8c46f18045c09094ff70eb7426) with 4 transactions
2024-09-05 13:09:42.549 [INF] CRTR: Pruning channel graph using block 473a4c98f782d66e20ca922348858c332a0cbf8c46f18045c09094ff70eb7426 (height=2482)
2024-09-05 13:09:42.550 [INF] LNWL: Marking unconfirmed transaction<PHONE_NUMBER>6e9355c0e0966dbedd7a8b1025b23e651a35c9a13460be9eee9734 mined in block 2482
2024-09-05 13:09:42.552 [DBG] LNWL: Marked address bcrt1pjcgssmutr6rem0al4e65lryrlmcppe2l8y8znu83xq2d4ukma08su97pj8 used
2024-09-05 13:09:42.553 [DBG] CHDB: Pruned graph, cache now has num_node_features=0, num_nodes=0, num_channels=0
2024-09-05 13:09:42.554 [INF] CRTR: Block 473a4c98f782d66e20ca922348858c332a0cbf8c46f18045c09094ff70eb7426 (height=2482) closed 0 channels
2024-09-05 13:09:42.558 [INF] LNWL: Marking unconfirmed transaction 5eff09b441dc4f725d1f8f1bc60decc7e8888c0028a59047229a82afaef37b8e mined in block 2482
2024-09-05 13:09:42.559 [DBG] LNWL: Marked address bcrt1pjcgssmutr6rem0al4e65lryrlmcppe2l8y8znu83xq2d4ukma08su97pj8 used
2024-09-05 13:09:42.563 [INF] LNWL: Marking unconfirmed transaction 212ac7cdc251c8a2eabeab8f2e9e8404758ca874490f3002d364328677f1b3a6 mined in block 2482
2024-09-05 13:09:42.563 [DBG] LNWL: Marked address bcrt1pjcgssmutr6rem0al4e65lryrlmcppe2l8y8znu83xq2d4ukma08su97pj8 used
2024-09-05 13:09:42.859 [DBG] NTFN: Filtering 4 txns for 0 spend requests at height 2482
2024-09-05 13:09:42.859 [INF] NTFN: New block: height=2482, sha=473a4c98f782d66e20ca922348858c332a0cbf8c46f18045c09094ff70eb7426
2024-09-05 13:09:42.861 [DBG] DISC: New block: height=2482, hash=473a4c98f782d66e20ca922348858c332a0cbf8c46f18045c09094ff70eb7426
2024-09-05 13:09:42.861 [DBG] SWPR: TxPublisher received new block: 2482
2024-09-05 13:09:42.861 [DBG] SWPR: Received new block: height=2482, attempt sweeping 0 inputs
2024-09-05 13:09:42.861 [INF] UTXN: Attempting to graduate height=2482: num_kids=0, num_babies=0
2024-09-05 13:10:08.186 [DBG] HLCK: invoking success callback
2024-09-05 13:10:47.449 [DBG] RPCS: [/lnrpc.Lightning/OpenChannel] requested
2024-09-05 13:10:47.764 [DBG] RPCS: [openchannel] request to NodeKey(030da9bba7e129efb448cf9ba94ee407aec06bbe7420f24bf77c84bdc8519713bf) allocation(us=10000000, them=0)
2024-09-05 13:10:47.765 [ERR] RPCS: Expected either 'sat_per_vbyte' or 'conf_target' to be set, using default conf of 6 instead
2024-09-05 13:10:47.766 [DBG] RPCS: [openchannel]: using fee of 12500 sat/kw for funding tx
2024-09-05 13:10:47.768 [INF] FNDG: Initiating fundingRequest(local_amt=0.10000000 BTC (subtract_fees=false), push_amt=0 mSAT, chain_hash=0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206, peer=030da9bba7e129efb448cf9ba94ee407aec06bbe7420f24bf77c84bdc8519713bf, min_confs=1)
2024-09-05 13:10:47.769 [DBG] TSVR: DeriveTapscriptRoot called
2024-09-05 13:10:50.543 [DBG] GRPC: [core] [Channel #6] Closing the name resolver
2024-09-05 13:10:50.543 [DBG] GRPC: [core] [Channel #5] Closing the name resolver
2024-09-05 13:10:50.544 [DBG] GRPC: [core] [Channel #5] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.543 [DBG] GRPC: [core] [Channel #6] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.545 [DBG] GRPC: [core] [Channel #6] Channel Connectivity change to IDLE
2024-09-05 13:10:50.545 [DBG] GRPC: [core] [Channel #6] Channel entering idle mode
2024-09-05 13:10:50.545 [DBG] GRPC: [core] [Channel #5] Channel Connectivity change to IDLE
2024-09-05 13:10:50.546 [DBG] GRPC: [core] [Channel #5] Channel entering idle mode
2024-09-05 13:10:50.547 [DBG] GRPC: [core] [Channel #5 SubChannel #7] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.547 [DBG] GRPC: [core] [Channel #5 SubChannel #7] Subchannel deleted
2024-09-05 13:10:50.546 [DBG] GRPC: [core] [Channel #6 SubChannel #8] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.548 [DBG] GRPC: [core] [Channel #6 SubChannel #8] Subchannel deleted
2024-09-05 13:10:50.548 [DBG] GRPC: [transport] [client-transport 0x40001e3448] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.547 [DBG] GRPC: [transport] [client-transport 0x40001e2d88] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.549 [DBG] GRPC: [transport] [server-transport 0x40001d5a00] Closing: EOF
2024-09-05 13:10:50.550 [DBG] GRPC: [transport] [server-transport 0x40001d5a00] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.549 [DBG] GRPC: [transport] [client-transport 0x40001e3448] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.549 [DBG] GRPC: [transport] [server-transport 0x40000f9040] Closing: EOF
2024-09-05 13:10:50.550 [DBG] GRPC: [transport] [client-transport 0x40001e2d88] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.551 [DBG] GRPC: [transport] [server-transport 0x40000f9040] Error closing underlying net.Conn during Close: tls: failed to send closeNotify alert (but connection was closed anyway): io: read/write on closed pipe
2024-09-05 13:10:50.552 [DBG] GRPC: [transport] [server-transport 0x40000f9040] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.564 [DBG] GRPC: [core] [Channel #9] Closing the name resolver
2024-09-05 13:10:50.564 [DBG] GRPC: [core] [Channel #9] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.564 [DBG] GRPC: [core] [Channel #9] Channel Connectivity change to IDLE
2024-09-05 13:10:50.564 [DBG] GRPC: [core] [Channel #9] Channel entering idle mode
2024-09-05 13:10:50.565 [DBG] GRPC: [core] [Channel #9 SubChannel #14] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.565 [DBG] GRPC: [core] [Channel #9 SubChannel #14] Subchannel deleted
2024-09-05 13:10:50.565 [DBG] GRPC: [transport] [client-transport 0x40004d5688] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.566 [DBG] GRPC: [transport] [server-transport 0x400084d520] Closing: EOF
2024-09-05 13:10:50.566 [DBG] GRPC: [transport] [client-transport 0x40004d5688] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.566 [DBG] GRPC: [transport] [server-transport 0x400084d520] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.578 [DBG] GRPC: [core] [Channel #15] Closing the name resolver
2024-09-05 13:10:50.578 [DBG] GRPC: [core] [Channel #15] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.579 [DBG] GRPC: [core] [Channel #15] Channel Connectivity change to IDLE
2024-09-05 13:10:50.579 [DBG] GRPC: [core] [Channel #15] Channel entering idle mode
2024-09-05 13:10:50.580 [DBG] GRPC: [core] [Channel #15 SubChannel #18] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.580 [DBG] GRPC: [core] [Channel #15 SubChannel #18] Subchannel deleted
2024-09-05 13:10:50.581 [DBG] GRPC: [transport] [client-transport 0x4000634b48] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.581 [DBG] GRPC: [transport] [server-transport 0x4000145040] Closing: EOF
2024-09-05 13:10:50.581 [DBG] GRPC: [transport] [client-transport 0x4000634b48] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.582 [DBG] GRPC: [transport] [server-transport 0x4000145040] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.592 [DBG] GRPC: [core] [Channel #19] Closing the name resolver
2024-09-05 13:10:50.593 [DBG] GRPC: [core] [Channel #19] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.593 [DBG] GRPC: [core] [Channel #19] Channel Connectivity change to IDLE
2024-09-05 13:10:50.593 [DBG] GRPC: [core] [Channel #19] Channel entering idle mode
2024-09-05 13:10:50.594 [DBG] GRPC: [core] [Channel #19 SubChannel #20] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.594 [DBG] GRPC: [core] [Channel #19 SubChannel #20] Subchannel deleted
2024-09-05 13:10:50.594 [DBG] GRPC: [transport] [client-transport 0x400014d208] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.595 [DBG] GRPC: [transport] [server-transport 0x400084d6c0] Closing: EOF
2024-09-05 13:10:50.595 [DBG] GRPC: [transport] [server-transport 0x400084d6c0] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.595 [DBG] GRPC: [transport] [client-transport 0x400014d208] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.600 [DBG] GRPC: [core] [Channel #23] Closing the name resolver
2024-09-05 13:10:50.600 [DBG] GRPC: [core] [Channel #23] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.600 [DBG] GRPC: [core] [Channel #23] Channel Connectivity change to IDLE
2024-09-05 13:10:50.600 [DBG] GRPC: [core] [Channel #23] Channel entering idle mode
2024-09-05 13:10:50.601 [DBG] GRPC: [core] [Channel #23 SubChannel #26] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.601 [DBG] GRPC: [core] [Channel #23 SubChannel #26] Subchannel deleted
2024-09-05 13:10:50.601 [DBG] GRPC: [transport] [client-transport 0x40001e3b08] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.602 [DBG] GRPC: [transport] [client-transport 0x40001e3b08] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.602 [DBG] GRPC: [transport] [server-transport 0x40000f9520] Closing: EOF
2024-09-05 13:10:50.603 [DBG] GRPC: [transport] [server-transport 0x40000f9520] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.610 [DBG] GRPC: [core] [Channel #27] Closing the name resolver
2024-09-05 13:10:50.610 [DBG] GRPC: [core] [Channel #27] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.610 [DBG] GRPC: [core] [Channel #27] Channel Connectivity change to IDLE
2024-09-05 13:10:50.611 [DBG] GRPC: [core] [Channel #27] Channel entering idle mode
2024-09-05 13:10:50.611 [DBG] GRPC: [core] [Channel #27 SubChannel #30] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.611 [DBG] GRPC: [core] [Channel #27 SubChannel #30] Subchannel deleted
2024-09-05 13:10:50.612 [DBG] GRPC: [transport] [client-transport 0x4000634fc8] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.612 [DBG] GRPC: [transport] [client-transport 0x4000634fc8] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.612 [DBG] GRPC: [transport] [server-transport 0x40001451e0] Closing: EOF
2024-09-05 13:10:50.613 [DBG] GRPC: [transport] [server-transport 0x40001451e0] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.614 [DBG] GRPC: [core] [Channel #33] Closing the name resolver
2024-09-05 13:10:50.614 [DBG] GRPC: [core] [Channel #33] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.614 [DBG] GRPC: [core] [Channel #33] Channel Connectivity change to IDLE
2024-09-05 13:10:50.615 [DBG] GRPC: [core] [Channel #33] Channel entering idle mode
2024-09-05 13:10:50.615 [DBG] GRPC: [core] [Channel #33 SubChannel #34] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.616 [DBG] GRPC: [core] [Channel #33 SubChannel #34] Subchannel deleted
2024-09-05 13:10:50.616 [DBG] GRPC: [transport] [client-transport 0x4000b56248] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.616 [DBG] GRPC: [transport] [server-transport 0x4000145380] Closing: EOF
2024-09-05 13:10:50.616 [DBG] GRPC: [transport] [client-transport 0x4000b56248] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.617 [DBG] GRPC: [transport] [server-transport 0x4000145380] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.621 [DBG] GRPC: [core] [Channel #35] Closing the name resolver
2024-09-05 13:10:50.621 [DBG] GRPC: [core] [Channel #35] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.621 [DBG] GRPC: [core] [Channel #35] Channel Connectivity change to IDLE
2024-09-05 13:10:50.621 [DBG] GRPC: [core] [Channel #35] Channel entering idle mode
2024-09-05 13:10:50.621 [DBG] GRPC: [core] [Channel #35 SubChannel #38] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.622 [DBG] GRPC: [core] [Channel #35 SubChannel #38] Subchannel deleted
2024-09-05 13:10:50.622 [DBG] GRPC: [transport] [client-transport 0x40009fe008] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.623 [DBG] GRPC: [transport] [client-transport 0x40009fe008] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.623 [DBG] GRPC: [transport] [server-transport 0x40005b3040] Closing: EOF
2024-09-05 13:10:50.628 [DBG] GRPC: [transport] [server-transport 0x40005b3040] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.635 [DBG] GRPC: [core] [Channel #39] Closing the name resolver
2024-09-05 13:10:50.635 [DBG] GRPC: [core] [Channel #39] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.635 [DBG] GRPC: [core] [Channel #39] Channel Connectivity change to IDLE
2024-09-05 13:10:50.635 [DBG] GRPC: [core] [Channel #39] Channel entering idle mode
2024-09-05 13:10:50.636 [DBG] GRPC: [core] [Channel #39 SubChannel #42] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.636 [DBG] GRPC: [core] [Channel #39 SubChannel #42] Subchannel deleted
2024-09-05 13:10:50.637 [DBG] GRPC: [transport] [client-transport 0x400014cfc8] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.637 [DBG] GRPC: [transport] [server-transport 0x40000f8000] Closing: EOF
2024-09-05 13:10:50.637 [DBG] GRPC: [transport] [server-transport 0x40000f8000] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.637 [DBG] GRPC: [transport] [client-transport 0x400014cfc8] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.644 [DBG] GRPC: [core] [Channel #45] Closing the name resolver
2024-09-05 13:10:50.644 [DBG] GRPC: [core] [Channel #45] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.644 [DBG] GRPC: [core] [Channel #45] Channel Connectivity change to IDLE
2024-09-05 13:10:50.645 [DBG] GRPC: [core] [Channel #45] Channel entering idle mode
2024-09-05 13:10:50.645 [DBG] GRPC: [core] [Channel #45 SubChannel #46] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.645 [DBG] GRPC: [core] [Channel #45 SubChannel #46] Subchannel deleted
2024-09-05 13:10:50.646 [DBG] GRPC: [transport] [client-transport 0x400014d688] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.646 [DBG] GRPC: [transport] [server-transport 0x40000f8680] Closing: EOF
2024-09-05 13:10:50.646 [DBG] GRPC: [transport] [client-transport 0x400014d688] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.647 [DBG] GRPC: [transport] [server-transport 0x40000f8680] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.653 [DBG] GRPC: [core] [Channel #47] Closing the name resolver
2024-09-05 13:10:50.653 [DBG] GRPC: [core] [Channel #47] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.653 [DBG] GRPC: [core] [Channel #47] Channel Connectivity change to IDLE
2024-09-05 13:10:50.654 [DBG] GRPC: [core] [Channel #47] Channel entering idle mode
2024-09-05 13:10:50.654 [DBG] GRPC: [core] [Channel #47 SubChannel #50] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.654 [DBG] GRPC: [core] [Channel #47 SubChannel #50] Subchannel deleted
2024-09-05 13:10:50.655 [DBG] GRPC: [transport] [client-transport 0x400014dd48] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.655 [DBG] GRPC: [transport] [client-transport 0x400014dd48] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.655 [DBG] GRPC: [transport] [server-transport 0x4000145520] Closing: EOF
2024-09-05 13:10:50.656 [DBG] GRPC: [transport] [server-transport 0x4000145520] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.662 [DBG] GRPC: [core] [Channel #51] Closing the name resolver
2024-09-05 13:10:50.662 [DBG] GRPC: [core] [Channel #51] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.662 [DBG] GRPC: [core] [Channel #51] Channel Connectivity change to IDLE
2024-09-05 13:10:50.663 [DBG] GRPC: [core] [Channel #51] Channel entering idle mode
2024-09-05 13:10:50.663 [DBG] GRPC: [core] [Channel #51 SubChannel #54] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.663 [DBG] GRPC: [core] [Channel #51 SubChannel #54] Subchannel deleted
2024-09-05 13:10:50.664 [DBG] GRPC: [transport] [client-transport 0x40009fe488] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.664 [DBG] GRPC: [transport] [client-transport 0x40009fe488] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.664 [DBG] GRPC: [transport] [server-transport 0x40000f9860] Closing: EOF
2024-09-05 13:10:50.665 [DBG] GRPC: [transport] [server-transport 0x40000f9860] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.668 [DBG] GRPC: [core] [Channel #55] Closing the name resolver
2024-09-05 13:10:50.668 [DBG] GRPC: [core] [Channel #55] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.668 [DBG] GRPC: [core] [Channel #55] Channel Connectivity change to IDLE
2024-09-05 13:10:50.669 [DBG] GRPC: [core] [Channel #55] Channel entering idle mode
2024-09-05 13:10:50.669 [DBG] GRPC: [core] [Channel #55 SubChannel #58] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.669 [DBG] GRPC: [core] [Channel #55 SubChannel #58] Subchannel deleted
2024-09-05 13:10:50.670 [DBG] GRPC: [transport] [client-transport 0x4000634488] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.670 [DBG] GRPC: [transport] [client-transport 0x4000634488] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.670 [DBG] GRPC: [transport] [server-transport 0x4000145860] Closing: EOF
2024-09-05 13:10:50.671 [DBG] GRPC: [transport] [server-transport 0x4000145860] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.676 [DBG] GRPC: [core] [Channel #61] Closing the name resolver
2024-09-05 13:10:50.676 [DBG] GRPC: [core] [Channel #61] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.677 [DBG] GRPC: [core] [Channel #61] Channel Connectivity change to IDLE
2024-09-05 13:10:50.677 [DBG] GRPC: [core] [Channel #61] Channel entering idle mode
2024-09-05 13:10:50.677 [DBG] GRPC: [core] [Channel #61 SubChannel #62] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.678 [DBG] GRPC: [core] [Channel #61 SubChannel #62] Subchannel deleted
2024-09-05 13:10:50.678 [DBG] GRPC: [transport] [client-transport 0x40001e2b48] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.678 [DBG] GRPC: [transport] [server-transport 0x400058cb60] Closing: EOF
2024-09-05 13:10:50.678 [DBG] GRPC: [transport] [client-transport 0x40001e2b48] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.679 [DBG] GRPC: [transport] [server-transport 0x400058cb60] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.682 [DBG] GRPC: [core] [Channel #63] Closing the name resolver
2024-09-05 13:10:50.682 [DBG] GRPC: [core] [Channel #63] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.682 [DBG] GRPC: [core] [Channel #63] Channel Connectivity change to IDLE
2024-09-05 13:10:50.683 [DBG] GRPC: [core] [Channel #63] Channel entering idle mode
2024-09-05 13:10:50.683 [DBG] GRPC: [core] [Channel #63 SubChannel #66] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.683 [DBG] GRPC: [core] [Channel #63 SubChannel #66] Subchannel deleted
2024-09-05 13:10:50.684 [DBG] GRPC: [transport] [client-transport 0x40009fe908] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.684 [DBG] GRPC: [transport] [client-transport 0x40009fe908] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.684 [DBG] GRPC: [transport] [server-transport 0x40005b2680] Closing: EOF
2024-09-05 13:10:50.685 [DBG] GRPC: [transport] [server-transport 0x40005b2680] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.689 [DBG] GRPC: [core] [Channel #67] Closing the name resolver
2024-09-05 13:10:50.689 [DBG] GRPC: [core] [Channel #67] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.689 [DBG] GRPC: [core] [Channel #67] Channel Connectivity change to IDLE
2024-09-05 13:10:50.689 [DBG] GRPC: [core] [Channel #67] Channel entering idle mode
2024-09-05 13:10:50.690 [DBG] GRPC: [core] [Channel #67 SubChannel #70] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.690 [DBG] GRPC: [core] [Channel #67 SubChannel #70] Subchannel deleted
2024-09-05 13:10:50.690 [DBG] GRPC: [transport] [client-transport 0x40001e3688] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.691 [DBG] GRPC: [transport] [server-transport 0x4000145ba0] Closing: EOF
2024-09-05 13:10:50.691 [DBG] GRPC: [transport] [client-transport 0x40001e3688] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.691 [DBG] GRPC: [transport] [server-transport 0x4000145ba0] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.695 [DBG] GRPC: [core] [Channel #71] Closing the name resolver
2024-09-05 13:10:50.695 [DBG] GRPC: [core] [Channel #71] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.695 [DBG] GRPC: [core] [Channel #71] Channel Connectivity change to IDLE
2024-09-05 13:10:50.696 [DBG] GRPC: [core] [Channel #71] Channel entering idle mode
2024-09-05 13:10:50.696 [DBG] GRPC: [core] [Channel #71 SubChannel #74] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.696 [DBG] GRPC: [core] [Channel #71 SubChannel #74] Subchannel deleted
2024-09-05 13:10:50.697 [DBG] GRPC: [transport] [client-transport 0x40004d4488] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.697 [DBG] GRPC: [transport] [client-transport 0x40004d4488] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.697 [DBG] GRPC: [transport] [server-transport 0x40005b2820] Closing: EOF
2024-09-05 13:10:50.698 [DBG] GRPC: [transport] [server-transport 0x40005b2820] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.705 [DBG] GRPC: [core] [Channel #75] Closing the name resolver
2024-09-05 13:10:50.705 [DBG] GRPC: [core] [Channel #75] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.705 [DBG] GRPC: [core] [Channel #75] Channel Connectivity change to IDLE
2024-09-05 13:10:50.706 [DBG] GRPC: [core] [Channel #75] Channel entering idle mode
2024-09-05 13:10:50.706 [DBG] GRPC: [core] [Channel #75 SubChannel #78] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.706 [DBG] GRPC: [core] [Channel #75 SubChannel #78] Subchannel deleted
2024-09-05 13:10:50.707 [DBG] GRPC: [transport] [client-transport 0x40004d4fc8] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.707 [DBG] GRPC: [transport] [server-transport 0x40005b29c0] Closing: EOF
2024-09-05 13:10:50.707 [DBG] GRPC: [transport] [client-transport 0x40004d4fc8] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.708 [DBG] GRPC: [transport] [server-transport 0x40005b29c0] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.715 [DBG] GRPC: [core] [Channel #79] Closing the name resolver
2024-09-05 13:10:50.715 [DBG] GRPC: [core] [Channel #79] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.715 [DBG] GRPC: [core] [Channel #79] Channel Connectivity change to IDLE
2024-09-05 13:10:50.715 [DBG] GRPC: [core] [Channel #79] Channel entering idle mode
2024-09-05 13:10:50.716 [DBG] GRPC: [core] [Channel #79 SubChannel #82] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.716 [DBG] GRPC: [core] [Channel #79 SubChannel #82] Subchannel deleted
2024-09-05 13:10:50.716 [DBG] GRPC: [transport] [client-transport 0x4000b56d88] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.717 [DBG] GRPC: [transport] [server-transport 0x40005b2ea0] Closing: EOF
2024-09-05 13:10:50.717 [DBG] GRPC: [transport] [client-transport 0x4000b56d88] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.717 [DBG] GRPC: [transport] [server-transport 0x40005b2ea0] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.724 [DBG] GRPC: [core] [Channel #85] Closing the name resolver
2024-09-05 13:10:50.724 [DBG] GRPC: [core] [Channel #85] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.724 [DBG] GRPC: [core] [Channel #85] Channel Connectivity change to IDLE
2024-09-05 13:10:50.724 [DBG] GRPC: [core] [Channel #85] Channel entering idle mode
2024-09-05 13:10:50.725 [DBG] GRPC: [core] [Channel #85 SubChannel #86] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.725 [DBG] GRPC: [core] [Channel #85 SubChannel #86] Subchannel deleted
2024-09-05 13:10:50.725 [DBG] GRPC: [transport] [client-transport 0x40009fefc8] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.726 [DBG] GRPC: [transport] [server-transport 0x400084c000] Closing: EOF
2024-09-05 13:10:50.726 [DBG] GRPC: [transport] [client-transport 0x40009fefc8] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.726 [DBG] GRPC: [transport] [server-transport 0x400084c000] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.730 [DBG] GRPC: [core] [Channel #89] Closing the name resolver
2024-09-05 13:10:50.730 [DBG] GRPC: [core] [Channel #89] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.730 [DBG] GRPC: [core] [Channel #89] Channel Connectivity change to IDLE
2024-09-05 13:10:50.731 [DBG] GRPC: [core] [Channel #89] Channel entering idle mode
2024-09-05 13:10:50.731 [DBG] GRPC: [core] [Channel #89 SubChannel #90] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.731 [DBG] GRPC: [core] [Channel #89 SubChannel #90] Subchannel deleted
2024-09-05 13:10:50.732 [DBG] GRPC: [transport] [client-transport 0x4000b57448] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.732 [DBG] GRPC: [transport] [client-transport 0x4000b57448] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.732 [DBG] GRPC: [transport] [server-transport 0x40005b3520] Closing: EOF
2024-09-05 13:10:50.733 [DBG] GRPC: [transport] [server-transport 0x40005b3520] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.738 [DBG] GRPC: [core] [Channel #91] Closing the name resolver
2024-09-05 13:10:50.738 [DBG] GRPC: [core] [Channel #91] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.738 [DBG] GRPC: [core] [Channel #91] Channel Connectivity change to IDLE
2024-09-05 13:10:50.738 [DBG] GRPC: [core] [Channel #91] Channel entering idle mode
2024-09-05 13:10:50.739 [DBG] GRPC: [core] [Channel #91 SubChannel #94] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.739 [DBG] GRPC: [core] [Channel #91 SubChannel #94] Subchannel deleted
2024-09-05 13:10:50.739 [DBG] GRPC: [transport] [client-transport 0x4000635208] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.740 [DBG] GRPC: [transport] [client-transport 0x4000635208] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.740 [DBG] GRPC: [transport] [server-transport 0x40005b3860] Closing: EOF
2024-09-05 13:10:50.741 [DBG] GRPC: [transport] [server-transport 0x40005b3860] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.749 [DBG] GRPC: [core] [Channel #95] Closing the name resolver
2024-09-05 13:10:50.749 [DBG] GRPC: [core] [Channel #95] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.750 [DBG] GRPC: [core] [Channel #95] Channel Connectivity change to IDLE
2024-09-05 13:10:50.750 [DBG] GRPC: [core] [Channel #95] Channel entering idle mode
2024-09-05 13:10:50.750 [DBG] GRPC: [core] [Channel #95 SubChannel #98] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.750 [DBG] GRPC: [core] [Channel #95 SubChannel #98] Subchannel deleted
2024-09-05 13:10:50.751 [DBG] GRPC: [transport] [client-transport 0x4000635688] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.751 [DBG] GRPC: [transport] [server-transport 0x40001d5380] Closing: EOF
2024-09-05 13:10:50.751 [DBG] GRPC: [transport] [client-transport 0x4000635688] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.752 [DBG] GRPC: [transport] [server-transport 0x40001d5380] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.757 [DBG] GRPC: [core] [Channel #99] Closing the name resolver
2024-09-05 13:10:50.757 [DBG] GRPC: [core] [Channel #99] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.757 [DBG] GRPC: [core] [Channel #99] Channel Connectivity change to IDLE
2024-09-05 13:10:50.757 [DBG] GRPC: [core] [Channel #99] Channel entering idle mode
2024-09-05 13:10:50.758 [DBG] GRPC: [core] [Channel #99 SubChannel #102] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.758 [DBG] GRPC: [core] [Channel #99 SubChannel #102] Subchannel deleted
2024-09-05 13:10:50.758 [DBG] GRPC: [transport] [client-transport 0x40004d5208] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.759 [DBG] GRPC: [transport] [server-transport 0x40001d56c0] Closing: EOF
2024-09-05 13:10:50.759 [DBG] GRPC: [transport] [server-transport 0x40001d56c0] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.759 [DBG] GRPC: [transport] [client-transport 0x40004d5208] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.766 [DBG] GRPC: [core] [Channel #103] Closing the name resolver
2024-09-05 13:10:50.766 [DBG] GRPC: [core] [Channel #103] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.766 [DBG] GRPC: [core] [Channel #103] Channel Connectivity change to IDLE
2024-09-05 13:10:50.766 [DBG] GRPC: [core] [Channel #103] Channel entering idle mode
2024-09-05 13:10:50.767 [DBG] GRPC: [core] [Channel #103 SubChannel #106] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.767 [DBG] GRPC: [core] [Channel #103 SubChannel #106] Subchannel deleted
2024-09-05 13:10:50.767 [DBG] GRPC: [transport] [client-transport 0x4000634248] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.768 [DBG] GRPC: [transport] [client-transport 0x4000634248] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.768 [DBG] GRPC: [transport] [server-transport 0x400084c1a0] Closing: EOF
2024-09-05 13:10:50.768 [DBG] GRPC: [transport] [server-transport 0x400084c1a0] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.775 [DBG] GRPC: [core] [Channel #107] Closing the name resolver
2024-09-05 13:10:50.775 [DBG] GRPC: [core] [Channel #107] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.775 [DBG] GRPC: [core] [Channel #107] Channel Connectivity change to IDLE
2024-09-05 13:10:50.776 [DBG] GRPC: [core] [Channel #107] Channel entering idle mode
2024-09-05 13:10:50.776 [DBG] GRPC: [core] [Channel #107 SubChannel #110] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.776 [DBG] GRPC: [core] [Channel #107 SubChannel #110] Subchannel deleted
2024-09-05 13:10:50.777 [DBG] GRPC: [transport] [client-transport 0x40004d5b08] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.777 [DBG] GRPC: [transport] [client-transport 0x40004d5b08] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.777 [DBG] GRPC: [transport] [server-transport 0x40005b3d40] Closing: EOF
2024-09-05 13:10:50.778 [DBG] GRPC: [transport] [server-transport 0x40005b3d40] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.783 [DBG] GRPC: [core] [Channel #111] Closing the name resolver
2024-09-05 13:10:50.783 [DBG] GRPC: [core] [Channel #111] ccBalancerWrapper: entering idle mode
2024-09-05 13:10:50.784 [DBG] GRPC: [core] [Channel #111] Channel Connectivity change to IDLE
2024-09-05 13:10:50.784 [DBG] GRPC: [core] [Channel #111] Channel entering idle mode
2024-09-05 13:10:50.784 [DBG] GRPC: [core] [Channel #111 SubChannel #112] Subchannel Connectivity change to SHUTDOWN
2024-09-05 13:10:50.784 [DBG] GRPC: [core] [Channel #111 SubChannel #112] Subchannel deleted
2024-09-05 13:10:50.785 [DBG] GRPC: [transport] [client-transport 0x40009feb48] Closing: grpc: the connection is closing due to channel idleness
2024-09-05 13:10:50.785 [DBG] GRPC: [transport] [client-transport 0x40009feb48] loopyWriter exiting with error: transport closed by client
2024-09-05 13:10:50.785 [DBG] GRPC: [transport] [server-transport 0x400084c820] Closing: EOF
2024-09-05 13:10:50.786 [DBG] GRPC: [transport] [server-transport 0x400084c820] loopyWriter exiting with error: transport closed by client
2024-09-05 13:11:08.180 [DBG] HLCK: invoking success callback
2024-09-05 13:12:08.192 [DBG] HLCK: invoking success callback
2024-09-05 13:12:42.556 [INF] CRTR: Pruning channel graph using block 4be9a61cd21af5a3dea6ea730cb283de4121fa6a6246b84c8578ca087371f2d6 (height=2483)
2024-09-05 13:12:42.555 [DBG] LNWL: Filtering block 2483 (4be9a61cd21af5a3dea6ea730cb283de4121fa6a6246b84c8578ca087371f2d6) with 1 transactions
2024-09-05 13:12:42.564 [DBG] CHDB: Pruned graph, cache now has num_node_features=0, num_nodes=0, num_channels=0
2024-09-05 13:12:42.565 [INF] CRTR: Block 4be9a61cd21af5a3dea6ea730cb283de4121fa6a6246b84c8578ca087371f2d6 (height=2483) closed 0 channels
2024-09-05 13:12:42.866 [DBG] NTFN: Filtering 1 txns for 0 spend requests at height 2483
2024-09-05 13:12:42.866 [INF] NTFN: New block: height=2483, sha=4be9a61cd21af5a3dea6ea730cb283de4121fa6a6246b84c8578ca087371f2d6
2024-09-05 13:12:42.868 [DBG] SWPR: Received new block: height=2483, attempt sweeping 0 inputs
2024-09-05 13:12:42.868 [DBG] DISC: New block: height=2483, hash=4be9a61cd21af5a3dea6ea730cb283de4121fa6a6246b84c8578ca087371f2d6
2024-09-05 13:12:42.869 [DBG] SWPR: TxPublisher received new block: 2483
2024-09-05 13:12:42.869 [INF] UTXN: Attempting to graduate height=2483: num_kids=0, num_babies=0
2024-09-05 13:13:08.190 [DBG] HLCK: invoking success callback
2024-09-05 13:14:08.245 [DBG] HLCK: invoking success callback

The DeriveTapscriptRoot called log line makes it seem like things are hanging here: https://github.com/lightninglabs/taproot-assets/blob/72551b4031d85872f5b32af5b68e0a210121380c/server.go#L930
which means the taproot assets server isnt starting up properly....
@lukegao209  - could you post logs closer to start up time? hopefully something there can indicate to us where Tapd is getting stuck

here are all the logs :
logs.txt

@lukegao209  - and could I also just ask for your LiT config file/ start up flags?  Refusing to start with --no-macaroons specified",
"custom_status": ""
}
}
}
{
"state": "SERVER_ACTIVE"
}

thanks!
ok I think this is the magic line:
2024-09-05 12:58:13.962 [ERR] STAT: could not start the taproot-assets sub-server: ValidateConfig: error enforcing safe authentication on RPC ports: detected RPC server listening on publicly reachable interface <IP_ADDRESS>:10029 with authentication disabled! Refusing to start with --no-macaroons specified

so the solution here is to not expose the taproot-assets rpc & rest interfaces on public <IP_ADDRESS> interface.
Since you are initialising it in --stateless_init mode, only LiT will be able to access the taproot-assets server directly anways so there should not be a need to expose it publically

how to fix it？ should I call it from 8443 port？

ok, I will test it on 8443

Yes, you can use 8443 for all RPC (and REST if you use --enablerest) calls. You just need to use the ~/.lit/tls.cert, but other than that everything should work as expected over the main litd port.

I can't initwallet by 8443 , and taproot assets doesn't work if I initWallet by 10009
/ # lncli -n regtest --rpcserver=<IP_ADDRESS>:8443 --tlscertpath=~/.lit/tls.cert create --stateless_init --save_to admin.macaroon
Input wallet password:
Confirm password:

Do you have an existing cipher seed mnemonic or extended master root key you want to use?
Enter 'y' to use an existing cipher seed mnemonic, 'x' to use an extended master root key
or 'n' to create a new seed (Enter y/x/n): n

Your cipher seed can optionally be encrypted.
Input your passphrase if you wish to encrypt it (or press enter to proceed without a cipher seed passphrase):

Generating fresh cipher seed...

[lncli] unable to generate seed: rpc error: code = Unknown desc = lnd is not ready for: /lnrpc.WalletUnlocker/GenSeed
/ #

So what @ellemouton suggested, is that you should first remove these lines from your startup command for litd:
  - "--taproot-assets.rpclisten=<IP_ADDRESS>:10029"
  - "--taproot-assets.restlisten=<IP_ADDRESS>:8089"

For running lncli commands specifically in stateless_init mode, you don't need to use the port 8443 (which is port for litd), therefore you can run like this:
lncli -n regtest --stateless_init --save_to admin.macaroon
For other lncli commands that require a macaroon, you need to specify that the --macaroonpath is set to the admin.macaroon created in that create command.
However, you need to use the 8443 port for litd´s other sub-servers, i.e. loop, pool, tapcli & frcli. Those you would run like this:
loop --rpcserver=<IP_ADDRESS>:8443 --tlscertpath=~/.lit/tls.cert --macaroonpath=<PATH_TO_SUPMACAROON_CREATED_WITH_LNCLI_BAKEMACAROON> getinfo

pool --rpcserver=<IP_ADDRESS>:8443 --tlscertpath=~/.lit/tls.cert --macaroonpath=<PATH_TO_SUPMACAROON_CREATED_WITH_LNCLI_BAKEMACAROON> getinfo

tapcli --rpcserver=<IP_ADDRESS>:8443 --tlscertpath=~/.lit/tls.cert --macaroonpath=<PATH_TO_SUPMACAROON_CREATED_WITH_LNCLI_BAKEMACAROON> getinfo

frcli --rpcserver=<IP_ADDRESS>:8443 --tlscertpath=~/.lit/tls.cert --macaroonpath=<PATH_TO_SUPMACAROON_CREATED_WITH_LNCLI_BAKEMACAROON> revenue

What @ellemouton recommended, is that you should first remove these lines from your startup command for litd:
  - "--taproot-assets.rpclisten=<IP_ADDRESS>:10029"
  - "--taproot-assets.restlisten=<IP_ADDRESS>:8089"

For running lncli commands specifically in stateless_init mode, you don't need to use the port 8443 (which is the port for litd), therefore you can run like this: lncli -n regtest create --stateless_init --save_to admin.macaroon
For other lncli commands that require a macaroon, you need to specify that the --macaroonpath is set to the admin.macaroon created in that create command.
However, you need to use the 8443 port for litd´s other sub-servers, i.e. loop, pool, tapcli & frcli. Those you would run like this:
loop --rpcserver=<IP_ADDRESS>:8443 --tlscertpath=~/.lit/tls.cert --macaroonpath=<PATH_TO_LIT_SUPERMACAROON_CREATED_WITH_LNCLI_BAKEMACAROON> getinfo

pool --rpcserver=<IP_ADDRESS>:8443 --tlscertpath=~/.lit/tls.cert --macaroonpath=<PATH_TO_LIT_SUPERMACAROON_CREATED_WITH_LNCLI_BAKEMACAROON> getinfo

tapcli --rpcserver=<IP_ADDRESS>:8443 --tlscertpath=~/.lit/tls.cert --macaroonpath=<PATH_TO_LIT_SUPERMACAROON_CREATED_WITH_LNCLI_BAKEMACAROON> getinfo

frcli --rpcserver=<IP_ADDRESS>:8443 --tlscertpath=~/.lit/tls.cert --macaroonpath=<PATH_TO_LIT_SUPERMACAROON_CREATED_WITH_LNCLI_BAKEMACAROON> revenue

tested.
1.	‘Open channel’ is now working.
2.	lit init failed, and no macaroon was generated for lit, making it impossible to access tapd.”
/ # litcli -n regtest status
{
    "sub_servers": {
        "accounts": {
            "disabled": false,
            "running": false,
            "error": "",
            "custom_status": ""
        },
        "faraday": {
            "disabled": true,
            "running": false,
            "error": "",
            "custom_status": ""
        },
        "lit": {
            "disabled": false,
            "running": false,
            "error": "Error when creating LND Services client: error waiting for chain to be synced: error in GetInfo call: rpc error: code = DeadlineExceeded desc = context deadline exceeded",
            "custom_status": ""
        },
        "lnd": {
            "disabled": false,
            "running": false,
            "error": "",
            "custom_status": "Wallet Ready"
        },
        "loop": {
            "disabled": true,
            "running": false,
            "error": "",
            "custom_status": ""
        },
        "pool": {
            "disabled": true,
            "running": false,
            "error": "",
            "custom_status": ""
        },
        "taproot-assets": {
            "disabled": false,
            "running": false,
            "error": "",
            "custom_status": ""
        }
    }
}
{
    "state": "RPC_ACTIVE"
}

Logs please. Something else seems to go wrong now.

Logs please. Something else seems to go wrong now.

Logs:
logs.txt
docker-compose.yml =>
name: lnfi-${LIT_NETWORK}
services:
  lit:
    image: lightninglabs/lightning-terminal:v0.13.993-experimental
    container_name: ${LIT_NAME}-litd-${LIT_NETWORK}
    hostname: ${LIT_NAME}-litd-${LIT_NETWORK}
    volumes:
      - ${LIT_DATA_PATH}/${LIT_NAME}/lit:/root/.lit
      - ${LIT_DATA_PATH}/${LIT_NAME}/lnd:/root/.lnd
      - ${LIT_DATA_PATH}/${LIT_NAME}/loop:/root/.loop
      - ${LIT_DATA_PATH}/${LIT_NAME}/tapd:/root/.tapd
      - ${TOR_PATH}:/root/.tor
    expose:
      - "9735"
      - "8443"
      - "8442"
      - "10009"
      - "10010"
      - "10029"
    ports:
      - "${LIT_PORT_HTTPS}:8443"
      - "${LIT_PORT_LND}:10009"
    command:
      - "lightning-terminal"
      - "--httpslisten=<IP_ADDRESS>:8443"
      - "--insecure-httplisten=<IP_ADDRESS>:8442"
      - "--uipassword=${LIT_UI_PASSWORD}"
      - "--network=${LIT_NETWORK}"
      - "--tlsextradomain=${LIT_TLSEXTRADOMAIN}"
      - "--tlsextradomain=${LIT_NAME}-litd-${LIT_NETWORK}"
      - "--tlsextradomain=${TAPD_TLSEXTRADOMAIN}"
      - "--tlsextraip=${LIT_TLSEXTRAIP}"
      - "--tlsextraip=<IP_ADDRESS>"

      - "--lnd-mode=integrated"
      - "--lnd.bitcoin.active"
      - "--lnd.bitcoin.node=bitcoind"
      - "--lnd.alias=${LND_ALIAS}"
      - "--lnd.tlsextradomain=${LIT_TLSEXTRADOMAIN}"
      - "--lnd.tlsextradomain=${LIT_NAME}-litd-${LIT_NETWORK}"
      - "--lnd.tlsextradomain=${TAPD_TLSEXTRADOMAIN}"
      - "--lnd.tlsextradomain=localhost"
      - "--lnd.tlsextraip=${LIT_TLSEXTRAIP}"
      - "--lnd.tlsextraip=<IP_ADDRESS>"
      - "--lnd.externalip=${LND_EXTERNALIP}"
      - "--lnd.rpclisten=<IP_ADDRESS>:10009"
      - "--lnd.listen=<IP_ADDRESS>:9735"
      - "--lnd.debuglevel=debug"
      - "--lnd.rpcmiddleware.enable"
      - "--lnd.protocol.wumbo-channels"
      - "--lnd.maxpendingchannels=10"
      - "--lnd.protocol.option-scid-alias"
      - "--lnd.protocol.zero-conf"
      - "--lnd.protocol.simple-taproot-chans"
      - "--lnd.protocol.simple-taproot-overlay-chans"
      - "--lnd.protocol.custom-message=17"
      - "--lnd.allow-circular-route"
      - "--lnd.accept-keysend"
      - "--lnd.addpeer=${NOSTR_NODE_NPUBKEY}@${NOSTR_NODE_HOST}"

      - "--lnd.bitcoind.rpchost=${BITCOIND_RPCHOST}"
      - "--lnd.bitcoind.rpcuser=${BITCOIND_RPCUSER}"
      - "--lnd.bitcoind.rpcpass=${BITCOIND_RPCPASS}"
      - "--lnd.bitcoind.zmqpubrawblock=${BITCOIND_ZMQBLOCK}"
      - "--lnd.bitcoind.zmqpubrawtx=${BITCOIND_ZMQRAWTX}"

      # - "--lnd.tor.active"
      # - "--lnd.tor.v3"
      # - "--lnd.tor.skip-proxy-for-clearnet-targets"
      # - "--lnd.tor.dns=nodes.lightning.directory"
      # - "--lnd.tor.socks=${TOR_SOCKS}"
      # - "--lnd.tor.control=${TOR_CONTROL}"

      - "--autopilot.disable"

      - "--taproot-assets-mode=integrated"
      # - "--taproot-assets.rpclisten=<IP_ADDRESS>:10029"
      # - "--taproot-assets.restlisten=<IP_ADDRESS>:8089"
      - "--taproot-assets.tlsextradomain=${TAPD_TLSEXTRADOMAIN}"
      - "--taproot-assets.tlsextraip=${TAPD_TLSEXTRAIP}"
      - "--taproot-assets.tlsextraip=<IP_ADDRESS>"
      - "--taproot-assets.universe.public-access=rw"
      - "--taproot-assets.universe.sync-all-assets"
      - "--taproot-assets.allow-public-uni-proof-courier"
      - "--taproot-assets.allow-public-stats"
      - "--taproot-assets.experimental.rfq.priceoracleaddress=rfqrpc://${ORACLE_SERVER_HOST}"
      # - "--taproot-assets.experimental.rfq.skipacceptquotepricecheck"
      # - "--taproot-assets.experimental.rfq.mockoraclesatsperasset=10"
      # - "--taproot-assets.tapddir=/root/.lit/tapd"
      # - "--taproot-assets.tlskeypath=/root/.lit/tls.key"
      # - "--taproot-assets.tlscertpath=/root/.lit/tls.cert"

      - "--faraday-mode=disable"
      - "--faraday.min_monitored=24h"
      - "--faraday.connect_bitcoin"
      - "--faraday.bitcoin.host=${BITCOIND_RPCHOST}"
      - "--faraday.bitcoin.user=${BITCOIND_RPCUSER}"
      - "--faraday.bitcoin.password=${BITCOIND_RPCPASS}"
      - "--faraday.debuglevel=info"

      - "--loop-mode=disable"
      - "--loop.network=${LIT_NETWORK}"
      - "--loop.tlsautorefresh"
      - "--loop.server.host=${LOOP_SERVER}"
      - "--loop.server.notls"

      - "--pool-mode=disable"
    networks:
      - lnfi_network
    logging:
      driver: "json-file"
      options:
        max-file: "3" # number of files or file count
        max-size: "50m" # file size
networks:
  lnfi_network:
    external: true

Looking at your logs, it looks like everything eventually started correctly in litd. It's just that the initial chain syncing took an extended amount of time (roughly 20mins). We're tracking that issue here: https://github.com/lightninglabs/lightning-terminal/issues/837
The positive news though, it seems like everything is working as expected after the initial sync! If you run litcli -n regtest status again now, are all the sub-servers that you haven't disabled set to running: true?

lit init failed, and no macaroon was generated for lit, making it impossible to access tapd.”

When running in stateless_init mode, it's expected that no macaroon should automatically be created for lit or the other sub-servers (loop, pool, tapd & faraday). Instead you have to manually create a supermacaroon with lncli that can be used with litcli + the different sub-severs.
In order to create that supermacaroon, follow these steps:

Run litcli helper supermacrootkey. That will return a root_key_id that should be used when baking the supermacaroon in the next step.
Run lncli -n regtest --macaroonpath <PATH_TO_LND_ADMIN_MACAROON_FROM_THE_LNCLI_CREATE_COMMAND> bakemacaroon --save_to /tmp/lit.macaroon --root_key_id <root_key_id> --allow_external_permissions account:read account:write actions:read autopilot:read autopilot:write privacymap:read proxy:read proxy:write sessions:read sessions:write supermacaroon:write suggestions:read suggestions:write swap:execute swap:read loop:out loop:in terms:read auth:read order:read order:write auction:read recommendation:read report:read insights:read rates:read audit:read daemon:write daemon:read assets:write assets:read addresses:read addresses:write proofs:read proofs:write mint:read mint:write universe:read universe:write rfq:write rfq:read channels:write

Note that this macaroon you create above contains all permissions from LiT + All different sub-servers, i.e.:
Lit: https://github.com/lightninglabs/lightning-terminal/blob/master/perms/permissions.go
Loop: https://github.com/lightninglabs/loop/blob/master/loopd/perms/perms.go
Pool: https://github.com/lightninglabs/pool/blob/master/perms/perms.go
Faraday: https://github.com/lightninglabs/faraday/blob/master/frdrpcserver/perms/perms.go
Tapd: https://github.com/lightninglabs/taproot-assets/blob/main/perms/perms.go
Those permissions may be updated in the future, and if they are, you may need to create a new macaroon to support new features. You can create individual macaroons for the different sub-servers if you prefer, by editing the permissions to match the specific sub-server's permissions.
You can use that macaroon to call the different sub-servers as I stated in my comment above:
loop --rpcserver=<IP_ADDRESS>:8443 --tlscertpath=~/.lit/tls.cert --macaroonpath=<PATH_TO_LIT_SUPERMACAROON_CREATED_WITH_LNCLI_BAKEMACAROON> getinfo

pool --rpcserver=<IP_ADDRESS>:8443 --tlscertpath=~/.lit/tls.cert --macaroonpath=<PATH_TO_LIT_SUPERMACAROON_CREATED_WITH_LNCLI_BAKEMACAROON> getinfo

tapcli --rpcserver=<IP_ADDRESS>:8443 --tlscertpath=~/.lit/tls.cert --macaroonpath=<PATH_TO_LIT_SUPERMACAROON_CREATED_WITH_LNCLI_BAKEMACAROON> getinfo

frcli --rpcserver=<IP_ADDRESS>:8443 --tlscertpath=~/.lit/tls.cert --macaroonpath=<PATH_TO_LIT_SUPERMACAROON_CREATED_WITH_LNCLI_BAKEMACAROON> revenue

For litcli, you would use:
litcli --macaroonpath=<PATH_TO_LIT_SUPERMACAROON_CREATED_WITH_LNCLI_BAKEMACAROON> COMMAND

Thanks for the reply. After generating the macaroon, tapd is now working. It seems that the overall configuration of parameters for terminal, lnd, and tapd can be quite confusing. I believe this poses a challenge for most developers. I’d recommend looking into ways to simplify the setup.


After upgrading from v12.0.3 to v12.1.1 of amplify-cli, amplify api gql-compile is impossible due to field-level authorization error

How did you install the Amplify CLI?
yarn
If applicable, what version of Node.js are you using?
v16.19.0
Amplify CLI Version
v12.1.1
What operating system are you using?
Linux
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
No manual changes made
Describe the bug
After upgrading the version of the amplify-cli from v12.0.3 to v12.1.1, the command amplify api gql-compile cannot be executed due to a field-level authorization error.
Please see the attached file for details.

Upon investigation, the version of amplify-category-api has changed from 5.3.0 to 5.4.1.
Comparing changes between v12.0.3 and v12.1.1
packages/amplify-cli/package.json

We have confirmed that error messages are defined in the following file.
amplify-category-api/packages/amplify-graphql-auth-transformer/src
/graphql-auth-transformer.ts
Checking the Change Log, we could not find any update information regarding amplify-category-api.
Is this a bug with the upgrade of amplify-cli?
Would you please check and investigate the cause?
Expected behavior
Can execute the command amplify api gql-compile, as in v12.0.3.
Reproduction steps

Execute the command: amplify upgrade
Execute the command: amplify api gql-compile

Project Identifier
No response
Log output
No response
Additional information
No response
Before submitting, please confirm:

[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

Hi @tf-suzukito 👋, Thanks for raising this issue. We are working on reproducing the issue. Could you please run below command and send us the report amplify diagnose --send-report and share with us the project identifier?
please refer here

+1. Also running into this issue. It was introduced in 12.1.0. Reverting to 12.0.3 resolves it.
I just ran diagnose and my project identifier is 3def1a2bd59d61900f734d59f169a578

Hi @AnilMaktala san, thank you for quick response 🙏
I tried to do amplify diagnose --send-report but faced error.
$ amplify diagnose --send-report

Learn more at https://docs.amplify.aws/cli/reference/diagnose/

✅ Report saved: /tmp/.../report-1687307463391.zip

⠹ Sending zip
DiagnoseReportUploadError
✖ Sending zip

Should I downgrade to amplify version v12.0.3 and then run it?

Hi @tf-suzukito, Thank you for bringing this issue to our attention. By following the steps provided in the description, we were able to reproduce the issue successfully. As a result, we have flagged this as a bug for our team to investigate and assess further.
@hisham, Thank you for sharing the report.
schema:
type Employee
  @model
  @auth(rules: [{ allow: private, operations: [read] }, { allow: owner }]) {
  name: String
  email: String
  ssn: String! @auth(rules: [{ allow: owner }])
}

Execute the command: amplify upgrade
Execute the command: amplify api gql-compile

@tf-suzukito Hi the error is expected if you are adding the field level auth to a non-nullable field due to the subscription concern. We recently apply a more restricted rule due to that concern. Take the repro schema as example
type Employee
  @model
  @auth(rules: [{ allow: private, operations: [read] }, { allow: owner }]) {
  name: String
  email: String
  ssn: String! @auth(rules: [{ allow: owner }])
}

This will throw the same error because the private role does not have read access to the required field ssn. If the error is not thrown, it will result in a bad state where the private role will subscribe to the ssn of other owners.
So the field level auth for the non-nullable fields is more restricted than the nullable ones because of the subscription. There are two workaround which is either make that field nullable or turn off the subscription for the model. I would not recommend adding { allow: private, operations: [read] } to the ssn field since it should not be your intention and there is no need to apply field level auth in this case
Solution#1
type Employee
  @model
  @auth(rules: [{ allow: private, operations: [read] }, { allow: owner }]) {
  name: String
  email: String
  ssn: String @auth(rules: [{ allow: owner }]) # nullable field
}

Solution#2
type Employee
  @model(subscriptions:null)
  @auth(rules: [{ allow: private, operations: [read] }, { allow: owner }]) {
  name: String
  email: String
  ssn: String! @auth(rules: [{ allow: owner }])
}

Hi there - any update on this, ETA, or workaround? We have purposely not updated to 12.1.1 because of this issue, but I don't want to now fall behind on amplify cli updates (current version 12.4.0). If you're not able to fix in time, I'm going to have to find a workaround...

Hi there.
And thank you for reaction, @hisham san. 🙏
Same above opinion. Is there any progress on this issue?
I know there are other high priority issues, so I can't speak for myself, but the fact that it is treated as an ERROR instead of a WARNING makes it difficult to update it in any way.
I know that the AWS team is discussing this issue, and we would be very happy to hear from you if there are any progress.


[PyTorch Upstream] Inductor UT regression : TypeError: unsupported operand type(s) for |: 'dict' and 'dict'

After update triton commit id in stock pytorch from b8c64f64c18d8cac598b3adb355c21e7439c21de to b32c4d871602ff5b0b105cccaeaf3fc917de6abc, we got inductor test case  test/inductor/test_triton_kernels.py:KernelTests.test_triton_kernel_2d_autotune_grad_False_dynamic_False_backend_aot_eager_grid_type_1 failue when using python 3.8.
The error message:
2024-05-31T16:33:43.8626799Z This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0
2024-05-31T16:33:43.8627300Z =================================== FAILURES ===================================
2024-05-31T16:33:43.8627856Z _ KernelTests.test_triton_kernel_2d_autotune_grad_False_dynamic_False_backend_aot_eager_grid_type_1 _
2024-05-31T16:33:43.8628374Z Traceback (most recent call last):
2024-05-31T16:33:43.8628829Z   File "inductor/test_triton_kernels.py", line 716, in test_triton_kernel_2d_autotune
2024-05-31T16:33:43.8629303Z     torch_result = call_triton(t1, t2, output)
2024-05-31T16:33:43.8629728Z   File "inductor/test_triton_kernels.py", line 709, in call_triton
2024-05-31T16:33:43.8630233Z     add_kernel_2d_autotuned[grid](x, y, output, x_elements, y_elements)
2024-05-31T16:33:43.8630949Z   File "/opt/conda/envs/py_3.8/lib/python3.8/site-packages/triton/runtime/jit.py", line 345, in <lambda>
2024-05-31T16:33:43.8631639Z     return lambda *args, **kwargs: self.run(grid=grid, warmup=False, *args, **kwargs)
2024-05-31T16:33:43.8632415Z   File "/opt/conda/envs/py_3.8/lib/python3.8/site-packages/triton/runtime/autotuner.py", line 156, in run
2024-05-31T16:33:43.8633176Z     timings = {config: self._bench(*args, config=config, **kwargs) for config in pruned_configs}
2024-05-31T16:33:43.8633993Z   File "/opt/conda/envs/py_3.8/lib/python3.8/site-packages/triton/runtime/autotuner.py", line 156, in <dictcomp>
2024-05-31T16:33:43.8634735Z     timings = {config: self._bench(*args, config=config, **kwargs) for config in pruned_configs}
2024-05-31T16:33:43.8635510Z   File "/opt/conda/envs/py_3.8/lib/python3.8/site-packages/triton/runtime/autotuner.py", line 106, in _bench
2024-05-31T16:33:43.8636087Z     current = dict(meta, **config.all_kwargs())
2024-05-31T16:33:43.8636758Z   File "/opt/conda/envs/py_3.8/lib/python3.8/site-packages/triton/runtime/autotuner.py", line 242, in all_kwargs
2024-05-31T16:33:43.8637335Z     return self.kwargs | {
2024-05-31T16:33:43.8637751Z TypeError: unsupported operand type(s) for |: 'dict' and 'dict'

https://github.com/triton-lang/triton/pull/4049

https://github.com/triton-lang/triton/commit/03b84666a1991a0addd6b0d80c911de98b7e6c31 merged in llvm-target by https://github.com/intel/intel-xpu-backend-for-triton/pull/1239.

Hi @whitneywhtsang  , is this issue  resolved?

@etaf  this merge fixes issue. To reiterate our statement - this is not a blocker issue, PyTorch 2.4 drops Python 3.8 support.


Scroll back to top on menu clicks

Always go to the top of the page as navigating between menus.
Changes

Scroll back to top on menu changes.
Turn suspended checks into guard clauses.

Testing

gulp build
Open in mobile view.
Go to About Us, scroll down till Careers button is at the top of the screen.
Click Careers entries.
Should scroll to top and slide careers menu into view.

Review

@jimmynotjim
@KimberlyMunoz
@sebworks

Nice fix :+1:

👍


Not appearing in Overlay.dll

Hi everyone,
I tried looking for youtube videos first and googling but cant seem to find people with this issue. I installed Cactbot using act and it is in my Plugin Listing tab and active so thats no issue. My problem is in the Overlayplugin.dll tab when I press New and go to the dropdown menu I dont see any Cactbot options. I even tried to copy/paste the cactbotoverlay.dll into the addons folder in the Overlay folderlike I saw online and then change the plugin in the Plugin Listings tab just to see and still not 1 Cactbot option.
Can anyone help me and tell me where I went wrong if I went wrong?
Thanks :)

The options no longer show up as Cactbot overlay types directly. Instead, you need to select Miniparse as the type of overlay. Then, in the URL field, put the file location for the raidboss.html file that you would normally use. From there, the configuration should work as you expect.

You should not put cactbot in the addons folder any more.
Do these steps work for you?

The options no longer show up as Cactbot overlay types directly. Instead, you need to select Miniparse as the type of overlay. Then, in the URL field, put the file location for the raidboss.html file that you would normally use. From there, the configuration should work as you expect.

I tried that and it worked thanks but I dont see how to change any option that way.

You should not put cactbot in the addons folder any more.

Do these steps work for you?
I tried the start of it originally and it doesnt work. It installs fine and is in my Plugin Listings without any problems but in the OvwerlayPlugin.dll tab it has this error at the bottom and the options dont appear in the dropdown when I pick new.
[07/07/2020 19:48:16] Info: InitPlugin: PluginDirectory = C:\Users%%%\AppData\Roaming\Advanced Combat Tracker\Plugins\OverlayPlugin
[07/07/2020 19:48:16] Info: InitPlugin: Initialized.
[07/07/2020 19:48:18] Error: LoadAddons: CactbotOverlay.dll: System.InvalidCastException: Unable to cast object of type 'Cactbot.PluginLoader' to type 'RainbowMage.OverlayPlugin.IOverlayAddonV2'.
at RainbowMage.OverlayPlugin.PluginMain.LoadAddons()
[07/07/2020 19:54:57] Error: Got a subscription for missing event "onUserFileChanged"!
[07/07/2020 19:54:57] Error: Got a subscription for missing event "onForceReload"!
[07/07/2020 19:54:57] Error: JS Handler call failed: System.Exception: Tried to call missing handler "cactbotLoadData"!
at RainbowMage.OverlayPlugin.EventDispatcher.CallHandler(JObject e)
at RainbowMage.OverlayPlugin.EventDispatcher.ProcessHandlerMessage(IEventReceiver receiver, String data)
[07/07/2020 19:54:57] Error: JS Handler call failed: System.Exception: Tried to call missing handler "cactbotLoadUser"!
at RainbowMage.OverlayPlugin.EventDispatcher.CallHandler(JObject e)
at RainbowMage.OverlayPlugin.EventDispatcher.ProcessHandlerMessage(IEventReceiver receiver, String data)
[07/07/2020 19:54:57] Info: Cactbot Raidboss: BrowserConsole: Uncaught (in promise) TypeError: Cannot read property 'detail' of null (Source: file:///C:/Users/%%%/AppData/Roaming/Advanced%20Combat%20Tracker/Plugins/cactbot-0.18.0/cactbot/resources/user_config.js, Line: 35)
I dont know why its having this issue but would be great if you can help me fix it.
Thanks :)

Glad you got it sorted.  I think the issue was likely that you had cactbot listed before overlayplugin.


Getting 500 issue

Fatal error: Uncaught Screen\Exceptions\PhantomJsException: sh: /home/www/html/developementsec.com/browsershotnew/plugin/bin/phantomjs: Permission denied in /home/www/html/developementsec.com/browsershotnew/plugin/src/Capture.php:301 Stack trace: #0 /home/www/html/developementsec.com/browsershotnew/plugin/demo/shot.php(43): Screen\Capture->save('test') #1 {main} thrown in /home/www/html/developementsec.com/browsershotnew/plugin/src/Capture.php on line 301

Same issue on centos, how can resolve it?

Found out, Just add
$screen->setOptions([
'ignore-ssl-errors' => 'yes',
]);
and it works like a charm.
Good luck

In my case i have to set phantomjs path directly (linux):
$screen->binPath = '/usr/local/bin/';


feat(diagnostics): Use showerror to stringify error messages

This will, for example, give the following messages:
ErrorException
ErrorException: something is wrong
BoundsError: attempt to access 3-element Vector{Int64} at index [4]

instead of:
ErrorException("")
ErrorException("something is wrong")
BoundsError([1, 2, 3], (4,))

Thanks! Can you update the tests as well? The issue is simply that they expect the old way of showing the errors.

Done. I also extracted the stringification into a utility function so that it coudl be used also in the explicit smuggle(error) method.

Thank you very much for your contribution. :)


Decoupling allocation from writing in HTTP/2 outbound flow control

Motivation:
The current DefaultHttp2RemoteFlowController's writePendingBytes currently operates in 2 passes. The first allocates bytes and optionally writes some frames. The second pass just loops across all active streams and writes all remaining bytes.
If streams can be removed/added as a side effect of writing (EOS or error) then we need to take more care when the write actually occurs. Moving all of the writes to the second loop (across active streams) is simpler since we can just make a copy of the list and not worry about any restructuring of the priority tree that may result.
Modifications:
Modified DefaultHttp2RemoteFlowController.writePendingBytes to only allocate bytes on the first pass and then write any allocated bytes on the second pass.
Result:
Side effects resulting from writing should no longer impact the flow control algorithm.

@Scottmitch with the coming changes related to stream removal, I suspect this is going to be important.  Can you take a look?

@nmittler - I'm getting a compile error:

/Users/scott_mitchell/git/netty/codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2RemoteFlowController.java:325: two or more consecutive empty lines

Also allocated() it not used anymore.

Weird, I wasn't getting that build error. Anyway, I removed the line ... PTAL.

@nmittler - Great work!  Just a few nits.  Feel free to cherry-pick once resolved.

Thanks for the quick review! Cherry-picked into master and 4.1.


[W6.2][T12-B1]Adil Azmoon

Changed the theme to a lighter grey, adjusted font size and changed font family

@adileyzekmoon You can close this PR. Remember to have the correct PR title next time.


Create LICENSE

I made it for reading directories recursively on web based on HTMLInputElement.webkitdirectory API's.

add


Debugging / help

Hi thorrak,
Happy new year, and thanks for all your work on this project.
I'm having a couple of issues getting my fermentrack working again after being away from the homebrew scene for awhile.
I have an older setup based on fuzzewuzze's original build, and I have flashed the legacy 0.2.10 RevA onto the Arduino, with a success message.
I am having two, probably related issues.

Fermentrack does not seem to initiate the cooling relay, and just sits at Idling, even though the beer or fridge constant is set much lower.

After awhile, it seems to crash, and returns an error that it is running a very old version of BrewPi. Please upload a new version of BrewPi to your Arduino. I can't restart with the Restart Controller button under the device manager at this point, and need to restart it manually by powering the arduino off.

Sorry, this was a bit longer than intended. Can you give any advice on debugging this?
Side note 1, This is running through a virtual box with linux mint, instead of raspberry pi, but I have previously not had an issue with this build.
Side note 2, I am planning on upgrading to a new esp8266 build, but I am really hoping to get this going so I can get a brew or two in before I get the upgraded version going.

Here is the full error text from dev-3-stderr.log:
Jan 03 2022 02:42:24   Refreshing dbConfig
Jan 03 2022 02:42:24   Connection type Serial selected. Opening serial port.
Jan 03 2022 02:42:24   Connected via serial to port /dev/ttyACM0
Jan 03 2022 02:42:24   Notification: Script started, with no active beer being logged
Jan 03 2022 02:42:34   Checking software version on controller...
Jan 03 2022 02:42:44   Warning: Cannot receive version number from controller. Your controller is either not programmed or running a very old version of BrewPi. Please upload a new version of BrewPi to your controller.

Additionally, the dashpanel is now displaying:
Cannot receive LCD text from Controller/Script

I have an older setup based on fuzzewuzze's original build, and I have flashed the legacy 0.2.10 RevA onto the Arduino, with a success message.
I am having two, probably related issues.

Fermentrack does not seem to initiate the cooling relay, and just sits at Idling, even though the beer or fridge constant is set much lower.

Do you have a screen on the actual BrewPi hardware? If so, does it match what you see in Fermentrack (or - separately - are you actively seeing the timer tick up in Fermentrack)?
Both the "LCD" display in Fermentrack and the control of the state of the relay are handled by the actual hardware - not Fermentrack - which would indicate a potential issue with either the hardware, hardware setup, or firmware. That said, let's try to debug --
On the device confguration/pin setup page, what do you see? (The page in Fermentrack with a bunch of icons)

After awhile, it seems to crash, and returns an error that it is running a very old version of BrewPi. Please upload a new version of BrewPi to your Arduino. I can't restart with the Restart Controller button under the device manager at this point, and need to restart it manually by powering the arduino off.

Sorry, this was a bit longer than intended. Can you give any advice on debugging this? Side note 1, This is running through a virtual box with linux mint, instead of raspberry pi, but I have previously not had an issue with this build. Side note 2, I am planning on upgrading to a new esp8266 build, but I am really hoping to get this going so I can get a brew or two in before I get the upgraded version going.

There could be a couple of sources of this issue. Again - do you have a screen on the BrewPi? If so, what does the screen show while disconnected from Fermentrack?

Do you have a screen on the actual BrewPi hardware?  If so, does it match what you see in Fermentrack (or - separately - are you actively seeing the timer tick up in Fermentrack)?
No, there is not a screen. the "Idling for 00m00" does increase/tick up.

On the device confguration/pin setup page, what do you see? (The page in Fermentrack with a bunch of icons)
With the error above, I get an error "Unable to reach brewpi-script. Try restarting the brewpi-script." With a restart, I get this:

Try setting a heating pin, and see if that solves problem 1. I can't remember if - for the Arduino firmware - having it set is required (even if you don't hook up a heater).
Without a screen, we're slightly limited in how we can debug issue 2, but that's OK. What happens if you physically unplug & reconnect the Arduino. Does it start working again?

Thanks for the help so far!

Try setting a heating pin, and see if that solves problem 1. I can't remember if - for the Arduino firmware - having it set is required (even if you don't hook up a heater).

I gave this a try just now, and reset the temps for the beer constant and fridge constant, but it still appears to be stuck on idling.
I have had trouble with this relay. The heating stopped working on it (which is why I had stopped using it and did not have it assigned).

Without a screen, we're slightly limited in how we can debug issue 2, but that's OK. What happens if you physically unplug & reconnect the Arduino. Does it start working again?

Yes it does start working again.

Ok, following on your suspicion it was hardware related, I'm pretty sure I must have messed up on the wiring to the relay on the arduino.
I plugged in a spare uno. Everything started up, got sensors assigned and the relay was triggering correctly.
I then rewired the relay to try to get the heating relay to work. I used this diagram:
https://dotps1.github.io/img/2018-01-22-brewing-your-own-brewpi/schematic.jpg
This caused the 2nd arduino to die! :(
I have found the brewpi remix, which I will rework the parts with instead. Obviously a wiring issue on my part, then hardware.  I now have two uno bricks.

Ok, following on your suspicion it was hardware related, I'm pretty sure I must have messed up on the wiring to the relay on the arduino.
I plugged in a spare uno. Everything started up, got sensors assigned and the relay was triggering correctly.
I then rewired the relay to try to get the heating relay to work. I used this diagram: https://dotps1.github.io/img/2018-01-22-brewing-your-own-brewpi/schematic.jpg This caused the 2nd arduino to die! :(

What do you mean by "die"? Continue to sit at idling forever? I believe that's a firmware bug, but unfortunately don't have any hardware here to test with to be able to tell you for certain. (That said - see my note below about BrewPi Remix)
Looking at that wiring diagram, unless there is something wrong with the relay, nothing should end up frying the Arduino. The only reason I could see the relay causing issues is if the JD-VCC jumper was bridging the wrong two pins.

I have found the brewpi remix, which I will rework the parts with instead. Obviously a wiring issue on my part, then hardware.  I now have two uno bricks.

BrewPi-Remix is @lbussy 's project, and consists of two main components -- replacement arduino firmware, and a replacement web interface. The replacement firmware is not only compatible with Fermentrack, but - I believe - pin compatible with Fuzzewuzze's firmware port. That is: You may be able to just flash the firmware and have it start working.
This firmware is available through the firmware flash interface of Fermentrack as "BrewPi Remix" - You can use either the "RevC" or "I2C" variants and likely be fine (though RevC is most similar to what Fuzzewuzze published). Definitely worth a try if you think the hardware isn't functioning as expected!

I just want to be extra careful to point out a significant item:  You said Rev A above, and we are talking about RevC.  Rev A was used for the older shield I believe and the pinouts are different.  If you are not using a shield anyway, I recommend using the I2C variant.  It is mostly compatible with Rev C with the exception that it uses A0 for the OneWire.  The advantage to this variant is you can easily plug in an LCD with four wires compared to needing a pretty complicated shield with RevC.
Here is a post in the support thread for the wiring diagram:
https://www.homebrewtalk.com/threads/brewpi-remix-–-what’s-old-is-new-again.687633/page-9#post-9217104

Hello, apologies for the delay here, and thanks to the both of you for your help.
The JD-VCC jumper looks fine.
I am able to reflash both of my arduinos, so I guess not dead after all. Honestly I think I needed a break to get fresh eyes on the problem! Sorry to give such scattered info! 🤣 🐙
Following @lbussy's note, I flashed to Rev C, it was incorrectly on Rev A. The idle issues are gone now, and it is triggering cooling periodically. I am going to reflash to the I2C variant, and I've ordered a couple of the 2004 I2C LCD from aliexpress, but it will take a month or so to get to New Zealand.
It does still periodically appear to crash. I did some testing over the course of the day today. Hopefully it will give a few insights.
It was set to around 55f, and was keeping solid on that temp for a number of hours. A few hours later rechecked and saw the "Cannot receive LCD text from Controller/Script" error. I unplugged the USB and plugged it back in, and the restarted. The temp at this point was around 65f.

There are logs.  Use the ❓ icon and you can view the logs there. I expect it would be called something obvious, but I don't have a device attached right now to check.  If the controller crashes, you should be able to see something.

Progress!
I was able to find the logs under /home/fermentrack/fermentrack/log
Here is the crash from today:
 Jan 06 2022 20:28:34   Controller debug message: INFO MESSAGE 18: Negative peak detected:  54.8, estimated:  55.0. Previous cool estimator:  4.680, New cool estimator:  4.680.
  Exiting.
 Jan 06 2022 21:13:28   Refreshing dbConfig
 Jan 06 2022 21:13:28   Connection type Serial selected. Opening serial port.
 Jan 06 2022 21:13:28   Connected via serial to port /dev/ttyACM0
 Jan 06 2022 21:13:28   Notification: Script started, with no active beer being logged
 Jan 06 2022 21:13:38   Checking software version on controller...
 Jan 06 2022 21:13:48   Warning: Cannot receive version number from controller. Your controller is either not programmed or running a very old version of BrewPi. Please upload a new version of BrewPi to your controller.
 Jan 06 2022 21:14:23   Refreshing dbConfig
 Jan 06 2022 21:14:23   Connection type Serial selected. Opening serial port.
 Jan 06 2022 21:14:23   Connected via serial to port /dev/ttyACM0
 Jan 06 2022 21:14:23   Notification: Script started, with no active beer being logged
 Jan 06 2022 21:14:33   Checking software version on controller...
 Jan 06 2022 21:14:43   Warning: Cannot receive version number from controller. Your controller is either not programmed or running a very old version of BrewPi. Please upload a new version of BrewPi to your controller.
 Jan 06 2022 21:15:18   Refreshing dbConfig
 Jan 06 2022 21:15:18   Connection type Serial selected. Opening serial port.
 Jan 06 2022 21:15:18   Connected via serial to port /dev/ttyACM0
 Jan 06 2022 21:15:18   Notification: Script started, with no active beer being logged
 Jan 06 2022 21:15:28   Checking software version on controller...
 Jan 06 2022 21:15:38   Warning: Cannot receive version number from controller. Your controller is either not programmed or running a very old version of BrewPi. Please upload a new version of BrewPi to your controller.
 Jan 06 2022 21:16:13   Refreshing dbConfig
 Jan 06 2022 21:16:13   Connection type Serial selected. Opening serial port.
 Jan 06 2022 21:16:13   Connected via serial to port /dev/ttyACM0
 Jan 06 2022 21:16:13   Notification: Script started, with no active beer being logged
 Jan 06 2022 21:16:23   Checking software version on controller...
 Jan 06 2022 21:16:33   Warning: Cannot receive version number from controller. Your controller is either not programmed or running a very old version of BrewPi. Please upload a new version of BrewPi to your controller.
 Jan 06 2022 21:17:08   Refreshing dbConfig
--- etc ---

It looks like the reconnection doesn't work - I'd guess because the original thread doesn't stop. @thorrak does that seem likely?

Just a mini update here. I have installed a new version of Raspbian, Fermentrack and reflashed the arduino with BrewPi Remix - 0.2.13 - - RevC. I'm hoping that whatever issues were going on are now resolved. I will let it run for a day or two controlling the temp and see if it is stable, and report back. At least I am getting a slightly better understanding of how the software works!
Thanks to you both for your time/help. 🥂

Well it only got half an hour in last night and received the same error again. :(
Is it possible for USB cables or USB ports to be an issue here?
Should the brewpi continue to regulate the temperature even if Fermentrack can't access it?
Any other logs I can check?
Jan 09 2022 09:00:18   Notification: Started logging for beer 'Test beer'.
 Jan 09 2022 09:01:37   Refreshing dbConfig
 Jan 09 2022 09:01:37   Notification: Beer temperature set to 58.0 degrees in web interface
 Jan 09 2022 09:01:38   Controller debug message: INFO MESSAGE 12: Received new setting: mode = b
 Jan 09 2022 09:01:38   Controller debug message: INFO MESSAGE 12: Received new setting: beerSet = 58.0
 Jan 09 2022 09:35:48   Serial Error: Write timeout)
 Jan 09 2022 09:35:53   Serial Error: Write timeout)
 Jan 09 2022 09:36:04   Error: controller is not responding to new data requests. Exiting.
 Jan 09 2022 09:36:06   Refreshing dbConfig
 Jan 09 2022 09:36:06   Connection type Serial selected. Opening serial port.
 Jan 09 2022 09:36:06   Connected via serial to port /dev/ttyACM0
 Jan 09 2022 09:36:06   Notification: Script started for beer 'Test beer'
 Jan 09 2022 09:36:16   Checking software version on controller...
 Jan 09 2022 09:36:26   Warning: Cannot receive version number from controller. Your controller is either not programmed or running a very old version of BrewPi. Please upload a new version of BrewPi to your controller.

I was able to get it running smoothly, finally.
Here are the steps that worked.

Replaced relay module and Arduino.
Click the 'Update/Install Missing Python Packages'
Removed all devices from Fermentrack, and readded

No issues since. 👍

Well, it was a nuclear option but I'm glad it worked.


Explore integration options with Sentry; tracking and monitoring

https://sentry.io/welcome/
As an addon, it would be great to able to register deployments automatically with the sentry server, hosted by Apereo perhaps or CAS directly. Helps us put together a "who uses CAS" sort of page, and improves community relationship and growth. We'd want the integration to be on by default, but of course configurable easily to turn off.
Have discussed this option with @jtgasper3 in the past; perhaps we could deploy the server-component via docker somewhere and let CAS talk to it.
More modestly, a simple http header that can be tracked via shodan.io [or other easier means] may be in order here.

See:

https://hub.docker.com/_/sentry/
https://store.docker.com/images/788f45b7-2701-4244-90e4-3f85aef116d8?tab=description

Changes should be available in 5.1 RC2


Closes #29 - Add support for Laravel 8

With this PR we're dropping supports for lower versions of Laravel

A new inspection was created.

The inspection completed: No new issues


Add an aws_request_id field for AWS lambdas.

Add an aws_request_id field for AWS lambdas. This is necessary to match logs up more easily in OpenSearch and CloudWatch Logs.

This can be done inside the code using this library. Closing.


JSON substitution doesn't replace variables starting with the word 'system'

We've decided to add some configuration settings as part of the appsettings.json file and replace them as part of our release pipeline.
I noticed that whenever the word 'system' is at the beginning of any variable (object or not), the substitution does not happen. None of our variables were using only the word 'system', like the system.debug variable, to access nested values. They were something like 'SystemUsersApiUri' or some variation of that.
If this is not classified as a bug, could you please add the JSON substitutions' restrictions to the docs? I have collected logs and I'm happy to share them.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 315ff823-9992-9f9b-62a1-42ce622ed41c
Version Independent ID: 72ec3ffc-1dc9-b2dc-e3d4-4f14deae3720
Content: File transforms and variable substitution - Azure Pipelines
Content Source: docs/pipelines/tasks/transforms-variable-substitution.md
Product: devops
GitHub Login: @alexhomer1
Microsoft Alias: ahomer

Thank you for your feedback. There is no published limitation as you describe, and so this issue should be filed as a product bug. Bugs, issues, suggestions, and feature requests related to the product rather than the documentation are best posted on the Developer Community website at https://developercommunity.visualstudio.com/spaces/21/index.html, where they are tracked by the product teams. Please post your feedback there. Thank you.


feat(convertDateStringsToDates): friendly feature

I know this should not be in app.js.
I tried to do it like your authInterceptor.
// app.js
$httpProvider.defaults.transformResponse.push('dateInterceptor');

// dateInterceptor.js
angular.factory('dateInterceptor', convertDateStringsToDates)

But it's just not working
Do you have a better way to do this? @michaelkrone

I guess we should use moment.js here, angular-moment is already in use and installed, so we can inject and use it for all date/time related things.
Instead of parsing by regexp ourself, moment provides some nice methods to handle stuff like that.

BTW, we should use code style according to the .jshintrc as stated in john papas guidelines, so use tabstops ans single quotes (from .jshintrc):
 "indent": "\t",
 "quotmark": "single"

We might change indent to spaces, as you converted all sources to spaces.

I will adjust and merge this tonight

I've done the refactor. You can merge after review.

I can't test the ut because of #89


scripts(ticdc): limit file width

What problem does this PR solve?
Issue Number: close #4780
Check List
Tests

Unit test

Release note
None

Can we use lll?

lll checks whole file, it may be annoying when we only change one line but it ask us to reformat the whole file.
I'd like to make the reformat processing as smooth as possible by checking added lines only.

Codecov Report

Merging #4781 (2bb6760) into master (9607554) will decrease coverage by 0.1059%.
The diff coverage is 51.8176%.

Flag
Coverage Δ

cdc
59.7084% <51.8176%> (-0.2139%)
:arrow_down:

dm
52.0770% <ø> (+0.0481%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.
@@               Coverage Diff                @@
##             master      #4781        +/-   ##
================================================
- Coverage   55.6402%   55.5343%   -0.1060%
================================================
  Files           494        521        +27
  Lines         61283      64344      +3061
================================================
+ Hits          34098      35733      +1635
- Misses        23750      25092      +1342
- Partials       3435       3519        +84

/merge


When running setup.bat file I get "Error: cannot open Hazel/vendor/msdf-atlas-gen: no such file or directory"

When running setup.bat file I get "Error: cannot open Hazel/vendor/msdf-atlas-gen: no such file or directory". But when I go to the specified path the folder msdf-atlas-gen does exist.
Steps to reproduce the behavior:

Go to './scripts'
Click on 'setup.bat'

Expected behavior
setup to be able find msdf-atlas-gen as the folder does exist in the specified path and finish setup successfully
Result behavior
setup cannot open msdf-atlas-gen and says it does not exist even though it does

In .gitmodules file. You should try change

path = Hazel\vendor\msdf-atlas-gen

to

path = Hazel/vendor/msdf-atlas-gen


[Visualizer] ability to highlight dependencies

Is your feature request related to a problem? Please describe.
With a very complex and large deployments it's a bit hard to track all the dependencies. Visualiser does help but with tens of resources it can get difficult to find dependency paths
Describe the solution you'd like
I'd like a way to highlight the dependency chain (in both ways, selectable) from a selected resource/module all the way to the root and/or leaf.
Also, ability to highlight root resources (that does not depends on any) would be beneficial.

@shenglol FYI in case you are interested, but not urgent


Pushing animated and then switching tab in one NavigationCommandSequence not working correctly

This seems to be a UIKit problem. When pushing several viewcontrollers, and then switching tabs, only the first viewcontroller was pushed to the navigationcontroller. This issue very probably also happens in a project not using Wireframes. Probably UIKit "optimizes" non-active child viewcontrollers which results in this issue. The use case should not be necessary too much in practice, so it won't pay off to find a workaround for this.

This can cause an assertionFailure in the NavigationControllerWireframe, as the Navigation Controller does not correctly update it's viewControllers array. Maybe we should remove the PushSwitchPushCommandChain which exhibits this behavior.

Confirmed in a test project that this really is a UIKit bug.


Not working if there is nested Serializer

It is working fine if it Serializer with the normal fields but if Serializer has nested serializer as its field then errors property throwing datatype exception

@dhope-nagesh - Mine too is not working. Were you able to work it out?

@tomaszkoperski - Any update on this?

Hi, I try to fix this issue on #13


fix(compare_map_segmentation): update voxel_based for dynamic map loader with map grid coordinate

Description
Since Map_loader server has provided map grid coordinates, this PR uses new map_loader I/F for efficiently search map grid which input point cloud belong to and avoid the degradation of compare result for point on the map grid boundary.
Related links
https://github.com/autowarefoundation/autoware.universe/issues/3085
https://github.com/autowarefoundation/autoware.universe/pull/3087
TIERIV COMPANY INTERNAL LINK
Tests performed

Run autoware with split map pointcloud with pointcloud_map_metadata.yaml file.

Confirm the processing time and voxel_based_compare_map_filter's output as the same as whole map pointcloud loading version.

-
Whole map loading
Dynamic map loading

Pointcloud number

Processing time

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

The modification https://github.com/autowarefoundation/autoware.universe/pull/3277/commits/aa857b0ebfde2356e2967e679291f4c90cc50a3e to support latest map_loader IF with metadata added at https://github.com/autowarefoundation/autoware.universe/pull/3286


Disabling local feature importance view for large data scenario

Description
The table view is not in scope for large data effort. Hence disabling the local importance tab for large data scenario.

Checklist

[x] I have added screenshots above for all UI changes.
[ ] I have added e2e tests for all UI changes.
[ ] Documentation was updated if it was needed.

Codecov Report

Merging #1828 (ac18368) into main (b733264) will increase coverage by 4.50%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1828      +/-   ##
==========================================
+ Coverage   82.82%   87.33%   +4.50%
==========================================
  Files          55       39      -16
  Lines        2935     1792    -1143
==========================================
- Hits         2431     1565     -866
+ Misses        504      227     -277

Flag
Coverage Δ

unittests
87.33% <ø> (+4.50%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

raiwidgets/raiwidgets/explanation_constants.py

raiwidgets/raiwidgets/error_handling.py

raiwidgets/raiwidgets/responsibleai_dashboard.py

raiwidgets/raiwidgets/error_analysis_dashboard.py

raiwidgets/raiwidgets/cohort.py

raiwidgets/raiwidgets/interfaces.py

...iwidgets/raiwidgets/explanation_dashboard_input.py

...dgets/raiwidgets/error_analysis_dashboard_input.py

raiwidgets/raiwidgets/fairness_dashboard.py

raiwidgets/raiwidgets/model_analysis_dashboard.py

... and 6 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


typo: "transister"

The icon "electronics-transister" should probably be renamed to "electronics-transistor"
Thank you for your work. I love the icons!

Fixed in 2b858a7

Thank you @marc-spieler ! 🙌


utmpx api for linux musl + musl few build fixes.

close #3190

Why is this trying to change O_LARGEFILE?

I just looked at an alpine instance, O_LARGEFILE on x86_64 arch is the same as android so 0o100000

When can this PR be merged? Is it blocked waiting for a future release?

@joshtriplett did I answer your question ?
@JohnTitor would you mind reviewing it ?
thanks.

@JohnTitor can this be merged? What does the tag "breakage-candidate" mean?

Turned out that the Cargo feature way I mentioned above isn't pragmatic, and we have to make libc 0.3 real. See https://github.com/rust-lang/libc/pull/3488#issuecomment-1862579094 for more details.

:pushpin: Commit e3caaf6b0ea08ae294e25a861022c256a7535ec4 has been approved by JohnTitor
It is now in the queue for this repository.

:sunny: Test successful - checks-actions, checks-cirrus-freebsd-13, checks-cirrus-freebsd-14
Approved by: JohnTitor
Pushing 28ef7fe52d3bbf0a210df8ec3b2202626b98fd7b to main...


Update Gitpod live demo setup steps to README

Update Gitpod live demo and screenshots to minimize user confusion because Gitpod changed their branding.
Fixes #350
I changed paths in ReadMe to my branch to see the result and you can review
Before merging: we should update media file paths to  theia-ide/theia-trace-extension and change the branch If-gitpodDemo to matser (https://raw.githubusercontent.com/theia-ide/theia-trace-extension/master/doc/images/gitpod-live-demo-setup.gif)
Here is the result

Signed-off-by: Ibrahim Fradj<EMAIL_ADDRESS>

@IbrahimFradj Can you switch the paths to what they should be when merged so that it's ready to go?

@ebugden  i changed the paths to what they should be when merged

@MatthewKhouzam When this is merged will the old files automatically be overwritten? The new images have identical file names to the old ones.

@ebugden @MatthewKhouzam @IbrahimFradj new versions of screenshots with the same file name used to be not updated on github pages. They are somehow cached on GitHub.. I did some research on the web and many people where complaining about that. Unfortunately I can't find any link at the moment for that.
To avoid this issue, all the images that I've uploaded in doc/images directory have a number as suffix. When there is a new version I upload a new file with a new number, delete the old one and reference the new file in the readme.
I don't know if this is still an issue, but my approach for sure works.

@ebugden  i changed the paths and the name of the media file. we can see the result in readme on the branch.

@ebugden with great pleasure. i changed the path of files to trace extension master


Sketch not running ArrayIndexOutofBound error

Hi,
I am trying to make your sketch run. But when compiled i get following errors

Could not run the sketch (Target VM failed to initialize)
ArrayIndexOutofBound at line : 205
button[p] = new Radio(35, 95+(yPos*20),12,color(180),color(80),color(255),p,button);

can you please help in understanding what is going wrong.
I just downloaded and compiled rightaway.
EM

@Electromania I just made an update to the sketch.
Please download or pull the new code and try it. It should work.

i tried again, no success. attached is the screenshot of screen i see with error. it just freezes the program - i have to End Task to stop it.

The problem is happening when the sketch tries to create a list of serial ports and associated radio buttons to allow you to select the port. The issue may be happening because you don't have many ports on your PC. When you run Arduino and select the Arduino board to program, how many ports do you see in the dropdown menu?
The sketch is adding a radio button in order to place the "Refresh Serial Ports List" selection. Actually, the sketch already refreshes the serial ports automatically, so you don't really need that line.
Try commenting out lines 203 to 206 and see if it works.

thanks, i made it work. apparently it needs some port to be ready to be opened. i was running it without connecting any arduino.
now at least the program is running : ). i will see how to get the heart beating ; ).
thanks a lot

Oh, yes. You do need to actually have a serial port.
I will post an issue about that and we will see about fixing this edge case.
Happy Heartbeats!