Received unknown value for type, please report this: 5

Bug
Description
I sent a trade offer (via Steam web) asking for this CS:GO crate, which is in the inventory of one of my bots, and ASF was unable to accept the trade and told me to report it here.
Expected behavior
Trade to be accepted.
Actual behavior
Trade is rejected, the following error message is shown:
2018-05-07 06:56:52|dotnet-27995|ERROR|bot1|GetConfirmations() Received unknown value for type, please report this: 5

Steps to reproduce
I'm not sure. That CS:GO crate is owned by one of my bots, and the only thing I did was send a trade offer asking for it (and giving no items), expecting the trade to be instantly accepted since I'm the operator of said bot.
Full log.txt recorded during reproducing the problem
2018-05-07 06:52:26|dotnet-27995|INFO|ASF|InitASF() ASF V<IP_ADDRESS> (2a7d2e4b-041e-4317-9132-1ed9f73528f5)
2018-05-07 06:52:26|dotnet-27995|INFO|ASF|Start() Starting IPC server on http://*:1242/...
2018-05-07 06:52:26|dotnet-27995|INFO|ASF|Start() IPC server ready!
2018-05-07 06:52:27|dotnet-27995|INFO|bot1|Start() Starting...
2018-05-07 06:56:37|dotnet-27995|INFO|bot1|Connect() Connecting...
2018-05-07 06:56:40|dotnet-27995|INFO|bot1|OnConnected() Connected to Steam!
2018-05-07 06:56:40|dotnet-27995|INFO|bot1|OnConnected() Logging in...
2018-05-07 06:56:41|dotnet-27995|INFO|bot1|OnLoggedOn() Successfully logged on!
2018-05-07 06:56:41|dotnet-27995|INFO|bot1|Init() Logging in to ISteamUserAuth...
2018-05-07 06:56:42|dotnet-27995|INFO|bot1|IsAnythingToFarm() Checking first badge page...
2018-05-07 06:56:43|dotnet-27995|INFO|bot1|Init() Success!
2018-05-07 06:56:45|dotnet-27995|INFO|bot1|StartFarming() We don't have anything to idle on this account!
2018-05-07 06:56:46|dotnet-27995|INFO|bot1|ParseTrade() Accepting trade:<PHONE_NUMBER>
2018-05-07 06:56:52|dotnet-27995|ERROR|bot1|GetConfirmations() Received unknown value for type, please report this: 5
2018-05-07 08:16:48|dotnet-27995|INFO|bot1|ParseTrade() Accepting trade:<PHONE_NUMBER>
2018-05-07 08:16:48|dotnet-27995|INFO|bot1|ParseTrade() Accepting trade:<PHONE_NUMBER>
2018-05-07 08:16:55|dotnet-27995|ERROR|bot1|GetConfirmations() Received unknown value for type, please report this: 5

Global ASF.json config
{
  "AutoRestart": false,
  "BackgroundGCPeriod": 0,
  "Blacklist": [],
  "CommandPrefix": "!",
  "ConfirmationsLimiterDelay": 10,
  "ConnectionTimeout": 60,
  "CurrentCulture": "en-US",
  "Debug": false,
  "FarmingDelay": 15,
  "GiftsLimiterDelay": 1,
  "Headless": false,
  "IdleFarmingPeriod": 8,
  "InventoryLimiterDelay": 3,
  "IPC": true,
  "IPCPassword": <hidden>,
  "IPCPrefixes": [ "http://*:1242/" ],
  "LoginLimiterDelay": 10,
  "MaxFarmingTime": 10,
  "MaxTradeHoldDuration": 15,
  "OptimizationMode": 0,
  "Statistics": true,
  "SteamOwnerID": <hidden>,
  "SteamProtocols": 2,
  "UpdateChannel": 0,
  "UpdatePeriod": 0,
  "WebLimiterDelay": 200
}

BotName.json config of all affected bot instances (if more than one)
{
  "AcceptGifts": false,
  "AutoSteamSaleEvent": false,
  "CustomGamePlayedWhileFarming": null,
  "CustomGamePlayedWhileIdle": null,
  "DismissInventoryNotifications": false,
  "Enabled": true,
  "FarmingOrder": 0,
  "FarmOffline": true,
  "GamesPlayedWhileIdle": [],
  "HandleOfflineMessages": false,
  "HoursUntilCardDrops": 3,
  "IdlePriorityQueueOnly": false,
  "IdleRefundableGames": true,
  "IsBotAccount": false,
  "LootableTypes": [1, 3, 5, 6],
  "PasswordFormat": 0,
  "Paused": false,
  "RedeemingPreferences": 0,
  "SendOnFarmingFinished": true,
  "SendTradePeriod": 0,
  "ShutdownOnFarmingFinished": false,
  "SteamLogin": <hidden>,
  "SteamMasterClanID": 0,
  "SteamParentalPIN": "0",
  "SteamPassword": null,
  "SteamTradeToken": <hidden>,
  "SteamUserPermissions": {<hidden>: 3},
  "TradingPreferences": 1,
  "UseLoginKeys": true
}

Can't reproduce with the same config and ASF v<IP_ADDRESS>

Trade is rejected

Trade is not rejected, trade can't be accepted:
2018-05-07 06:56:46|dotnet-27995|INFO|bot1|ParseTrade() Accepting trade:<PHONE_NUMBER>
2018-05-07 06:56:52|dotnet-27995|ERROR|bot1|GetConfirmations() Received unknown value for type, please report this: 5

And this means that Valve added new confirmation type that ASF is unaware of, and it can't possibly know what it should do in this case.

Can't reproduce with the same config and ASF v<IP_ADDRESS>

Nothing changed in terms of ASF 2FA between those two, it's a matter of reproduction, not a matter of fixes, but good that you already tried to help me.

Steps to reproduce
I'm not sure.

Me neither but I can speculate it has something to do with recent hold upon CS:GO items. In any case, here is what you can do:
Download latest ASF pre-release version (currently V<IP_ADDRESS>) and enable Debug mode. Reproduce your issue, simply make ASF state that value to report, and close ASF. Open log.txt generated by ASF and find the end of the log where ASF stated unknown value to report. Above that log line there will be unique link generated by ASF, starting with GET https://steamcommunity.com/mobileconf/conf?l=english&p= (this will happen only in debug mode). Copy-paste full URL and go under that link in your browser that is logged in as affected bot (it won't work without established session). Also be swift, since it's 2FA link that expires in around 5-15 minutes since being generated, so you can't hold that for later.
If you succeeded, you'll see a web page exactly the same as the one you'd see on your 2FA phone, with confirm/reject buttons and all details. Don't click anything there, right click on the page and save source as - name your file however you want, e.g. 2fa.html, this will be the most important reproduction bit.
Now create a zip file out of full log.txt that you recorded and used, and your 2fa.html file that you saved, and send that zip file on my e-mail: JustArchi[at]JustArchi[dot]net. Remember to NOT put it in any public location, such as this GitHub issue, because both files might contain sensitive information, as stated on the wiki of Debug description.
That will help me a lot since it's everything I need to check what the issue is, and what ASF should possibly do in this case. It might be a trivial fix or extra logic, depending on what Valve came up with.
Thank you in advance.

Thanks for your help 👍


Plugin cannot be installed within obsidian

The plugin is listed in the obsidian plugin library, but attempting to open the plugin about page / summary results in the error message Failed to load plugin manifest.

(I would like to test this plugin out to see if it works for me, so if an alternative instruction guide for manual installation can be provided I'd appreciate it; not worries if not though!)

@LillieoftheMoon it's likely a problem with the new version. Thanks for the report

@LillieoftheMoon thank you for your help, I've fixed the problem

No problem! Double checked on my end, issue is fixed as stated.
Thank you!!


add process_abort function

I did not have the total overview of how to handle the "details dict" along with an abort ( is it always string -> string mapping ?? ).
So with those changes here, I took the very conservative road - only adding the URI to the exception raised.

I am merging this, but yeah, I guess adding m_session_join.set_exception() at respective places is still needed.

The follow up issue is https://github.com/crossbario/autobahn-cpp/issues/90


BCC Emails don't send

PHP Version
7.4
Shopware Version
6.4
Expected behaviour
BCC emails are being sent out
Actual behaviour
BCC emails are not being sent out
How to reproduce
Add a BCC recipient to the email object before it gets sent.

We just use the Symfony Mailer library. Please create a issue there https://github.com/symfony/symfony


Feature request: Support for month format MMM

Hi,, it will be nice if you can support also another date formats,,, e.g. month MMM,,
like https://momentjs.com/docs/#/displaying/

I'd add that support for month-of-year selection (returning a date defaulting to the first of month in the year) would be good as well.

Yeah it would be great to have support for momentjs' date formats


How to diagnose an issue? Unix receiver idles on "Starting ... "

I'm excited to try and use scream to send audio from a Windows 10 laptop to a Linux server (and then over 3.5mm aux into an audio receiver).
I believe I've gotten scream installed on the Windows laptop correctly. (see #98 )
I also believe that I've correctly compiled the unix receiver on my Linux server (Proxmox).
$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

Using speaker-test, I've confirmed that I have audio correctly working.
I can:

launch YouTube on the Windows machine and set the output device to Scream
run the scream receiver with various flags

The scream receiver doesn't seem to be receiving any audio. I'm not sure how to further diagnose the issue.
My Linux server is a laptop networked via ethernet on eno1.
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP mode DEFAULT group default qlen 1000
    link/ether 10:1f:74:69:a2:88 brd ff:ff:ff:ff:ff:ff
3: enx64d4da6b44df: <NOARP> mtu 1400 qdisc noop state DOWN mode DEFAULT group default qlen 20
    link/ether 64:d4:da:6b:44:df brd ff:ff:ff:ff:ff:ff
4: wlo1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 40:25:c2:b4:8a:b8 brd ff:ff:ff:ff:ff:ff
5: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 10:1f:74:69:a2:88 brd ff:ff:ff:ff:ff:ff
6: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 52:7c:1b:aa:cc:22 brd ff:ff:ff:ff:ff:ff

Running with -o alsa (pulseaudio is the same):
scream/Receivers/unix/build$ ./scream -i eno1 -v -o alsa
Using ALSA output
Starting multicast receiver

What should I try next?

Edit: I should add that even though I am using Proxmox, I am running the scream receiver on the host, not in a VM.

Do a tcpdump like tcpdump -pni eno1 port 4010 to see if you get any packets while playing sound. If you don't get any, try unicast (see the README.md on the github frontpage).

I was just about to comment with some tcpdump output! You beat me to it. Thanks for the quick response @duncanthrax .
$ sudo tcpdump -pni eno1 port 4010 -c5
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:41:10.195685 IP <IP_ADDRESS>.4010 > <IP_ADDRESS>.4010: UDP, length 1157
16:41:10.196422 IP <IP_ADDRESS>.4010 > <IP_ADDRESS>.4010: UDP, length 1157
16:41:10.205085 IP <IP_ADDRESS>.4010 > <IP_ADDRESS>.4010: UDP, length 1157
16:41:10.214919 IP <IP_ADDRESS>.4010 > <IP_ADDRESS>.4010: UDP, length 1157
16:41:10.215588 IP <IP_ADDRESS>.4010 > <IP_ADDRESS>.4010: UDP, length 1157
5 packets captured
5 packets received by filter
0 packets dropped by kernel

I'm definitely receiving the packets.
Based on the readme...I guess I should use the -P libpcap flag?
$ sudo apt-get install libpcap0.8 libpcap0.8-dev libpcap-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libpcap-dev is already the newest version (1.8.1-6).
libpcap0.8 is already the newest version (1.8.1-6).
libpcap0.8-dev is already the newest version (1.8.1-6).
0 upgraded, 0 newly installed, 0 to remove and 21 not upgraded.

So I would assume I should compile with libpcap available:
$ cmake ..
-- Checking for module 'libpcap'
--   No package 'libpcap' found
-- Configuring done
-- Generating done
-- Build files have been written to: /home...<blah blah blah>.../build

Hmmm, the cmake recipe uses pkg-config to find libpcap. Probably you have this problem:
https://bugs.launchpad.net/ubuntu/+source/libpcap/+bug/1865501

@afparsons do you have a firewall enabled?
I don't use Debian but I think you can see it with sudo systemctl status firewall.service
If that fail try sudo systemctl status firewalld.service or sudo ufw status.

I'm having a similar issue, except I'm attempting to pass audio up through a Windows VM. Similar setup, except using libvirt networking. It's exhibiting the same symptoms as here - packets are clearly received on the host, either through unicast or multicast, but running an strace shows that they aren't reaching the receiver (no activity).
In my case, I have UFW installed, but the same problem was exhibited even after ports 4010 and 4011 were allowed through, or if UFW was disabled entirely. Not sure how to continue diagnosing from here. As a side note, I haven't been able to get IVSHMEM working either, but that's unrelated to this issue.

@kaisparkle What's your distro? For example on Ubuntu I've seen both UFW and firewalld at the same time and even if one was allowing the port the other one wasn't. I banged my head around it for a few days.
Try sudo systemctl status firewalld.service and see if it's installed / enabled.
If that's not it look at iptables rules and see what's in there.
UFW is a strange beast. On one hand it's easy to use but its not aware of any rule managed by others. I discovered this the hard way when I configured UFW to deny anything from outside, then installed docker and found out I could happily connect from the outside because docker was managing it's own iptables rules.

@martinellimarco I'm on Arch, so I've only got UFW installed at the moment. I'm pretty unfamiliar with iptables, but I've posted the output of iptables -S here. https://pastebin.com/0jxpe0Bq

Just for testing run the following commands. They'll flush any iptables rule and set it to accept everything. It's temporary and not saved on disk but it will show us if the problem is firewall or not.
sudo iptables -t nat -F
sudo iptables -t mangle -F
sudo iptables -F
sudo iptables -X
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT

sudo iptables -S

If it doesn't work what kind of virtual interface are you using between host and guest? Also try this

No dice there, so it's not the firewall. I already had the suggestions in that post enabled - first thing I tried when I was digging through issues for a solution :)
I'm using virt-manager's default configuration, which is the virbr0 bridge, with forward mode="nat".

Have you tested this with anycast or unicast? Try unicast.
Also since your are using a bridge I think it's worth checking sudo ebtables -L which is the ethernet bridge firewall.

Yeah, tried with default and I'm using unicast right now with these arguments: scream -u -p 4011 -i virbr0 -o pulse
ebtables -L output:
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT```

can you confirm with any other program that a connection is possible between host and guest? Usually I use netcat for that.
nc -l -p 4010 -u on linux
nc.exe IP_OF_THE_LINUX_BOX 4010 -u on windows
Type something, you should see it on the other end.
If you don't have netcat try with python -m SimpleHTTPServer on linux and on windows open a browser and visit http://IP_OF_THE_LINUX_BOX

I can send a message with netcat from the Windows 10 guest to the host, but I have to restart netcat on both ends after a message, otherwise it won't be received. Additionally, I can only send to the host, not the other way around.

ok, at least we confirmed it's a network problem and not a scream one. In about an hour I'll be at home and I'll be able to setup a new VM with the same virtual NIC you posted above. Let's see if I can reproduce the issue.

Sorry @kaisparkle, I can't reproduce the problem.
I've tested with a fresh windows VM with windows firewall disabled but that shouldn't be the problem as you already confirmed you see the packets on the host. For the network I just copied your xml. I've tested with and without UFW enabled. With it enabled I just had to open the port with ufw allow 4010/udp. Tested both multicast and unicast.
I'd really like to see the wireshark log if you have the time.

I'm not entirely sure how to run Wireshark on the host - I'm using a single GPU configuration, so X is killed on VM start and the GPU is passed over. I can probably reconfigure it with a virtual GPU for testing, but I've got work today (unfortunately :stuck_out_tongue:) so it might be a while.

You can use tcpdump from a terminal.
The command should be tcpdump -s 0 -i virbr0 -w log.pcap

Hello, I am currently trying to pass audio from my windows vm running under a Ubuntu 20.04 host.
I seem to have the exact same issue as OP, when I run the above commands used to troubleshoot I get the exact same output.
@martinellimarco if you or anyone else here wants to figure out this issue I'll be the test subject.
P.s I am new to commenting on issues so apologies if I shouldn't comment in a year old issue as I do not know proper etiquette.


System.Data.SqlClient.ManualTesting.Tests.TvpTest.TestMain fails on Ubuntu due to different regional date format

System.Data.SqlClient.ManualTesting.Tests.TvpTest.TestMain fails on Ubuntu due to different regional date format.
Most of the failures are due to mismatch in the Year format between the expected and the actual value as seen below, opening this issue to keep track.
 ** DIFF at line 341
  A : Failed Row[0]Col[5] = 1/1/53 12:00:00 AM: Invalid value for this metadata.
  E : Failed Row[0]Col[5] = 1/1/1753 12:00:00 AM: Invalid value for this metadata.
  ** DIFF at line 342
  A : Failed Row[1]Col[5] = 1/1/53 12:00:00 AM: Invalid value for this metadata.
  E : Failed Row[1]Col[5] = 1/1/1753 12:00:00 AM: Invalid value for this metadata.
  ** DIFF at line 343
  A : Failed Row[4]Col[5] = 1/1/53 12:00:00 AM: Invalid value for this metadata.
  E : Failed Row[4]Col[5] = 1/1/1753 12:00:00 AM: Invalid value for this metadata.
  ** DIFF at line 344

However, there are a couple of more failures apart from mismatch year format which need to be investigated.
 ** DIFF at line 640
  A : Value       => Expected : Actual == 0 :<PHONE_NUMBER>00000000
  E : Value       => Expected : Actual == 0 : 0
  ** DIFF at line 641
  A : Test SqlDataReader TVP [Data Type][EXPECTED ERROR]: VALUE MISMATCH - [Actual = 1/1/01 12:00:00 AM] [Expected = 1/1/01 12:00:00 AM]
  E :
  ** DIFF at line 642
  A :
  E : ------------------------------ TestSqlDataReader_TVP_Variant [type: date value:1/1/0001 00:00:00] ------------------------------
  ** DIFF at line 643
  A : ------------------------------ TestSqlDataReader_TVP_Variant [type: date value:1/1/01 00:00:00] ------------------------------
  E : Type        => Expected : Actual == System.DateTime : System.DateTime
  ** DIFF at line 644
  A : Type        => Expected : Actual == System.DateTime : System.DateTime
  E : Base Type   => Expected : Actual == date : date
  ** DIFF at line 645
  A : Base Type   => Expected : Actual == date : date
  E : Value       => Expected : Actual == 0 : 0
  ** DIFF at line 646
  A : Value       => Expected : Actual == 0 :<PHONE_NUMBER>00000000
  E :
  ** DIFF at line 647
  A : Test SqlDataReader TVP [Variant Type][EXPECTED ERROR]: VALUE MISMATCH - [Actual = 1/1/01 12:00:00 AM] [Expected = 1/1/01 12:00:00 AM]
  E : ------------------------------ TestSimpleDataReader_Type [type: date value:1/1/0001 00:00:00] ------------------------------
  ** DIFF at line 648
  A :
  E : Type        => Expected : Actual == System.DateTime : System.DateTime
  ** DIFF at line 649
  A : ------------------------------ TestSimpleDataReader_Type [type: date value:1/1/01 00:00:00] ------------------------------
  E : Base Type   => Expected : Actual ==  :
  ** DIFF at line 650
  A : Type        => Expected : Actual == System.DateTime : System.DateTime
  E : Value       => Expected : Actual == 0 : 0
  ** DIFF at line 651
  A : Base Type   => Expected : Actual ==  :
  E :
  ** DIFF at line 652
  A : Value       => Expected : Actual == 0 :<PHONE_NUMBER>00000000
  E : ------------------------------ TestSimpleDataReader_Variant [type: date value:1/1/0001 00:00:00] ------------------------------
  ** DIFF at line 653
  A : Test Simple Data Reader [Data Type][EXPECTED ERROR]: VALUE MISMATCH - [Actual = 1/1/01 12:00:00 AM] [Expected = 1/1/01 12:00:00 AM]
  E : Type        => Expected : Actual == System.DateTime : System.DateTime
  ** DIFF at line 654
  A :
  E : Base Type   => Expected : Actual == date : date
  ** DIFF at line 655
  A : ------------------------------ TestSimpleDataReader_Variant [type: date value:1/1/01 00:00:00] ------------------------------
  E : Value       => Expected : Actual == 0 : 0
  ** DIFF at line 656
  A : Type        => Expected : Actual == System.DateTime : System.DateTime
  E :
  ** DIFF at line 657
  A : Base Type   => Expected : Actual == date : date
  E : ------------------------------ SqlBulkCopySqlDataReader_Type [type: date value:1/1/0001 00:00:00] ------------------------------
  ** DIFF at line 658
  A : Value       => Expected : Actual == 0 :<PHONE_NUMBER>00000000
  E : Type        => Expected : Actual == System.DateTime : System.DateTime
  ** DIFF at line 659
  A : Test Simple Data Reader [Variant Type][EXPECTED ERROR]: VALUE MISMATCH - [Actual = 1/1/01 12:00:00 AM] [Expected = 1/1/01 12:00:00 AM]
  E : Base Type   => Expected : Actual ==  :
  ** DIFF at line 660
  A :
  E : Value       => Expected : Actual == 0 : 0
  ** DIFF at line 661
  A : ------------------------------ SqlBulkCopySqlDataReader_Type [type: date value:1/1/01 00:00:00] ------------------------------
  E :
  ** DIFF at line 662
  A : Type        => Expected : Actual == System.DateTime : System.DateTime
  E : ------------------------------ SqlBulkCopySqlDataReader_Variant [type: date value:1/1/0001 00:00:00] ------------------------------

Complete Log:
TvpTest.TestMain.log
Expected Result:
Expected_SqlParameterTest_ReleaseMode.log
Actual Result:
Actual_SqlParameterTest_Ubuntu.log

@David-Engel good idea. Done. Let me know if you want help moving other issues. I think now you only need write permissions on both repos to be able to transfer.


Linuxbrew Support

Hi - would a PR be accepted to add Linuxbrew support?
Thanks!

We weren't going to add linuxbrew ourselves, but were aware of it when we made the homebrew support, and left some logical room for it one day. If you're willing to do the work to implement it, we'd be very happy to accept it!
Did you have any requirements/plans for what you want to work?
I believe the main concern for us is that if a user opts into homebrew support, we probably shouldn't default to also doing linuxbrew, because that may surprise them and their linux users. One of the ways we had planned that was that when specifying a [dependencies.homebrew], without specifying target = ..., we would only ever apply them to macos targets, and you could "opt in" to linuxbrew targets by manually enumerating the platforms you care about (this would also specifically let you say "linuxbrew only, not macos homebrew").

I'd love to learn more about your usecase here! I'm curious about the circumstances in which you'd prefer Linuxbrew over apt (or any other Linux package manager).
I'd be happy to review a PR, and to work with you to scope the work or provide any guidance you nee din the PR process.

Homebrew packages are almost always more recent than even Ubuntu (which I use). Using Linuxbrew and Homebrew allows for a nearly combined manifest of packages:
https://github.com/dsully/dotfiles/blob/main/home/dot_config/Brewfile.tmpl
For my own tools that I release to my tap, I'd like to do the same:
https://github.com/dsully/homebrew-tap
@Gankra I'm curious how adding a Linuxbrew target would surprise a user? If they aren't using Linuxbrew, and they don't specify a package, it would be no-op. Unless I'm missing something?
I'd think the logical behavior would be to automatically add Linux artifacts to the tap if they exist - and also be multi-architecture aware, specifically x86_64 and arm64 / aarch64

If they aren't using Linuxbrew, and they don't specify a package, it would be no-op. Unless I'm missing something?

Linuxbrew is preinstalled on the GitHub Ubuntu runners, so builds running there automatically have it. I do think many users who intend to use apt packages would be surprised to see Linuxbrew packages installed too!

For my own tools that I release to my tap, I'd like to do the same:

I see, so it sounds like you're most interested in the publishing story rather than using Linuxbrew to install packages before the build?

Linuxbrew is preinstalled on the GitHub Ubuntu runners, so builds running there automatically have it. I do think many users who intend to use apt packages would be surprised to see Linuxbrew packages installed too!

I wasn't aware of that. It would still require someone to call brew install <package> instead of apt-get install <package> though?

I see, so it sounds like you're most interested in the publishing story rather than using Linuxbrew to install packages before the build?

Yes! Sorry if I didn't make that clear. 100% on what is generated for the Formula .rb file.

I wasn't aware of that. It would still require someone to call brew install  instead of apt-get install  though?

I think where we're talking at cross-purposes here is that we just (in 0.4.0) shipped a feature that lets users install dependencies from a package manager as a part of the build process. I've been so focused on that I assumed that's what your question was about. 😅 That aspect of Linuxbrew support, which is what @Gankra and I were talking about, has a few more complex questions to work through... but adding binaries to the Homebrew .rb formula file is a lot more straightforward.


OpenTracing shim doesn't change context

OpenTelemetry: v0.17.0
Node: v15.5.0
I'm not sure if I'm doing something wrong/
We have the following situation:
The application initializes OTel using node-sdk and OpenTracing shim in standard way like in examples. It also adds http instrumentation.
The application passes OpenTracing shim to the underlying libraries (actually app plugins) which create spans using opentracing API.
One of the libraries performs HTTP request and creates span for this.
OpenTelemetry HTTP instrumentation span actually belongs to the root span instead of span create by the library.
So trace has the following structure:
- HTTP root span (created by instrumentation, also active context is set here)
`--- Application span (created using OT API, creates new context and passes it below using childOf)
      `--- Library span with HTTP request (create using OT API, uses context from childOf)
`--- HTTP outgoing span (created by instrumentation, uses global active span which is root span)

But I expected to see the following:
- HTTP root span (created by instrumentation)
`--- Application span (created using OT API)
      `--- Library span with HTTP request (create using OT API)
            `--- HTTP outgoing span (created by instrumentation)

Usually user code creates new context for every level of nesting using api.context.with but this is impossible inside libraries which using OpenTracing API. This actually means that OpenTracing Shim is incompatible with instrumentations / plugins
I think it's impossible to fix but at least this should be mentioned in the docs

Hmm shouldn't those libraries be using tracer.withSpan though? I feel like we should be able to shim that to work properly

Do you mean withSpan from OpenTracing? I don't know about such method. And I wasn't able to find any information about it. We can change that libraries but they can use only opentracing API.
Although I believe it should be mentioned in the docs that OpenTracing shim doesn't support active context changing and instrumentations that use it

appears i was misremembering. We should be able to respect the childOf option in the shim though

Obviously there is a context loss somewhere but a look over the code doesn't show anything obvious to me. Can you provide a minimal reproduction?

If I understand this correct OpenTracing will never set a span on context but OpenTelemetry picks up parents only from context. Looks obvious that OpenTelemetry instrumentations will never use a span from OpenTracing as parent.

Yeah, I'll do an example later (on weekends I hope). But for now the context is lost because the only way to set is to call api.context.with. OpenTracing shim just passes existing context down using the third parameter of startSpan and doesn't change global active context which is stored in AsyncLocalStorage. May be if there was another way to change active context it would be possible to shim that. But I think AsyncLocalStorage API won't allow that

If I understand this correct OpenTracing will never set a span on context but OpenTelemetry picks up parents only from context. Looks obvious that OpenTelemetry instrumentations will never use a span from OpenTracing as parent.

opentracing API passes parents around explicitly. they don't need to pick anything up from context because they're provided directly to startSpan so we should be able to match them up

Yeah, I'll do an example later (on weekends I hope). But for now the context is lost because the only way to set is to call api.context.with. OpenTracing shim just passes existing context down using the third parameter of startSpan and doesn't change global active context which is stored in AsyncLocalStorage. May be if there was another way to change active context it would be possible to shim that. But I think AsyncLocalStorage API won't allow that

Oh I see where the disconnect is. I'm not an expert in AsyncLocalStorage but at least our context manager doesn't have an API for this. We could add it if it does turn out to be possible

opentracing API passes parents around explicitly. they don't need to pick anything up from context because they're provided directly to startSpan so we should be able to match them up

That works as long as you stay in the OpenTracing world. But if there is an (autoinstrumented) OpenTelemetry instrumenation somewhere on the way noone will pass the OpenTracing span to it - instead it wil pick up that one from active context.
I agree with @morigs that this is not really fixable because the concept of automatic context propagation doesn't exist in OpenTracing. A user could fix the gap only by calling some OpenTelemetry API - so by leaving the OpenTracing world.
I think it should work to use a span created by OTraceShim in api.context.with(ShimSpan, () => {}).
But if you can modify the code where OpenTracing is used it's also possible to use OTel directly at all places.

But I think AsyncLocalStorage API won't allow that

We should avoid to use any APIs from a concrete context manager to ensure this stays portable to e.g. browser and older nodejs versions.

@Flarna

But if you can modify the code where OpenTracing is used it's also possible to use OTel directly at all places.

This a big But 😄
This is impossible in our case. So I think we won't use any instrumentations for now. This is sad situation of course

In case somebody is interested in diving in here's the minimal reproduction. It requires Jaeger at localhost:6832

Code Spoiler
'use strict';

const { HttpTraceContext, ParentBasedSampler, AlwaysOnSampler } = require('@opentelemetry/core');
const opentelemetry = require("@opentelemetry/sdk-node");
const { HttpInstrumentation } = require('@opentelemetry/instrumentation-http');
const { JaegerExporter } = require('@opentelemetry/exporter-jaeger');
const { TracerShim } = require('@opentelemetry/shim-opentracing');
const opentracing = require('opentracing');

const jaegerExporter = new JaegerExporter({ serviceName: 'http_server_opentracing', flushInterval: 100 });
const httpInstrumentation = new HttpInstrumentation();
opentelemetry.api.diag.setLogger(new opentelemetry.api.DiagConsoleLogger(), 80);
const sdk = new opentelemetry.NodeSDK({
  traceExporter: jaegerExporter,
  textMapPropagator: new HttpTraceContext(),
  instrumentations: [httpInstrumentation],
  autoDetectResources: true,
  sampler: new ParentBasedSampler({ root: new AlwaysOnSampler() }),
});
sdk.start().then(() => startServer(process.env.PORT || 4000));

const tracer = new TracerShim(opentelemetry.api.trace.getTracer('opentracing-shim'));

const http = require('http');
const superagent = require('superagent');

function startServer(port) {
  const server = http.createServer(handleRequest);

  server.listen(port, (err) => {
    if (err) throw err;

    console.log(`Server is listening on ${port}`);
  });
}

async function handleRequest(req, res) {
  const parentSpan = tracer.extract(
    opentracing.FORMAT_HTTP_HEADERS,
    req.headers,
  );

  const span = tracer.startSpan('handle_request', {
    childOf: parentSpan,
  });

  await doSomething(span);

  res.writeHead(200, { 'Content-Type': 'application/json' });
  res.write(
    JSON.stringify({ status: 'OK', traceId: span.context().toTraceId() }),
  );

  res.end();
  span.finish();
}

async function doSomething(parentSpan) {
  const span = tracer.startSpan('do_something', { childOf: parentSpan });
  const res = await doRequest(span);
  span.log({ res: res.body });
  span.finish();
}

async function doRequest(parentSpan) {
  const span = tracer.startSpan('do_request', { childOf: parentSpan });
  const res = await superagent('https://httpbin.org/json');
  span.finish();
  return res;
}

When running this code I'm getting the following result

As you can see HTTPS GET is located under HTTP GET, not under do_request

if this is related to context propagation for outgoing request then it is the same error I have described here https://github.com/open-telemetry/opentelemetry-js/issues/1535 which describes error when clients send request to server and server responds back to client, then you have also 2 separate traces

@obecny not enough information to be sure, but I have experienced very similar behavior with this issue. Thus I think it's related


When confirming recipient's account in Send flow, app should auto-focus to subsequent textbox when entering characters.

Expected Behavior
When a phone number is mapped to multiple accounts the sender must confirm the last four characters of the recipient's account. After typing a character into a textbox, app should autofocus to the next textbox.

[ ] Also, should replace the word "digits" with "characters".

Current Behavior
Sender must tap each of the 4 textboxes when inputting characters.

duplicate of #4116


Add tier status to event logger

Part-of #2466
@bobheadxi I need some help here getting this to work with the telemetry recorder too. How can I add default properties like the ones mentioned in #2466? 🤔 It looks like I can only overwrite the TelemetrySource and not add arbitrary default fields?
Test plan
Added some console.log debugging to help make sure this work
diff --git a/lib/shared/src/telemetry/EventLogger.ts b/lib/shared/src/telemetry/EventLogger.ts
index 82ad6e603..668699cc2 100644
--- a/lib/shared/src/telemetry/EventLogger.ts
+++ b/lib/shared/src/telemetry/EventLogger.ts
@@ -128,6 +128,9 @@ export class EventLogger {
             version: this.extensionDetails.version, // for backcompat
             hasV2Event,
         }
+        console.log('###############')
+        console.log(getTier(this.getAuthStatus()))
+        console.log('###############')
         this.gqlAPIClient
             .logEvent(
                 {
(END)

Works with V2 too now, thanks @bobheadxi


Flake: TestReaderReadFileHTTPSProxySuccess

Logs
2023/05/03 21:02:51 http: TLS handshake error from <IP_ADDRESS>:60668: tls: first record does not look like a TLS handshake
2023/05/03 21:02:51 http: response.WriteHeader on hijacked connection from github.com/aws/eks-anywhere/pkg/files_test.pipe (reader_test.go:257)
2023/05/03 21:02:51 http: response.Write on hijacked connection from fmt.Fprintln (print.go:305)
--- FAIL: TestReaderReadFileHTTPSProxySuccess (0.01s)
    reader_test.go:140:
        Expected
            <*errors.errorString | 0xc0004803d0>: {
                s: "failed reading file from url [[https://example.com:443/testdata/file.yaml](https://example.com/testdata/file.yaml)]: Get \"[https://example.com:443/testdata/file.yaml\](https://example.com/testdata/file.yaml/)": EOF",
            }
        to be nil
FAIL
	github.com/aws/eks-anywhere/pkg/files	coverage: 92.6% of statements
FAIL	github.com/aws/eks-anywhere/pkg/files	0.055s

Occurences

https://github.com/aws/eks-anywhere/actions/runs/4876450182/jobs/8699956129?pr=5773

https://prow.eks.amazonaws.com/view/s3/prowpresubmitsdataclusterstack-prowbucket7c73355c-vfwwxd2eb4gp/pr-logs/pull/aws_eks-anywhere/5888/eks-anywhere-presubmit/1659339691830284288

https://github.com/aws/eks-anywhere/actions/runs/5489835919/jobs/10004494938?pr=5786

This has happened twice more for me today.


Distance of single edge restricted

As the distance for every edge can be roughly max 1000km we have two OSM way where this is exceeded (ferries!) and we need to deal with this:

http://www.openstreetmap.org/way/233682992
http://www.openstreetmap.org/way/141294301

The problem is that we currently return Double.Infinity if Integer.max is reached but math operations with infinity can lead to NaN which makes nearly every operation with them invalid. So should we just return a big double instead of infinity or increase distance precision - think about how to handle this!

Since there are so rare, may be break them in osm?

Also, there is possible to split them on reading process

Yeah, good idea to split the edges in the import process.

hah, I am so lazy.

Hmmh, such ferries should be normally tagged as route relationes i.e. the way should be splitted in OSM itself I think.

Removing the bug label, as this is more an OSM issue. Still we need to think about if we should return a very large distance instead of infinity.

I included a workaround for this (no way splitting for now) as the work to do this splitting properly is not worth the effort (at least not at the current time). But at the same time it is critical to throw an exception in setDistance if the distance is too large.

The problem is now that for CH preparation we set the distance which can easily grow over int max when processing world wide data.
As a workaround we should just return max int. In the future we have to decide if we remove the distance data from the CH graph (then certain applications would slow down) or how we fix this properly.

I think we should reduce the distance from currently mm to 0.1m.


Home: Replace OWL Carousel with alternative

The current OWL Carousel is dead and no longer actively maintained. Also, it does not show any post content, just the image and the title:

The carousel should be replaced by an alternative, e.g. https://glidejs.com/. Research should be done on alternatives before proceeding with any coding.

Fixed in https://github.com/AdvisorySG/dawn-advisory-theme/commit/dbc152e78ef4c78ebb611ad2fb338ca883f0bfec.


WFLY-13810 Workaround for ISPN-12273

https://issues.redhat.com/browse/WFLY-13810
Fixes intermittent failures in org.jboss.as.test.clustering.cluster.web.ExternalizerTestCase

Adding hold label until we have a sufficient number of successful CI test runs.


Add toFixed to prices calculator

Description

The prices in calculator sometimes looks too long, needs to be rounded.

Changes

Use toFixed to prices.

Related Issues
https://github.com/threefoldtech/tfgrid-sdk-ts/issues/1187#issuecomment-1868527054

Before

After

Checklist

[ ] Tests included
[ ] Build pass
[ ] Documentation
[ ] Code format and docstrings
[ ] Screenshots/Video attached (needed for UI changes)

I think 3 or 4 decimal places are enough, 6 is a little bit too much, what do you think?

I think 3 or 4 decimal places are enough, 6 is a little bit too much, what do you think?

Updated to 4


Make the mod info header readable

Unless I am misunderstanding something, there is no "modpack" here. This strange format makes it difficult for launchers to understand what is going on, thereby treating it as an arbitrary junk file.

Meanwhile, the other GTNH mods

This looks like a bug in MMC/Prism then as this format isn't exactly new. This behaviour isn't exclusive to CMM either, many other GTNH mods use the modListVersion 2 format.

You don't need to change the format you can just remove the non curly brackets from the top and bottom as those shouldn't be there when using modListVersion 2 format.

Still, it is rather strange to make this kind of format universal, given that this is something that is expected to be used on an as-needed basis.
If a mod isn't a pack, there is no need for the format. If a mod becomes a pack, then the metadata can be changed to reflect that.
I should mention that Project Red is also a pack, and the metadata is read correctly. Out of all of the GTNH mods I have, this is the only one exhibiting such behaviour. So there is something specific about the metadata here that is not playing nicely with launchers.

There's really no reason to change the format.. if you revert to the old format and just remove the top and bottom bracket it will be read correctly by whatever launcher you're using.

Please restore placeholders like ${modId}

Sorry about that. I clumsily copied it from a static source, and forgot the variables.


Y034 does seem to not check iter

The following code passes but the documentation of Y034 suggests that it should error:
class A:
    def __iter__(self) -> list: ...

This doesn't fall within the intended scope of Y034. If __iter__ returns an unrelated type, that's fine; Y034 is intended to catch cases where you should use Self.

oh, I didn't read the Y034 description carefully :) Thought it was a mixed bag for magic method to return Self/Iterator/...


push symbol could not be found

Describe the bug
This piece of code cannot compile:
contract;

use string::String;

abi MyContract {
    fn return_dynamic_string(l: u8) -> String;
}

impl MyContract for Contract {
    fn return_dynamic_string(l: u8) -> String {
        let mut string = String::new();
        let mut i = 0;
        while i < l {
            string::push(i);
            i = i+1;
        }
        string
    }
}

Running forc build yields this error:
13 |         while i < l {
14 |             string::push(i);
   |                     ^^^^ Could not find symbol "push" in this scope.
15 |             i = i+1;
16 |         }
   |

I'm not sure what I'm doing wrong.
Steps to reproduce

Use forc v0.40.1
Create fresh project
Add
string = { git = "https://github.com/FuelLabs/sway-libs" } as dependency
Write code above in src/main.sw
Profit?

Minimal reproducible code example
contract;

use string::String;

abi MyContract {
    fn return_dynamic_string(l: u8) -> String;
}

impl MyContract for Contract {
    fn return_dynamic_string(l: u8) -> String {
        let mut string = String::new();
        let mut i = 0;
        while i < l {
            string::push(i);
            i = i+1;
        }
        string
    }
}

Rust Version
1.70.0
Forc Version
0.40.1
Expected behavior
I expect the push symbol can be found without adding other imports.
Additional context
No response

This will work:
contract;
use string::String;
abi MyContract {
fn return_dynamic_string(l: u8) -> String;
}
impl MyContract for Contract {
    fn return_dynamic_string(l: u8) -> String {
        let mut string = String::new();
        let mut i = 0;
        while i < l {
            string.push(i);
            i = i+1;
        }
        string
    }
}

push() is an implementation on self while new() returns Self.

Please note that the String type in Sway-Libs will be removed in favor of https://github.com/FuelLabs/sway/pull/4716 in the std-lib

Whoopsie haha, sorry  I got confused reading the readme, closing the issue.


Buggy behavior on add cluster

theres still a bit of buggy behavior around the connection piece. When i add a bogus cluster, it shows up as connection failed after adding. then on refresh.. there is not icon state on the left in the data list b/c i think the controller is updating the status.
Also, I can add duplicate clusters with the same name. Also, sometimes when i add a new cluster, it just doesnt show up in any list until i refresh.

Also not seeing errors being reflected in webui, see below, entered 'sourceB' for the 'name' of the cluster, and didn't see an error in webui.
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "Cluster.clusterregistry.k8s.io "sourceB" is invalid: metadata.name: Invalid value: "sourceB": a DNS-1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is 'a-z0-9?(\.a-z0-9?)')",
"reason": "Invalid",
"details": {
"name": "sourceB",
"group": "clusterregistry.k8s.io",
"kind": "Cluster",
"causes": [
{
"reason": "FieldValueInvalid",
"message": "Invalid value: "sourceB": a DNS-1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is 'a-z0-9?(\.a-z0-9?)')",
"field": "metadata.name"
}
]
},
"code": 422
}
Request payload
{apiVersion: "clusterregistry.k8s.io/v1alpha1", kind: "Cluster",…}
apiVersion: "clusterregistry.k8s.io/v1alpha1"
kind: "Cluster"
metadata: {name: "sourceB", namespace: "mig"}
name: "sourceB"
namespace: "mig"
spec: {kubernetesApiEndpoints: {,…}}
kubernetesApiEndpoints: {,…}
serverEndpoints: [{clientCIDR: "<IP_ADDRESS>", serverAddress: "https://api.jwm05162019a.migration.redhat.com:6443"}]
0: {clientCIDR: "<IP_ADDRESS>", serverAddress: "https://api.jwm05162019a.migration.redhat.com:6443"}
clientCIDR: "<IP_ADDRESS>"
serverAddress: "https://api.jwm05162019a.migration.redhat.com:6443"

When adding a cluster, secret not found issue


Master

pull request

Current coverage is 76.17%

Merging #3357 into master will increase coverage by +1.79% as of e3ec580

@@            master   #3357   diff @@
======================================
  Files            5       5
  Stmts         3002    2489   -513
  Branches         0       0
  Methods
======================================
- Hit           2233    1896   -337
  Partial          0       0
+ Missed         769     593   -176

Review entire Coverage Diff as of e3ec580

Powered by Codecov. Updated on successful CI builds.


Error getting nodes from mirror for file 0.0.102 during attempt 0

Description
We’re seeing a “Error getting nodes from mirror for file 0.0.102 during attempt 0. Waiting 250 ms before next attempt: Stream refused by server” from the js SDK in previewnet HashIO.
Steps to reproduce

Additional context
No response
Hedera network
previewnet
Version
v2.18
Operating system
No response

I am able to reproduce this issue which is connected to an error in getting the address book. It is reproduced in HashIO because the SDK is a dependency library, but the problem is not in HashIO. We are further investigating why sometimes the call for Addressbook query does not succeed.

Hello @SimiHunjan and @Nana-EC,
I've played a little bit with the preview net GRPC mirror node for getting the nodes. Below are my considerations:

I've started a client through the SDK and I've performed 1000 AccountBalanceQuery transactions, as each transaction is executed every second (1 second). For this client, we are doing every 10 seconds AddressBookQuery request in order to update the book with the nodes from the mirror node (this is a configuration into the SDK). Randomly some of those requests are failing with the error that you have already seen. I've done some research and what I come across is the following statement:
The server may refuse to serve new requests if it is already handling too many other requests. This is normal behavior. Your client code will need to be able to recover from that error.
We've got such kind of recovery mechanism. If the request fails, we are trying to fetch it again after a random time.

I start to think that in the SDK, we are doing something wrong, so I've used  grpcurl library to perform grpc requests from the console. Then I used to do a request every 10 seconds to get the address book with the following command:
while sleep 10; do grpcurl -plaintext -d '{"file_id": {"fileNum": 102}, "limit": 0}' hcs.previewnet.mirrornode.hedera.com:5600 com.hedera.mirror.api.proto.NetworkService/getNodes; done
Again randomly, some of the requests were failing with the following error:
Code: Unavailable Message: unexpected HTTP status code received from server: 429 (Too Many Requests); transport: received unexpected content-type "text/plain; charset=utf-8"

Then I changed the period for getting the nodes for updating the address book into the SDK from 10 seconds to 20 seconds and again apply the previous scenario with the 1000 AccountBalanceQuery transactions. This time, every single request for updating the address book went through without errors.

Then I've also run the following command for fetching manually the nodes through the console, but this time with 20 seconds period between each request:
while sleep 20; do grpcurl -plaintext -d '{"file_id": {"fileNum": 102}, "limit": 0}' hcs.previewnet.mirrornode.hedera.com:5600 com.hedera.mirror.api.proto.NetworkService/getNodes; done
Every single request went through without any error.

So my consideration here is that we are doing a lot of requests to the Mirror Node (no matter if it is mainnet, testnet, or previewnet) and thus making it fail for some of them.

Why are we updating the address book every 10s? It should be way less frequent. This generates a ton of traffic on the mirror node with no real value. I think it should be once per day, at most once per hour. Node additions are extremely rare.

Why are we updating the address book every 10s? It should be way less frequent. This generates a ton of traffic on the mirror node with no real value. I think it should be once per day, at most once per hour. Node additions (or other address book updates) are extremely rare.

I believe that the logic behind that is built because of healthy/unhealthy nodes. When a node is marked as unhealthy, and based on those 10 seconds for fetching the address book, as soon as the address book is fetched again, the healthy nodes are cleared and setup again and the unhealthy nodes are restarted (empty). So I believe this is created so we can monitor which nodes are healthy and which not.

I would agree with Steven here. SDK should have some logic where it polls for updated address book at lets say once every 6hrs OR if +30% of its known address book is unreachable. This feature is intended for Community Nodes and I do not see a need is foreseeable future  where we would need to get this updated every 10sec.

I would agree with Steven here. SDK should have some logic where it polls for updated address book at lets say once every 6hrs OR if +30% of its known address book is unreachable. This feature is intended for Community Nodes and I do not see a need is foreseeable future where we would need to get this updated every 10sec.

That sounds reasonable. I would just add that the OR if +30% of its known address book is unreachable should be done immediately the first time but not every 10s after that. Perhaps every 10 minutes or more. Especially since nodes become unreachable during upgrades and that would cause unnecessary spikes in mirror node requests.

This is also filling up my logs,

This seems related to the use of hcs.previewnet.mirrornode.hedera.com:5600 here, instead of previewnet.mirrornode.hedera.com:443. Fixing that solve the issue.
As a workaround waiting for the new version, you can set clientSDK.setMirrorNetwork("previewnet.mirrornode.hedera.com:443"); to force the SDK to use that address.

@teacoat We are working on fixing that. On which network do you get the error?
@Neurone I am not sure that this URL is working. I've tested it through grpcurl and it does not resolve.

@ochikov It works well for me, are you in a dedicated/enterprise network? I'm in my private home network, I tried also via VPN in different regions, and it works.
Here the results using grpcurl with both addresses and the resolution via nslookup.
❯ nslookup hcs.previewnet.mirrornode.hedera.com
Server:		<IP_ADDRESS>
Address:	<IP_ADDRESS>#53

Non-authoritative answer:
Name:	hcs.previewnet.mirrornode.hedera.com
Address: <IP_ADDRESS>

❯ nslookup previewnet.mirrornode.hedera.com
Server:		<IP_ADDRESS>
Address:	<IP_ADDRESS>#53

Non-authoritative answer:
Name:	previewnet.mirrornode.hedera.com
Address: <IP_ADDRESS>

❯ grpcurl -d '{"file_id": {"fileNum": 102}, "limit": 0}' hcs.previewnet.mirrornode.hedera.com:5600 com.hedera.mirror.api.proto.NetworkService/getNodes
Failed to dial target host "hcs.previewnet.mirrornode.hedera.com:5600": EOF

❯ grpcurl -d '{"file_id": {"fileNum": 102}, "limit": 0}' previewnet.mirrornode.hedera.com:443 com.hedera.mirror.api.proto.NetworkService/getNodes
{
  "RSA_PubKey": "308201a2300d06092a864886f70d01010105000382018f003082018a02820181009f1f8a121c2fd6c76fd508d3e429f0c64bcb44c82a70573552aadcad071569e721958f5a5d09f9587ffafcfbe5341a2f0114acae346ef3c90213d3436ebb27f4350c990c5c8c3f8e1e36707bc08d42560823e3f24e09a03ad0955a5098019629dd04b27b251dce055f3ddcb0a41d66f0941b0b87cdfe3498d46038ab5df06f62a5ade08598573a88c8f5860dc1492a6e186485a9b13250e6d17b80cd39c5c819109e73ca732db23ef8baa776ec85ce0091becb2edefbaa5ed3e5dbfbd1f885a4fa881af3f144a8a565853533d89393592086b2d1d362e45bfe1fb45683aba6c640979ad6b46877184726c6ebd58b2eae85c7cfe3fbabef5f6cced850034b3847206c2d678c361876026b8d351e002af5e0ffe6f5b1f295fdc2f469caa2d2381ea0b48ca987cc2c8e635e8b19ce5e172a93761a8d490a9a4518d7255880a14d77b7ba774892b92a40bb81362e34fc6d5178d9b30112934205cb77fb9a282427394564a8554ea47286a47f86239e75c94789ce98c99844782462944f613167d7b50203010001",
  "nodeAccountId": {
    "accountNum": "3"
  },
  "nodeCertHash": "ZmZkNmFkYTc0YTNhMzRhOTA0YmVhNDc2MDMwODZmOGJlZjNiNmJlMThhYmVkNDRjNGQ0MGUxMmZiMTMwYjk3YmQ2Yjg1NWFlYzVkMGI5MGIwYjhjNzM1NGQ1ZjNiMGU0",
  "serviceEndpoint": [
    {
      "ipAddressV4": "I+fQlA==",
      "port": 50211
    },
    {
      "ipAddressV4": "KHlAMA==",
      "port": 50211
    },
    {
      "ipAddressV4": "I+fQlA==",
      "port": 50212
    },
    {
      "ipAddressV4": "A9P4rA==",
      "port": 50212
    },
    {
      "ipAddressV4": "A9P4rA==",
      "port": 50211
    },
    {
      "ipAddressV4": "KHlAMA==",
      "port": 50212
    }
  ],
  "description": "Hosted by Hedera | East Coast, USA",
  "stake": "10"
}
{
  "RSA_PubKey": "308201a2300d06092a864886f70d01010105000382018f003082018a0282018100c557af579fa83501be899b28907765bfdfcd52ab432b0195a1f1ecd86fc00ab6c5509b0fdd97edd3cb5cea56a295f312abb550831dbf963f450118b4fcc6e22cf4676200ce9cc8edfbbf558dc69f024264ad7d3dab23bed2133c274e6934489155db1087f90370905c64185a6211dc742fb9a6909d82186947b277463dfb3ff0acd47eff12ead1f6972ef2c1203793c45e77575be4fa110c7e40fa8db9c6187d113f4704014179071abf59be7d2b0de82de4215dc25506b1c9c26e4917401c997506e377e6bf03b688727e7940fad69c5e0da3cd5cbd2be777350aea2d0d47e97a448c84be6ce134d64bee0985c29162f4c1e567cca93d06a3c1be8abce35b557fb77f4fe671a66dec790756d0e8818165f2bacaa891aae7ac7437fc7175b6eb6deb7472378751bb6bf9b0e1483f9668e9fdbd5604c39b14d9e2bedeec846a980d704d171e7ba4b7fcd1a30d945ca12f47a325d9398aa18f97066054d4d15fc8994e2debe73e9271d548683f61ea44fb25071e3518a78ed3eb37e71a0691f2670203010001",
  "nodeId": "1",
  "nodeAccountId": {
    "accountNum": "4"
  },
  "nodeCertHash": "ZjBkOTRhY2NmNmRmZjM3Mjg3NGM5ZGJkOGQ3OTkyZWIzMTdhZjUwMDFjYTQxOTZhYmEyNjU4MDljYjNkMjAwYmE5NjFhNTQzOGMzYTVlZDA1YzgzYmRmOWNkMTE1ZDIy",
  "serviceEndpoint": [
    {
      "ipAddressV4": "A4XVkg==",
      "port": 50212
    },
    {
      "ipAddressV4": "KEYLyg==",
      "port": 50212
    },
    {
      "ipAddressV4": "A4XVkg==",
      "port": 50211
    },
    {
      "ipAddressV4": "I8cPsQ==",
      "port": 50212
    },
    {
      "ipAddressV4": "KEYLyg==",
      "port": 50211
    },
    {
      "ipAddressV4": "I8cPsQ==",
      "port": 50211
    }
  ],
  "description": "Hosted by Hedera | East Coast, USA",
  "stake": "10"
}
{
  "RSA_PubKey": "308201a2300d06092a864886f70d01010105000382018f003082018a02820181009ba457b73305f04a91cc46b1b965c4e841751abc8b1415a0badfd1f32c2482386a22725eb7ec74dea21e50617d648ea5ac393741ab01b8efb321239b8d4fdb1dfbeb9e3f39aa46580dd045d18ca44d002c37ddb527cce4ddc32bfc73419671f4ca4464a3f2a84fc85c71acf0e5a89626df69a81474ed16529f801a8afa97e435c4e04a964a357527288843e58f0a05cf5153ee4507b2c68b3d7fb54ae6a95a959c87a12f630e95c7b1b3c3695e858662417926d76c16983faf61225038745907e9cf13d67c2acd503ca451c85933ac4118acc279801cb968349903145ced27629dd08916317093587a77c2205cfa52543b53c3b6ea15b84e3d2c30c1ed752a4633c36b25b9893ea02ad562eb9b7868b3b4f47f4a25e356064962ac7b25e582944f00d30798a262f9214d8c5e74d0a8376cc2d6ba64e18f5e4a40afac625062d2ca23cd2800708321d3834314f0e5844859232673a32e70ae0d711e310581bcdb14e87134694c6e0930f46b37b96d49a64573947331e7e507d9e56de5e6146f2f0203010001",
  "nodeId": "2",
  "nodeAccountId": {
    "accountNum": "5"
  },
  "nodeCertHash": "Y2E2NzhlYmNiZDNkYzg2NDhmN2VkMDNmYjU5ZjBlMjFhZjY3NTEzZWFlZTUxMzE4ZTZiNTQ5YmU1YWNlOTA2ZWRjMWZmYTI2ZDkzYTU3YWNlYzliZTc3ZjQwZWFlZWQ3",
  "serviceEndpoint": [
    {
      "ipAddressV4": "NA9pgg==",
      "port": 50212
    },
    {
      "ipAddressV4": "aCv4Pw==",
      "port": 50212
    },
    {
      "ipAddressV4": "I+HJww==",
      "port": 50212
    },
    {
      "ipAddressV4": "NA9pgg==",
      "port": 50211
    },
    {
      "ipAddressV4": "I+HJww==",
      "port": 50211
    },
    {
      "ipAddressV4": "aCv4Pw==",
      "port": 50211
    }
  ],
  "description": "Hosted by Hedera | Central, USA",
  "stake": "10"
}
{
  "RSA_PubKey": "308201a2300d06092a864886f70d01010105000382018f003082018a0282018100c42ccac5fbc691fbbebda87ffd1e75bdcd8922494cf44fdbccee49788521c378bf77db0934ec0d2183d7c51db66f864c11ab7de1ac3c4cfdc1f093a2d6f37e2b34cbe4c8131f9683ad42878c83d3554c645aa167bcfb064a83dc45c5b1158499f9d92587fff7abcd5f221cd8150548413000fa6e5659089b1dfd65766ea78eaedfca6b45455fd8ab5984dbe35e5795d2c635ea7974d43e8eae4febffe492e707b48b1b0fc6481ae9e09d39133009b7d26402e6e52e5e91b2b380d88f0be7fb4b303e70219785057aa94ce924c4926e916569286e86b3ba651ca2a0a63df4f6907fefe3483d93b4ce1d4d03c7142111375b2c2c51d4eb839e37af530b2cbd6f50d4cb36e27937170d9cddac0ace2cc24b804b0a27351cf830b76525e26dfb9dbf49a056624a76862494e7263d0d70cebae952943e55842f5cad13fcf60a2e6dcf7a1d533f3a5bb54ec21918c76e525ba29146675831e17e36c61fe85498828d09b762015412b2e527849baec1cffc77de4c294c550811e598ff24da15a34569dd0203010001",
  "nodeId": "3",
  "nodeAccountId": {
    "accountNum": "6"
  },
  "nodeCertHash": "MjQ3MWYzZmU4MTQwNjgxZmU5MTkxM2QyY2MwNjNmMDY1ZTQ0OTBhZTYyZmY1ZDU0OGE1YWJlMTMxZDJhZjk2Y2JlM2FjMjViYmUyNDM2NmNhNGY4ZjBlNzZjZjk0NWYz",
  "serviceEndpoint": [
    {
      "ipAddressV4": "NvEmAQ==",
      "port": 50211
    },
    {
      "ipAddressV4": "I/dthw==",
      "port": 50211
    },
    {
      "ipAddressV4": "DVgWLw==",
      "port": 50211
    },
    {
      "ipAddressV4": "NvEmAQ==",
      "port": 50212
    },
    {
      "ipAddressV4": "DVgWLw==",
      "port": 50212
    },
    {
      "ipAddressV4": "I/dthw==",
      "port": 50212
    }
  ],
  "description": "Hosted by Hedera | West Coast, USA",
  "stake": "10"
}
{
  "RSA_PubKey": "308201a2300d06092a864886f70d01010105000382018f003082018a0282018100902f0490a9b7f5d2cd1c0d96c6a6990f573b5f0eb5bdbba39661ef023092419344669969a68a4c7071d329990fb1792e9001cb5598ea71c2d6676824320ee4cabf1dd357ae7f2adbedc1b1b0a9d95623779b4c4c7b47c4787a16ee7188c7217177624a9264ab39c41f7ff0b45a89bda40c4ad07c4d596d5f09d7056bcb5a35f44f95a59c266e09892dcbe46ad51f2d2b3e991a8f6658e1f2cb94c773eb44c44e892d1e55c1076f1608319ee657e40f192967543ab42ab222386d17586e253748dabd025e50b50ae6050720e239d64ee6fb4507c0614dd4be7afdb1330890ff3a6e176527c3116af129a9ac5e336d9f601e7127a6d7d820ad2f902dac9b248668a1bab08d10342ea69a7097132ff7120cc64fcde7840c656ba1732ba95e9c36751175e4ec3d84a7e0d28842b41bbbbd6f28e46c3a6633e1827965c55820d50dae2b0465cc0d42e195b9d1532e6225eb998d6a49079a8a1cd4d0175de3c87f97614847b3cbb17aa34be820b7b3ad98ac3faef993a6778974782c0c4ae3fabbcc430203010001",
  "nodeId": "4",
  "nodeAccountId": {
    "accountNum": "7"
  },
  "nodeCertHash": "ZjM1Nzg3M2Q0MTE0YTFhZWYwM2FkYzZiYTY5ZWZhZjI2OTBlMjI3YWJjMTZhNmZjNmU1MDQ5YTYzZmJkOTY4ODAwNGIxNGU0NjNjMjBlMzg0MzZhM2EyNGQzMTgyZGQ4",
  "serviceEndpoint": [
    {
      "ipAddressV4": "I+tBMw==",
      "port": 50211
    },
    {
      "ipAddressV4": "NrEzfw==",
      "port": 50212
    },
    {
      "ipAddressV4": "I+tBMw==",
      "port": 50212
    },
    {
      "ipAddressV4": "DUCqKA==",
      "port": 50211
    },
    {
      "ipAddressV4": "DUCqKA==",
      "port": 50212
    },
    {
      "ipAddressV4": "NrEzfw==",
      "port": 50211
    }
  ],
  "description": "Hosted by Hedera | West Coast, USA",
  "stake": "10"
}
{
  "RSA_PubKey": "308201a2300d06092a864886f70d01010105000382018f003082018a028201810091d7dfff78f4efbe5890450c5bc9e3534bffadad93fb7afb15bc7bcf67d3d3b413bd99940dd82564ada04ab2e4edf0a1c0b8fb7e1a8092e9138e960be2cc68b5b97f57d281c5872e97a479fc848363160e3863b57b33e4869b185ace5e36bd43ae5fa678c9eb66f1f4014786826b2f8fa7e0060f4405c0a8f9da7205ff4683a243fa0f315f1afbb4a4d140d02234e4473fb92fcb38f3eb28c60cf7cbfb64e069c18086e4dd61938920ae0fd7c193e6e104e65b817ed9398e232237fdf08322c9cec09d4099272a7c015d22b4dcc969f6ea1f518902105df60092b55a41b4f32b957b57d84e5b223905e8698951733ea9f2e2461ec0d6522ee816d5850facfeb412cff9b99943a87dc0d046447ce93b97e16d73b96b4263962f81fcf9458e57577c780a6f1615aa7a12326738e269bb731f89e891622e577ea54420bf0ca46be6fc4f71cf2681ac0252aa885e13be672cd284590427dcd137cf311625e8bee3b08fdcaaf465b387ce7cb33816f2c14a6b99ac7d734318cfc59b7ed939bafef8790203010001",
  "nodeId": "5",
  "nodeAccountId": {
    "accountNum": "8"
  },
  "nodeCertHash": "NDkzMWE3ODIwMmQ1NWYxMGIzMTU3NTc4NWMzZjQzOWRiNjgxOWJkMTEwMDNkZjdiYzJjZTkyZTI5YTUxN2I3YzIxODgwZGViNGMwMTc5NTc0NGI1NzZjZDQzYjg0OThk",
  "serviceEndpoint": [
    {
      "ipAddressV4": "Imr3QQ==",
      "port": 50211
    },
    {
      "ipAddressV4": "I1NZqw==",
      "port": 50212
    },
    {
      "ipAddressV4": "Imr3QQ==",
      "port": 50212
    },
    {
      "ipAddressV4": "DU7owA==",
      "port": 50211
    },
    {
      "ipAddressV4": "DU7owA==",
      "port": 50212
    },
    {
      "ipAddressV4": "I1NZqw==",
      "port": 50211
    }
  ],
  "description": "Hosted by Hedera | West Coast, USA",
  "stake": "10"
}
{
  "RSA_PubKey": "308201a2300d06092a864886f70d01010105000382018f003082018a0282018100c6e18c8fbf4cd4eb104542cb20aaaa252d95f052f1086d581c44ad737bf6676c0c3f789af5265b8afb79b50912da84e0afcf7547cb1fff08d0527017eb6dc5cdf83b51969d44336a6387cd70b94bf4c9baf2029840e5f4f863d7081f0fa81e0863adedb8b89a5dac2bb552d6e7b9fba222ac28c57075538fc957992942d341fa2876e6b507e9ce7ed572e8cfda5defa364fdf8d8e23829a4ccbb478f11eee3b32ab85e072951c5d9420115fba327073494f43b5f6bebf84152e356e7b16ba764b7a3b52cb2734640163be1465e6d1fa4c6e6f66684a635c9a556aa7100dbe645df8f4c423ae45a08cb35b4bc187886e2299b5c0210a5fba3b9449f483ef94ed922e1e98c113be166b89c73582243135d442306abe5a71b77018ff335d6dd79542697b168238b96727fd1339b5f82a3b6a597d976037ae2506456c8b34e9fbf3bc32410441c4bfc8eba58597254efebfaa78809a5c8854729a5ba78ece19fc8407dd8894a6bc7844037d878cace6c152c2e89e8a64b068a6c237e09993be806890203010001",
  "nodeId": "6",
  "nodeAccountId": {
    "accountNum": "9"
  },
  "nodeCertHash": "NjRlMDk4NjE1YmY0MDVmN2VkNWE0MDEzNDQ2Yjg5YzQ4OGNmY2Q2YmIyNWE0YTY3NmRjNzdlZWExMWQzM2Q3MDI2ODJmMGE2OWE4MDMwZThjNTc3N2QwZTQyMjAzNzk5",
  "serviceEndpoint": [
    {
      "ipAddressV4": "MhIRXQ==",
      "port": 50212
    },
    {
      "ipAddressV4": "FJaIWQ==",
      "port": 50212
    },
    {
      "ipAddressV4": "FJaIWQ==",
      "port": 50211
    },
    {
      "ipAddressV4": "In0XMQ==",
      "port": 50212
    },
    {
      "ipAddressV4": "In0XMQ==",
      "port": 50211
    },
    {
      "ipAddressV4": "MhIRXQ==",
      "port": 50211
    }
  ],
  "description": "Hosted by Hedera | West Coast, USA",
  "stake": "10"
}
❯ grpcurl -d '{"file_id": {"fileNum": 102}, "limit": 0}' previewnet.mirrornode.hedera.com:443 com.hedera.mirror.api.proto.NetworkService/getNodes
{
  "RSA_PubKey": "308201a2300d06092a864886f70d01010105000382018f003082018a02820181009f1f8a121c2fd6c76fd508d3e429f0c64bcb44c82a70573552aadcad071569e721958f5a5d09f9587ffafcfbe5341a2f0114acae346ef3c90213d3436ebb27f4350c990c5c8c3f8e1e36707bc08d42560823e3f24e09a03ad0955a5098019629dd04b27b251dce055f3ddcb0a41d66f0941b0b87cdfe3498d46038ab5df06f62a5ade08598573a88c8f5860dc1492a6e186485a9b13250e6d17b80cd39c5c819109e73ca732db23ef8baa776ec85ce0091becb2edefbaa5ed3e5dbfbd1f885a4fa881af3f144a8a565853533d89393592086b2d1d362e45bfe1fb45683aba6c640979ad6b46877184726c6ebd58b2eae85c7cfe3fbabef5f6cced850034b3847206c2d678c361876026b8d351e002af5e0ffe6f5b1f295fdc2f469caa2d2381ea0b48ca987cc2c8e635e8b19ce5e172a93761a8d490a9a4518d7255880a14d77b7ba774892b92a40bb81362e34fc6d5178d9b30112934205cb77fb9a282427394564a8554ea47286a47f86239e75c94789ce98c99844782462944f613167d7b50203010001",
  "nodeAccountId": {
    "accountNum": "3"
  },
  "nodeCertHash": "ZmZkNmFkYTc0YTNhMzRhOTA0YmVhNDc2MDMwODZmOGJlZjNiNmJlMThhYmVkNDRjNGQ0MGUxMmZiMTMwYjk3YmQ2Yjg1NWFlYzVkMGI5MGIwYjhjNzM1NGQ1ZjNiMGU0",
  "serviceEndpoint": [
    {
      "ipAddressV4": "I+fQlA==",
      "port": 50211
    },
    {
      "ipAddressV4": "KHlAMA==",
      "port": 50211
    },
    {
      "ipAddressV4": "I+fQlA==",
      "port": 50212
    },
    {
      "ipAddressV4": "A9P4rA==",
      "port": 50212
    },
    {
      "ipAddressV4": "A9P4rA==",
      "port": 50211
    },
    {
      "ipAddressV4": "KHlAMA==",
      "port": 50212
    }
  ],
  "description": "Hosted by Hedera | East Coast, USA",
  "stake": "10"
}
{
  "RSA_PubKey": "308201a2300d06092a864886f70d01010105000382018f003082018a0282018100c557af579fa83501be899b28907765bfdfcd52ab432b0195a1f1ecd86fc00ab6c5509b0fdd97edd3cb5cea56a295f312abb550831dbf963f450118b4fcc6e22cf4676200ce9cc8edfbbf558dc69f024264ad7d3dab23bed2133c274e6934489155db1087f90370905c64185a6211dc742fb9a6909d82186947b277463dfb3ff0acd47eff12ead1f6972ef2c1203793c45e77575be4fa110c7e40fa8db9c6187d113f4704014179071abf59be7d2b0de82de4215dc25506b1c9c26e4917401c997506e377e6bf03b688727e7940fad69c5e0da3cd5cbd2be777350aea2d0d47e97a448c84be6ce134d64bee0985c29162f4c1e567cca93d06a3c1be8abce35b557fb77f4fe671a66dec790756d0e8818165f2bacaa891aae7ac7437fc7175b6eb6deb7472378751bb6bf9b0e1483f9668e9fdbd5604c39b14d9e2bedeec846a980d704d171e7ba4b7fcd1a30d945ca12f47a325d9398aa18f97066054d4d15fc8994e2debe73e9271d548683f61ea44fb25071e3518a78ed3eb37e71a0691f2670203010001",
  "nodeId": "1",
  "nodeAccountId": {
    "accountNum": "4"
  },
  "nodeCertHash": "ZjBkOTRhY2NmNmRmZjM3Mjg3NGM5ZGJkOGQ3OTkyZWIzMTdhZjUwMDFjYTQxOTZhYmEyNjU4MDljYjNkMjAwYmE5NjFhNTQzOGMzYTVlZDA1YzgzYmRmOWNkMTE1ZDIy",
  "serviceEndpoint": [
    {
      "ipAddressV4": "A4XVkg==",
      "port": 50212
    },
    {
      "ipAddressV4": "KEYLyg==",
      "port": 50212
    },
    {
      "ipAddressV4": "A4XVkg==",
      "port": 50211
    },
    {
      "ipAddressV4": "I8cPsQ==",
      "port": 50212
    },
    {
      "ipAddressV4": "KEYLyg==",
      "port": 50211
    },
    {
      "ipAddressV4": "I8cPsQ==",
      "port": 50211
    }
  ],
  "description": "Hosted by Hedera | East Coast, USA",
  "stake": "10"
}
{
  "RSA_PubKey": "308201a2300d06092a864886f70d01010105000382018f003082018a02820181009ba457b73305f04a91cc46b1b965c4e841751abc8b1415a0badfd1f32c2482386a22725eb7ec74dea21e50617d648ea5ac393741ab01b8efb321239b8d4fdb1dfbeb9e3f39aa46580dd045d18ca44d002c37ddb527cce4ddc32bfc73419671f4ca4464a3f2a84fc85c71acf0e5a89626df69a81474ed16529f801a8afa97e435c4e04a964a357527288843e58f0a05cf5153ee4507b2c68b3d7fb54ae6a95a959c87a12f630e95c7b1b3c3695e858662417926d76c16983faf61225038745907e9cf13d67c2acd503ca451c85933ac4118acc279801cb968349903145ced27629dd08916317093587a77c2205cfa52543b53c3b6ea15b84e3d2c30c1ed752a4633c36b25b9893ea02ad562eb9b7868b3b4f47f4a25e356064962ac7b25e582944f00d30798a262f9214d8c5e74d0a8376cc2d6ba64e18f5e4a40afac625062d2ca23cd2800708321d3834314f0e5844859232673a32e70ae0d711e310581bcdb14e87134694c6e0930f46b37b96d49a64573947331e7e507d9e56de5e6146f2f0203010001",
  "nodeId": "2",
  "nodeAccountId": {
    "accountNum": "5"
  },
  "nodeCertHash": "Y2E2NzhlYmNiZDNkYzg2NDhmN2VkMDNmYjU5ZjBlMjFhZjY3NTEzZWFlZTUxMzE4ZTZiNTQ5YmU1YWNlOTA2ZWRjMWZmYTI2ZDkzYTU3YWNlYzliZTc3ZjQwZWFlZWQ3",
  "serviceEndpoint": [
    {
      "ipAddressV4": "NA9pgg==",
      "port": 50212
    },
    {
      "ipAddressV4": "aCv4Pw==",
      "port": 50212
    },
    {
      "ipAddressV4": "I+HJww==",
      "port": 50212
    },
    {
      "ipAddressV4": "NA9pgg==",
      "port": 50211
    },
    {
      "ipAddressV4": "I+HJww==",
      "port": 50211
    },
    {
      "ipAddressV4": "aCv4Pw==",
      "port": 50211
    }
  ],
  "description": "Hosted by Hedera | Central, USA",
  "stake": "10"
}
{
  "RSA_PubKey": "308201a2300d06092a864886f70d01010105000382018f003082018a0282018100c42ccac5fbc691fbbebda87ffd1e75bdcd8922494cf44fdbccee49788521c378bf77db0934ec0d2183d7c51db66f864c11ab7de1ac3c4cfdc1f093a2d6f37e2b34cbe4c8131f9683ad42878c83d3554c645aa167bcfb064a83dc45c5b1158499f9d92587fff7abcd5f221cd8150548413000fa6e5659089b1dfd65766ea78eaedfca6b45455fd8ab5984dbe35e5795d2c635ea7974d43e8eae4febffe492e707b48b1b0fc6481ae9e09d39133009b7d26402e6e52e5e91b2b380d88f0be7fb4b303e70219785057aa94ce924c4926e916569286e86b3ba651ca2a0a63df4f6907fefe3483d93b4ce1d4d03c7142111375b2c2c51d4eb839e37af530b2cbd6f50d4cb36e27937170d9cddac0ace2cc24b804b0a27351cf830b76525e26dfb9dbf49a056624a76862494e7263d0d70cebae952943e55842f5cad13fcf60a2e6dcf7a1d533f3a5bb54ec21918c76e525ba29146675831e17e36c61fe85498828d09b762015412b2e527849baec1cffc77de4c294c550811e598ff24da15a34569dd0203010001",
  "nodeId": "3",
  "nodeAccountId": {
    "accountNum": "6"
  },
  "nodeCertHash": "MjQ3MWYzZmU4MTQwNjgxZmU5MTkxM2QyY2MwNjNmMDY1ZTQ0OTBhZTYyZmY1ZDU0OGE1YWJlMTMxZDJhZjk2Y2JlM2FjMjViYmUyNDM2NmNhNGY4ZjBlNzZjZjk0NWYz",
  "serviceEndpoint": [
    {
      "ipAddressV4": "NvEmAQ==",
      "port": 50211
    },
    {
      "ipAddressV4": "I/dthw==",
      "port": 50211
    },
    {
      "ipAddressV4": "DVgWLw==",
      "port": 50211
    },
    {
      "ipAddressV4": "NvEmAQ==",
      "port": 50212
    },
    {
      "ipAddressV4": "DVgWLw==",
      "port": 50212
    },
    {
      "ipAddressV4": "I/dthw==",
      "port": 50212
    }
  ],
  "description": "Hosted by Hedera | West Coast, USA",
  "stake": "10"
}
{
  "RSA_PubKey": "308201a2300d06092a864886f70d01010105000382018f003082018a0282018100902f0490a9b7f5d2cd1c0d96c6a6990f573b5f0eb5bdbba39661ef023092419344669969a68a4c7071d329990fb1792e9001cb5598ea71c2d6676824320ee4cabf1dd357ae7f2adbedc1b1b0a9d95623779b4c4c7b47c4787a16ee7188c7217177624a9264ab39c41f7ff0b45a89bda40c4ad07c4d596d5f09d7056bcb5a35f44f95a59c266e09892dcbe46ad51f2d2b3e991a8f6658e1f2cb94c773eb44c44e892d1e55c1076f1608319ee657e40f192967543ab42ab222386d17586e253748dabd025e50b50ae6050720e239d64ee6fb4507c0614dd4be7afdb1330890ff3a6e176527c3116af129a9ac5e336d9f601e7127a6d7d820ad2f902dac9b248668a1bab08d10342ea69a7097132ff7120cc64fcde7840c656ba1732ba95e9c36751175e4ec3d84a7e0d28842b41bbbbd6f28e46c3a6633e1827965c55820d50dae2b0465cc0d42e195b9d1532e6225eb998d6a49079a8a1cd4d0175de3c87f97614847b3cbb17aa34be820b7b3ad98ac3faef993a6778974782c0c4ae3fabbcc430203010001",
  "nodeId": "4",
  "nodeAccountId": {
    "accountNum": "7"
  },
  "nodeCertHash": "ZjM1Nzg3M2Q0MTE0YTFhZWYwM2FkYzZiYTY5ZWZhZjI2OTBlMjI3YWJjMTZhNmZjNmU1MDQ5YTYzZmJkOTY4ODAwNGIxNGU0NjNjMjBlMzg0MzZhM2EyNGQzMTgyZGQ4",
  "serviceEndpoint": [
    {
      "ipAddressV4": "I+tBMw==",
      "port": 50211
    },
    {
      "ipAddressV4": "NrEzfw==",
      "port": 50212
    },
    {
      "ipAddressV4": "I+tBMw==",
      "port": 50212
    },
    {
      "ipAddressV4": "DUCqKA==",
      "port": 50211
    },
    {
      "ipAddressV4": "DUCqKA==",
      "port": 50212
    },
    {
      "ipAddressV4": "NrEzfw==",
      "port": 50211
    }
  ],
  "description": "Hosted by Hedera | West Coast, USA",
  "stake": "10"
}
{
  "RSA_PubKey": "308201a2300d06092a864886f70d01010105000382018f003082018a028201810091d7dfff78f4efbe5890450c5bc9e3534bffadad93fb7afb15bc7bcf67d3d3b413bd99940dd82564ada04ab2e4edf0a1c0b8fb7e1a8092e9138e960be2cc68b5b97f57d281c5872e97a479fc848363160e3863b57b33e4869b185ace5e36bd43ae5fa678c9eb66f1f4014786826b2f8fa7e0060f4405c0a8f9da7205ff4683a243fa0f315f1afbb4a4d140d02234e4473fb92fcb38f3eb28c60cf7cbfb64e069c18086e4dd61938920ae0fd7c193e6e104e65b817ed9398e232237fdf08322c9cec09d4099272a7c015d22b4dcc969f6ea1f518902105df60092b55a41b4f32b957b57d84e5b223905e8698951733ea9f2e2461ec0d6522ee816d5850facfeb412cff9b99943a87dc0d046447ce93b97e16d73b96b4263962f81fcf9458e57577c780a6f1615aa7a12326738e269bb731f89e891622e577ea54420bf0ca46be6fc4f71cf2681ac0252aa885e13be672cd284590427dcd137cf311625e8bee3b08fdcaaf465b387ce7cb33816f2c14a6b99ac7d734318cfc59b7ed939bafef8790203010001",
  "nodeId": "5",
  "nodeAccountId": {
    "accountNum": "8"
  },
  "nodeCertHash": "NDkzMWE3ODIwMmQ1NWYxMGIzMTU3NTc4NWMzZjQzOWRiNjgxOWJkMTEwMDNkZjdiYzJjZTkyZTI5YTUxN2I3YzIxODgwZGViNGMwMTc5NTc0NGI1NzZjZDQzYjg0OThk",
  "serviceEndpoint": [
    {
      "ipAddressV4": "Imr3QQ==",
      "port": 50211
    },
    {
      "ipAddressV4": "I1NZqw==",
      "port": 50212
    },
    {
      "ipAddressV4": "Imr3QQ==",
      "port": 50212
    },
    {
      "ipAddressV4": "DU7owA==",
      "port": 50211
    },
    {
      "ipAddressV4": "DU7owA==",
      "port": 50212
    },
    {
      "ipAddressV4": "I1NZqw==",
      "port": 50211
    }
  ],
  "description": "Hosted by Hedera | West Coast, USA",
  "stake": "10"
}
{
  "RSA_PubKey": "308201a2300d06092a864886f70d01010105000382018f003082018a0282018100c6e18c8fbf4cd4eb104542cb20aaaa252d95f052f1086d581c44ad737bf6676c0c3f789af5265b8afb79b50912da84e0afcf7547cb1fff08d0527017eb6dc5cdf83b51969d44336a6387cd70b94bf4c9baf2029840e5f4f863d7081f0fa81e0863adedb8b89a5dac2bb552d6e7b9fba222ac28c57075538fc957992942d341fa2876e6b507e9ce7ed572e8cfda5defa364fdf8d8e23829a4ccbb478f11eee3b32ab85e072951c5d9420115fba327073494f43b5f6bebf84152e356e7b16ba764b7a3b52cb2734640163be1465e6d1fa4c6e6f66684a635c9a556aa7100dbe645df8f4c423ae45a08cb35b4bc187886e2299b5c0210a5fba3b9449f483ef94ed922e1e98c113be166b89c73582243135d442306abe5a71b77018ff335d6dd79542697b168238b96727fd1339b5f82a3b6a597d976037ae2506456c8b34e9fbf3bc32410441c4bfc8eba58597254efebfaa78809a5c8854729a5ba78ece19fc8407dd8894a6bc7844037d878cace6c152c2e89e8a64b068a6c237e09993be806890203010001",
  "nodeId": "6",
  "nodeAccountId": {
    "accountNum": "9"
  },
  "nodeCertHash": "NjRlMDk4NjE1YmY0MDVmN2VkNWE0MDEzNDQ2Yjg5YzQ4OGNmY2Q2YmIyNWE0YTY3NmRjNzdlZWExMWQzM2Q3MDI2ODJmMGE2OWE4MDMwZThjNTc3N2QwZTQyMjAzNzk5",
  "serviceEndpoint": [
    {
      "ipAddressV4": "MhIRXQ==",
      "port": 50212
    },
    {
      "ipAddressV4": "FJaIWQ==",
      "port": 50212
    },
    {
      "ipAddressV4": "FJaIWQ==",
      "port": 50211
    },
    {
      "ipAddressV4": "In0XMQ==",
      "port": 50212
    },
    {
      "ipAddressV4": "In0XMQ==",
      "port": 50211
    },
    {
      "ipAddressV4": "MhIRXQ==",
      "port": 50211
    }
  ],
  "description": "Hosted by Hedera | West Coast, USA",
  "stake": "10"
}

The official documentation can be changed if needed ;) But no problem to wait for the next releaseI'm a bit skeptical this problem is related to the SDK fetching sequence - I suppose it's the same frequency even when you change the url, and the new one has no problem, and I just tried again with grpcurl, and the old address still doesn't work for me, regardless of the SDK - but we can wait for a new type of fix

@Neurone on my side the two URLs are working. However, I will check with the team of the mirror node if we need to change the URL. Keep in mind that the Mirror Node has some limitations of fetching and if a lot of people are using the first or the second proxy, the problem might occur as well. I will check and return it to you again.

❯ grpcurl -d '{"file_id": {"fileNum": 102}, "limit": 0}' hcs.previewnet.mirrornode.hedera.com:5600 com.hedera.mirror.api.proto.NetworkService/getNodes
Failed to dial target host "hcs.previewnet.mirrornode.hedera.com:5600": EOF

You need to use -plaintext since port 5600 is not TLS and gprcurl defaults to assuming TLS.
hcs.previewnet.mirrornode.hedera.com:5600 redirects to previewnet.mirrornode.hedera.com:443 via a proxy. This is to provide backwards compatibility as we transition mirror nodes from VM to Kubernetes. We will open a ticket when it's appropriate to transition the SDKs to the new URL.


add sonarcloud coverage

Running the same command locally gives result, while Github Actions does not produce any.

See gaepdit/EPD-IT#82

It looks like your latest commit is working. I tried getting coverlet to work as well and got the same result as you: The command works fine when run locally but returns no results on GitHub. But since you got this other method to work, it's not worth pursuing.
One question though. Is the trx logger option still needed or was that just for testing? If it's not needed, please remove, and I'll merge this on Monday. Thanks for your great work on this!

the result-directory option used to require the logger option to work (https://stackoverflow.com/questions/49390416/dotnet-test-not-creating-test-results-folder). I have tested it locally, and it is not needed anymore.

the result-directory option used to require the logger option to work (https://stackoverflow.com/questions/49390416/dotnet-test-not-creating-test-results-folder). I have tested it locally, and it is not needed anymore.

Ok, thanks. I was wondering if it was something like that.


fix: bug 1634 - filters don't accurately refresh their ui

Entity and action filters in the training dialog didn't refresh the true filter if one switches from any non-"any" filter, then back to "-any-". Fix sets the selectedIndex to "-1" which is the "-any-" key value.

:tada: This PR is included in version 0.324.10 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


enhance the Faq page.

Use Headless UI or React Accordions to allow users to expand/collapse each FAQ for better readability.
Add a search bar to filter FAQs based on keywords.

@MOHAMMED-IQRAMUL assign me this.


The picture is blurred after enlarging. How to deal with it

💬 Questions and Help
For questions or help we recommend checking:

Stack Overflow

If you're looking for a zoom image component on Android, take a look at my ZoomImage (https://github.com/panpf/zoomimage) library. It can be used for View and Compose, supports scaling, panning, positioning, rotation, and super-large image subsampling. It also integrates image loaders such as sketch, glide, picasso, coil, etc.
如果你正在寻找 Android 上的变焦图像组件，可以看看我的 ZoomImage (https://github.com/panpf/zoomimage) 库。它可用于 View 和 Compose，支持缩放、平移、定位、旋转、超大图子采样，它还集成了 sketch、glide、picasso、coil 等图像加载器


Error in main::check_binary from samtools --version

Hey there,
Newer versions of samtools (at least, V1.19) no longer support a --version command, causing this error:
[Wed Sep  2 16:31:51 2015] Checking required binaries
[main] unrecognized command '--version'
#------------------------------------------------------------------------------#
[Wed Sep  2 16:31:51 2015] Couldn't determine version of samtools, at least 1.1
required
Exited at 'main'
'./bin/proovread', line 2045
Last call 'main::check_binary'
'./bin/proovread', line 663
This can be solved by using samtools 1.1 of course, but I thought I'd bring it to your attention.
Other than that, installation and testing was successful on my laptop running Ubuntu 14.04!
Cheers,
Connor

the samtools versioning format is a little bit confusing, there actually is no version 1.19, only 0.1.19, which you seem to have. Versions starting with "0" are older than the current releases:
0.1.19 - old, and unfortunately doesn't support --version
1.1 - minimum for proovread
1.2 - current


fix(policies): add default value for the enroll mfa policy to enable saving

fixes gravitee-io/issues#8112

Code is good and allow me to save when only one Factor is configured but I'm also able to save if I do not select a factor. Don't know if it is something that we can improve thinking
also if the RecoveryCode factor is configured, it is proposed into the list. Is it expected ?

as discussed, we will open new issue for the behaviour described in this comment


[Developer] Settings panel dropdown saves string "null" instead of removing parameter

Describe The Bug:

When using a dropdown in the settings panel for a non-required string the config.json will store "parameter": "null" when selecting "None" in the dropdown.
To Reproduce:

Use e.g. homebridge-bravia and select "None" as TV input, see here: https://github.com/normen/homebridge-bravia/blob/master/config.schema.json
Expected behavior:

The settigs panel should remove the non-required variables where "None" is selected in the dropdown.
Logs:

no errors -

Show the Homebridge / Homebridge Config UI X logs here.

Homebridge Config:
Show your homebridge config.json here

Screenshots:

Environment:

Node.js Version:
v10.20.1
NPM Version:
v6.14.4
Homebridge Version:
v1.0.4
Homebridge Config UI X Version:
v4.17.1
Operating System: Raspbian / Ubuntu / Debian / Windows / macOS / Docker
Raspbian 9 "Stretch
Process Supervisor: Docker / Systemd / init.d / pm2 / launchctl / hb-service / other / none
systemd

Hi @normen,
Can you test 4.17.3-test.6 (or latest @test) and let me know if the issue is resolved there?
https://github.com/oznu/homebridge-config-ui-x/wiki/How-To-Test-Upcoming-Changes
Thanks.

Yes it does, thanks!


fix: revert to react-tag-autocomplete v5

:tada: This PR is included in version 2.0.13 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


create-react-app: You may need an appropriate loader to handle this file type

I use https://github.com/facebook/create-react-app and it comes with ES6 and Babel, but I can't make this component to work:
./node_modules/react-medium-editor-es6/src/editor.js
Module parse failed: /Users/wiradikusuma/Documents/.../client/node_modules/react-medium-editor-es6/src/editor.js Unexpected token (14:21)
You may need an appropriate loader to handle this file type.
|
| export default class MediumEditor extends Component {
|     static propTypes = {
|         tag: PropTypes.string,
|         text: PropTypes.string,

I'm missing something?

Hello @wiradikusuma,
As mentioned in the installation step, you need to include this module in babel-loader's configuration so it can get transpiled with rest of the ES6 code. Evidently, create-react-app won't let you do that .
Perhaps you should use the original component (the one this package is forked from).


net/http:

What version of Go are you using (go version)?

$ go version
go version go1.21.1 linux/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.1'
GCCGO='/usr/bin/gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2527636589=/tmp/go-build -gno-record-gcc-switches'

What did you do?
server.go code

package main

import (
   "fmt"
   "net/http"
)

type handler struct {
}

func (h *handler) ServeHTTP (w http.ResponseWriter, r *http.Request) {
   go func() {
      ctx := r.Context()
      <- ctx.Done()
      log(ctx.Err())
   }()
   log(r.Method + " " + r.RequestURI + " " + r.Proto)
   d := w.Header()
   d.Set("Server", "foo/1.0")
   if origin := r.Header.Get("Origin"); "" != origin {
      d.Set("Access-Control-Allow-Origin", origin)
   }
   switch r.Method {
   case "PUT":
      w.WriteHeader(http.StatusRequestEntityTooLarge)
   case "OPTIONS":
      d.Set("Access-Control-Allow-Methods", "OPTIONS, GET, HEAD, PUT, DELETE")
      d.Set("Access-Control-Allow-Headers", "Content-Type")
      d.Set("Access-Control-Allow-Max-Age", "86400")
      d.Set("Access-Control-Allow-Credentials", "true")
      w.WriteHeader(http.StatusNoContent)
   }
   log("Done")
}

func log (i any) {
   fmt.Printf("%v\n", i)
}

func main () {
   srv := &http.Server{
      Addr: ":8888",
      Handler: &handler{},
   }
   log(srv.ListenAndServe())
}
I do (file size 10MB)

$ go run server.go
$ wget -t1 -qSO - --method=PUT --body-file=10MB.mp4 'http://localhost:8888/'

server log

PUT / HTTP/1.1
Done
context canceled

clent log empty and connection reset

$ echo $?
4

man wget  (4 = Network failure.)

ok, I do (file size 1MB)

$ wget -t1 -qSO - --method=PUT --body-file=1MB.mp3 'http://localhost:8888/'

client log now

  HTTP/1.1 413 Request Entity Too Large
  Server: foo/1.0
  Date: Sat, 09 Sep 2023 07:44:06 GMT
  Content-Length: 0

What did you expect to see?
expected behavior, client receives response
What did you see instead?
client does not receive a response, and connection is closed

Additionally, when using encryption and HTTP 2, the error does not recur; it seems that the context is canceled due to a timeout and the client does not have time to read the response when the header Content-Length contains a sufficiently large value. And, if the request is made from the browser, the browser sends another repeat request

you're not reading the body
Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.
For questions please refer to https://github.com/golang/go/wiki/Questions

I am reporting an BUG, this is the most simplified version, I have no right to provide you with the source code of the project. behavior does not depend on reading the body. so that the answer is that the body is too large, should the entire body of size 100500 GB be read? in addition, when using HTTP 2 this bug is not observed
just repeat this test and everything will become clear if the text does not describe it clearly

https://datatracker.ietf.org/doc/html/rfc9110#name-413-content-too-large

15.5.14. 413 Content Too Large
The 413 (Content Too Large) status code indicates that the server is refusing to process a request because the request content is larger than the server is willing or able to process. The server MAY terminate the request, if the protocol version in use allows it; otherwise, the server MAY close the connection. If the condition is temporary, the server SHOULD generate a Retry-After header field to indicate that it is temporary and after what time the client MAY try again.

and with this bug there is no way to transfer any information to the client, he believes that the error is network and can repeat requests endlessly

@libjs your handler still needs to be correct, that is handle the body data.

@libjs your handler still needs to be correct, that is handle the body data.

no, it shouldn't process the body if it's too big, especially if it's known from the header Content-Type for example

and this is not my handler, this is a test that you can easily repeat by adding anything, the result will be the same, I spent a week on this bug

I repeat once again, to save resources, if after receiving the headers or in the process of reading the body, there is a need to respond to the client, then this is impossible without finishing reading the body, which can be very large

and everything would be solved by using HTTP 2, but proxies use HTTP 1.1, it is this fact that breaks the ability to respond to the client

in fact, this bug is a vulnerability, if you force the developer to read the entire body to be able to correctly complete the request, then it is easy to carry out a DDOS attack on such a server, sending it a body with the maximum possible body size, and this takes up at least network resources

your client is closing the connection before the response can be written because you've filled up whatever buffers there may be. there's nothing the server can do.

your client is closing the connection before the response can be written because you've filled up whatever buffers there may be. there's nothing the server can do.

It’s not my client that does this, it’s the server that closes the connection and this happens to any client, use any browser
I have my own implementation of the HTTP protocol for Golang, and it has been used in production for more than 5 years, working with 500k+ persistent connections, I personally know how to solve this problem without using the native HTTP module, I’m just checking whether Golang developers can solve this problem

Just answer, what do you need to understand the problem? I'll provide everything

see https://pkg.go.dev/net/http#ResponseController.EnableFullDuplex

see https://pkg.go.dev/net/http#ResponseController.EnableFullDuplex

tnx, im test it. and let you know the result

see https://pkg.go.dev/net/http#ResponseController.EnableFullDuplex

sorry, its not working

package main

import (
   "fmt"
   "net/http"
)

// wget -t1 -qSO - --method=PUT --body-file=video.mp4 'http://localhost:8888/'

type handler struct {
}

func (h *handler) ServeHTTP (w http.ResponseWriter, r *http.Request) {
   rc := http.NewResponseController(w)
   log(rc.EnableFullDuplex())
   go func() {
      ctx := r.Context()
      <- ctx.Done()
      log(ctx.Err())
   }()
   log(r.Method + " " + r.RequestURI + " " + r.Proto)
   d := w.Header()
   d.Set("Server", "foo/1.0")
   if origin := r.Header.Get("Origin"); "" != origin {
      d.Set("Access-Control-Allow-Origin", origin)
   }
   switch r.Method {
   case "PUT":
      w.WriteHeader(http.StatusRequestEntityTooLarge)
   case "OPTIONS":
      d.Set("Access-Control-Allow-Methods", "OPTIONS, GET, HEAD, PUT, DELETE")
      d.Set("Access-Control-Allow-Headers", "Content-Type")
      d.Set("Access-Control-Allow-Max-Age", "86400")
      d.Set("Access-Control-Allow-Credentials", "true")
      w.WriteHeader(http.StatusNoContent)
   }
   log("Done")
}

func log (i any) {
   fmt.Printf("%v\n", i)
}

func main () {
   srv := &http.Server{
      Addr: ":8888",
      Handler: &handler{},
   }
   log(srv.ListenAndServe())
}

server log

PUT / HTTP/1.1
Done
context canceled

and client dont receive response

if add at end of ServeHTTP

rc.Flush()

its not working too

it still looks like a client error: https://go.dev/play/p/NZ3b61LjNMr

it still looks like a client error: https://go.dev/play/p/NZ3b61LjNMr

wow! good test, but it's more likely a server error

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [IO wait]:
internal/poll.runtime_pollWait(0x7f0abe264ea0, 0x72)
	/usr/local/go-faketime/src/runtime/netpoll.go:343 +0x85
internal/poll.(*pollDesc).wait(0xc00012c000?, 0x4?, 0x0)
	/usr/local/go-faketime/src/internal/poll/fd_poll_runtime.go:84 +0x27
internal/poll.(*pollDesc).waitRead(...)
	/usr/local/go-faketime/src/internal/poll/fd_poll_runtime.go:89
internal/poll.(*FD).Accept(0xc00012c000)
	/usr/local/go-faketime/src/internal/poll/fd_unix.go:611 +0x2ac
net.(*netFD).accept(0xc00012c000)
	/usr/local/go-faketime/src/net/fd_unix.go:172 +0x29
net.(*TCPListener).accept(0xc0000680e0)
	/usr/local/go-faketime/src/net/tcpsock_posix.go:152 +0x1e
net.(*TCPListener).Accept(0xc0000680e0)
	/usr/local/go-faketime/src/net/tcpsock.go:315 +0x30
net/http.(*Server).Serve(0xc000128000, {0x731c40, 0xc0000680e0})
	/usr/local/go-faketime/src/net/http/server.go:3056 +0x364
net/http.(*Server).ListenAndServe(0xc000128000)
	/usr/local/go-faketime/src/net/http/server.go:2985 +0x71
main.main()
	/tmp/sandbox1756637940/prog.go:61 +0x65

you can use netclobber to make sure, and also, we won’t rewrite all browsers to create a perfect server

that's just there's else to run in the playground

ok, need to add wireshark log for browser request?

just add size to body https://go.dev/play/p/T_d-FcSNk-U
its not size, timeout, in playground need more octets

even such a server can respond to requests from any clients with any body size

#!/bin/sh

while true; do
   printf 'HTTP/1.1 413 Request Entity Too Large\r\nServer: foo/1.0\r\nContent-Length: 0\r\n\r\n' \
   | nc -q-1 -vvlp 8888 | sed -n '1,9 p'
done

I can't help you fix this bug until you recognize it as a bug) the issue status is expected to change

@libjs Did you manage to solve your problem? I encountered the same issue.

@libjs Did you manage to solve your problem? I encountered the same issue.

Денис, в треде написал как решить, использовать HTTP/2.0. Но это не решение бага в гошке, а обход проблемы.


Crash in BondSplicer Splice

Describe your environment.
SDK Version: <IP_ADDRESS>
Platform: Windows
OS Version: 10.0.22631.3296
Steps to reproduce.
We don't have exact steps to reproduce, only stack traces
What is the expected behavior?
Not to crash
What is the actual behavior?
Random crashes,

Checking the value of the internal arrays

m_buffer has a length of 298643 bytes

The content of the packages would read beyond its length and crash.
writer.WriteBlob(m_buffer.data() + 298643, 7345).
Additional context.
N/A

This was discussed in the last community meeting.  While the crash occurs during event encoding, as the library attempts to read beyond the allocated package size, but nothing wrong is seen by reviewing the relevant code. If the crash is consistently reproducible, please provide the exact steps to reproduce it or share the sample code that only depends on the 1ds-cpp-sdk.


Can't re-connect after error with OkHttp lib

OkHttp websocket ERROR event means that socket is closed and no further calls to listener will be made. However, next piece of code only notifies the client that connection is closed when CLOSE event is received.
    void emitLifecycleEvent(@NonNull LifecycleEvent lifecycleEvent) {
        Log.d(TAG, "Emit lifecycle event: " + lifecycleEvent.getType().name());
        mLifecycleStream.onNext(lifecycleEvent);
        if (lifecycleEvent.getType().equals(LifecycleEvent.Type.CLOSED))
            mConnectionStream.onNext(false);
    }

As a result we get "Attempted to connect when already connected" when socket is actually closed.

I'll create a PR with fast fix but I won't be able to test right now. @forresthopkinsa Please, take a look and test if you can.

Absolutely, I'll check it out when I get to work in about an hour.

You're totally right. With JWS, messages can still be sent after an Error event, whereas with OkHttp, a Failure is a combination of an Error and a Close. The code should definitely reflect that.

Thanks a lot for fixing this one! Unfortunately, I've found another issue after this one was fixed. I'll report it separately.

Hi,
I faced the reconnect problem after n/w disconnet/connect in the upstream project. i put my issue in there [ref: https://github.com/NaikSoftware/StompProtocolAndroid/issues/87] where i saw the same discussion and came to this downstream project.
I tried with 17.11.0 version but still facing the same reconnect problem.
Is it the proper version to be checked or I am missing something.

@souravbasu14 That fix wasn't included in the 17.11.0 release. It was released a day later, and it's scheduled to be included in 17.12.0. You can, however, use a non-release version, like so:
dependencies {
    compile 'com.github.forresthopkinsa:StompProtocolAndroid:965f1275ad'
}

@forresthopkinsa I did a quick verification with the non rel version. Below are my steps and observations:

Once the network is disconnected, I am getting ERROR state. From there I called reconnect().
On network connection, stompclient is getting connected and i receive OPEN state.
Old subscribes  topics were not restored. No data is coming after reconnect
After step 2, OPEN and ERROR goes into a loop. After ~1min interval i get a ERROR state though my network doesn't change. And as per Step 1, i called reconnect(). So i get OPEN state. Also previous subscribes topics are not restored.

Also observed a crash which leads the app to crash. it happened from onError from Subscription subscribe(final Action0 onComplete) function in Completable.java. Attached is the crashlog which i received in crashlytics.
crash.txt


Filter Migration unindexed docs page

Description of the change:
Reason for the change:
Link to original source:

Closes #

Hello @Whatthefoxsays,Thanks again for the PR! We appreciate your contribution and look forward to                                              continued collaboration. Thanks!                                             Team SendGrid DX


integ test: Decrease ipv6 iface mtu to lower then min

New test aimed to check that mtu value cannot be decreased lower than
1280

Coverage remained the same at 72.021% when pulling a94df850fe2549ffb52012019f5c76f5dd25f2b2 on SvetaHBar:mtu_eth_tests into fcb704b96c68b530c77e99b56c55968405c77586 on nmstate:master.


Transaction not verified in wallet, but balance appears

I have version 1.0.4 installed and transferred ZCL to my wallet yesterday. As of today, the funds are still not verified. However, the balance is showing. Block explorer shows confirmations. Do these transactions need to be verified for the fork? Any help is appreciated. Thank you!

Figured it out thanks to Bitcoin private support chat: https://support.btcprivate.org/464851-Transactions-Are-Unconfirmed-For-HoursDays

Hello,
I have ZClassic electrum wallet Z_1.0.3 installed and I transferred ZCL to my wallet, the balance shows that i have my coins and everything but it keeps on saying unverified! I tried to use block explorer to see confirmations but the page is not loading!
Please help me with this regards, and show me how to verify my transactions because i have 1 deposit and 1 withdrawal transactions that are both unverified!
Thank you very much in advance.

Hi,
I'm not sure if you should upgrade to the latest version of the electrum wallet - I'm using 1.0.4. I followed the instructions from the link above and everything worked out fine. Perhaps you can visit this link and chat with support: https://support.btcprivate.org/

Hi ya,
Thank you very much for your support dude, I used the link you shared and I waited for the blocks to sync and once they did all my unverified transactions are now verified!