[mesh] v4.4 MTXON task corrupting heap (IDFGH-9664)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
v4.4.4-116-g00bb43ff24
Operating System used.
Windows
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
PowerShell
Development Kit.
ESP32S3-WROOM N8R2
Power Supply used.
USB
What is the expected behavior?
As reported in
https://github.com/espressif/esp-idf/issues/10992
we are investigating crashes that happen to our devices.
We managed to reduce the triggering conditions to the following:

have 2 mesh devices connecting to MQTT with dynamic settings

Disable all watchdogs, cores + interrupts

make the child device send 1 packet per second with 1024 payload

reset the root

the child device will crash

We enabled comprehensive HEAP tracing

We added a piece of code in heap_caps that logs each time a malloc/free is made

After multiple retries, we see that the address that is corrupted is touched mainly by MTXON

We isolated the logs to MTXON mallocs.

Please note that we don't know what other tasks MTXON works with, so there might be FREEs that are allocated by other tasks (maybe TCPIP)!
Here is the result:

W (16:07:12.957) mesh_main: <MESH_EVENT_TODS_REACHABLE>reachable:1
I (16:07:12.964) mesh_main: <MESH_EVENT_ROOT_ADDRESS>root address:7c:df:a1:e0:8b:7d
I (16:07:12.973) offline: object saved to PSRAM, free 490247
I (16:07:13.933) esp_netif_handlers: sta ip: <IP_ADDRESS>, mask: <IP_ADDRESS>, gw: <IP_ADDRESS>
W (16:07:13.934) network: GOT IP from sta
I (16:07:13.938) mesh_netif: Interface AP
I (16:07:13.946) network: Network connected
I (16:07:13.948) mqtt_app: MQTT_EVENT_BEFORE_CONNECT
I (16:07:13.953) mqtt_app: Try [1] connection to mqtts://mqtt-stg.tiko.energy:8883
I (40932) wifi:<ba-add>idx:0 (ifx:0, d6:92:7d:c3:02:1e), tid:0, ssn:3, winSize:64
CORRUPT HEAP: Invalid data at 0x3dea2214. Expected 0xfefefefe got 0x0048fefe
CORRUPT HEAP: Invalid data at 0x3dea2218.  Expected 0xfefefefe got 0x008cfefe
	Line    3: CORRUPT HEAP: Invalid data at 0x3de9e134.
I usually:

enable corruption detection
add lots of calls to heap_caps_check_integrity()
start commenting out code until I know which code is causing the corruption

Perhaps you can try this approach to narrow things down further.

That's an interest approach to debugging heap corruption.
I usually:
* enable corruption detection

* add lots of calls to heap_caps_check_integrity()

* start commenting out code until I know which code is causing the corruption

Perhaps you can try this approach to narrow things down further.

we'll refine our investigation on this once we have more resources available.
Problem is, the mesh code is closed sourced and all our done steps lead to those modules.
On top, there are pending changes to the mesh library following our highest priority ticket,
https://github.com/espressif/esp-idf/issues/9955

@KonssnoK Can you provide a demo to reproduce this issue?

the more the devices, the easier the crash
example:
device_7.txt
device_13.txt
device_5.txt
I don't know why but in these logs the names of the tasks are wrong, in the terminal they are displayed correctly :)

just to complete the reporting, apparently it's possible to trigger more heap corruption crashes by simply enabling comprehensive heap poisoning in the example
https://github.com/KonssnoK/esp-idf/tree/bug/mesh_wifi/examples/mesh/ip_internal_network
used for
https://github.com/espressif/esp-idf/issues/9955
One way to make the child device crash is to keep the hotspot off apparently

@zhangyanjiaoesp can you give us an update?
are you able to reproduce the issue? thanks :)

@KonssnoK Yes, I can reproduce this issue according to your branch. And I'm debugging on it.
(By the way, the changes in mesh lib has been merged into v4.4, 90d6e45d9ffc6c060d664d50063fe05c712d3042)

@zRedShift are you using a mesh network or simple wifi?
In our case it's likely an interaction between tcpip task and the MTXON task, which is part of the mesh library.
More generally speaking, it seems that in general this is happening when someone writes in a already released TCP packet.

@zRedShift we also use mbedtls, but our setup is using the wifi mesh environment. BLE is off for us after provisioning.
When i have some time i'll try to understand if i can do some tests to see if the issue is in an open part of the code.
The possible involved modules i see are:

lwip tcpip
mbedtls
wifi stack -> not debuggable

@KonssnoK I'm still debugging on this issue, will feedback to you ASAP when I find the root cause.

@zhangyanjiaoesp did you manage to understand which component is triggering it?
if it's an open sourced one we can focus on it too.

@KonssnoK
Please use the new wifi lib to test, the corrupt issue has been solved on my side.
wifi_lib_0404.zip
wifi firmware version: 7fec53d
If your test is passed,  then we will merged the fix into release/v4.4 ASAP.

thanks @zhangyanjiaoesp , we'll test asap

just a question, what is it built on top of?
15b1309726f600122b5d4539e73758ae1852168d ?

@KonssnoK The wifi lib is base on your branch https://github.com/KonssnoK/esp-idf/tree/bug/mtxon-heap-corruption/examples/mesh/ip_internal_network, and it contains all the fixes from https://github.com/espressif/esp-idf/issues/9955.
If you want to update your release/v4.4 version, you can base on https://github.com/espressif/esp-idf/commit/90d6e45d9ffc6c060d664d50063fe05c712d3042.

@zhangyanjiaoesp we saw there were additional fixes to the wifi library, so we are currently aiming at
4c7d97e2bdbd26b1ad6adc6de8051888e1feec10
First though, let's check if everything is ok with the current branch

@zhangyanjiaoesp we continue to test but currently you have the green light for merging, we are not able to reproduce the issue with the same examples. Thanks :)

Would this fix affect v5.x versions of esp-idf? And is there a possibility that it solves a non-mesh related esp-wifi bug I mentioned here: https://github.com/espressif/esp-idf/issues/11006#issuecomment-1487529101?

Would this fix affect v5.x versions of esp-idf? And is there a possibility that it solves a non-mesh related esp-wifi bug I mentioned here: #11006 (comment)?

these fixes are usually backported everywhere (still maintained), so it will be pushed also to 5.0 for sure.
The 4.4 push is focused just because our product line works on v4.4 :)

@zhangyanjiaoesp we were able to reproduce again one crash,
we'll try now to isolate and reproduce
W (10:10:57.634) stats: iteration_time_us=1000004 Name=last% IDLE=40 IDLE=63 task_mesh_rx=1 tiT=4 ipc1=24 wifi=5 updater=56 MTXON=1
Guru Meditation Error: Core  1 panic'ed (StoreProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x40389eb2  PS      : 0x00060e33  A0      : 0x8038a678  A1      : 0x3fcb7370
0x40389eb2: remove_free_block at C:/repos/v3/esp-idf/components/heap/heap_tlsf.c:207
 (inlined by) block_locate_free at C:/repos/v3/esp-idf/components/heap/heap_tlsf.c:442
 (inlined by) tlsf_malloc at C:/repos/v3/esp-idf/components/heap/heap_tlsf.c:849

A2      : 0x3d800014  A3      : 0x0000010c  A4      : 0x3d896e6c  A5      : 0x3d8a8dd4
A6      : 0x3d8112c4  A7      : 0x3d8a8d44  A8      : 0x3d8a8e24  A9      : 0x00000013
A10     : 0x964c06f3  A11     : 0x00000004  A12     : 0xfffffffc  A13     : 0x00007001
A14     : 0x00060e20  A15     : 0x00000001  SAR     : 0x0000001d  EXCCAUSE: 0x0000001d
EXCVADDR: 0x0000700d  LBEG    : 0x400570e8  LEND    : 0x400570f3  LCOUNT  : 0x00000000

Backtrace: 0x40389eaf:0x3fcb7370 0x4038a675:0x3fcb7390 0x40376709:0x3fcb73b0 0x4037685b:0x3fcb73d0 0x403763f9:0x3fcb7420 0x421156f7:0x3fcb7440 0x42115754:0x3fcb7460 0x42116215:0x3fcb7480 0x4038b149:0x3fcb7640 0x4038b235:0x3fcb7690 0x4003f4bd:0x3fcb76b0 |<-CORRUPTED
0x40389eaf: remove_free_block at C:/repos/v3/esp-idf/components/heap/heap_tlsf.c:206
 (inlined by) block_locate_free at C:/repos/v3/esp-idf/components/heap/heap_tlsf.c:442
 (inlined by) tlsf_malloc at C:/repos/v3/esp-idf/components/heap/heap_tlsf.c:849

0x4038a675: multi_heap_malloc_impl at C:/repos/v3/esp-idf/components/heap/multi_heap.c:187

0x40376709: heap_caps_malloc_base at C:/repos/v3/esp-idf/components/heap/heap_caps.c:175

0x4037685b: heap_caps_malloc_prefer at C:/repos/v3/esp-idf/components/heap/heap_caps.c:290

0x403763f9: wifi_malloc at C:/repos/v3/esp-idf/components/esp_wifi/esp32s3/esp_adapter.c:71

0x421156f7: mesh_malloc at ??:?

0x42115754: esp_mesh_create_context at ??:?

0x42116215: esp_mesh_wifi_recv_cb at ??:?

0x4038b149: sta_input at ??:?

0x4038b235: sta_rx_cb at ??:?

device_7440_press.zip
@zhangyanjiaoesp @mhdong here are the logs

Generically speaking the stability of the system has improved thousands of folds.
We still get some crashes, which seem very similar to what was happening before.
@zhangyanjiaoesp maybe you can check for similar code (to the one you fixed) in the libraries?
To trigger them, instead of doing high traffic, we do parallel firmware updates.

3 devices
trigger a firmware update on all 3 devices at the same time

Here an example :
	Line 1609: CORRUPT HEAP: Invalid data at 0x3dea2dbc.
This way we can check also latest fixes on the field, since we have devices isolating themselves (still investigating on why)

@KonssnoK
the wifi lib based on https://github.com/espressif/esp-idf/commit/4c7d97e2bdbd26b1ad6adc6de8051888e1feec10 is here:
wifi_lib_0406.zip
wifi firmware version: 85cf6e5

To trigger them, instead of doing high traffic, we do parallel firmware updates.
3 devices
trigger a firmware update on all 3 devices at the same time
be lucky ( 100 ) ... triggering crashes is now quite difficult. We are investigating in order to replicate these crashes.
This issue is still debugging.

@zRedShift
Since your issue is not related to wifi mesh, please create a new ticket to report your issue

@KonssnoK the wifi lib based on 4c7d97e is here: wifi_lib_0406.zip wifi firmware version: 85cf6e5

To trigger them, instead of doing high traffic, we do parallel firmware updates.
3 devices
trigger a firmware update on all 3 devices at the same time
be lucky ( 100 ) ... triggering crashes is now quite difficult. We are investigating in order to replicate these crashes.

This issue is still debugging.

meaning you were able to replicate some other crashes?
We are still trying to understand how to trigger them.
The new library much more stable!

@KonssnoK No, I didn't  reproduce any crash issue, just look at your logs for some ideas.  If you find a good way to reproduce the problem, it will speed up the debug process.

@KonssnoK  Since the fix has solved the original crash issue, and the new crash issue is hard to reproduce, we will merge the fix into release/v4.4 firstly. Is it OK?

@zhangyanjiaoesp that would be great, so we can move inside esp-idf without having to change wifi-lib

i will close this ticket and open a new one when we manage to replicate other crashes


Build CD/CI pipeline

Needs to build CD/CI

Travis configuration is added to the project. Once a set of tests are included we can add more structure to the pipeline.

Lest close it?


important questions about the operator and the plugin

Hello, Some things are not well documented so I have a couple of questions which I believe will help everyone.

The latest version of hlf plugin is the 1.6.4 while of the operator (in helm charts) is the 1.6.1. Are these two version compatible? Is there any strict relation between the versions of the plugin and operator?
If I clone the main repository I assume that the uploaded operator is fully compatible with the corresponding  uploaded plugin. I know how to build the plugin but how can I build the operator and how can I apply it to my k8s cluster without using the common helm install hlf-operator -f values.yaml --version=1.6.1 kfs/hlf-operator command
I had been using version 1.5.1 for both operator and plugin and the images versions of peer and orderer were

export PEER_IMAGE=quay.io/kfsoftware/fabric-peer
export PEER_VERSION=2.3.2-v0
export ORDERER_IMAGE=hyperledger/fabric-orderer
export ORDERER_VERSION=2.3.2

The network was perfect. Now I have to jump to latest version of plugin and operator but I want to use the same version of peers and orderer. However, when I am running kubectl hlf chaincode install --path=./chaincodes/fabcar/go --config=org1.yaml --language=golang --label=fabcar --user=$ORG1_ADMIN_USER --peer=org1-peer0.default &  I am getting the error: could not build chaincode: docker build failed: docker build is disabled . Same for version 2.4.3. Should I deploy the chaincode only as a service?
4. Whenever the chaincode is installed as a service where is the folder with the code (needed to be build) of the chaincode?
5. What is the difference between the plugins commands channel create and generate?
6. In the latest version if I use kubectl hlf channel generate --output=ch2.block --name=ch2 --organizations Org1MSP,Org2MSP,Org3MSP --ordererOrganizations OrdererMSP --consenterNodes ordnode-2  only the ordnode-2 will be used as consenter is the new channel. Correct? If yes, I have not to run kubectl hlf channel consenter add  and kubectl hlf channel update commands afterward.

Version of HLF helm chart is compatible, since there's no change in the CRDs
The helm chart in this repo for the operator is outdated, it must be removed in the next version
For the new version, I recommend you to use the latest version for fabric-peer, since the latest instructions are aligned with the chaincode as an external service, which is the recommended and since Hyperledger Fabric 2.4

@nkaramolegos  for more info, could you join the Hyperledger discord and we can comment in the hlf-operator channel? This way we can have faster conversations and responses
https://discord.com/channels/905194001349627914/967823782712594442

I would like to use plugin version 1.6.4 with the operator 1.6.1 which are compatible as you said with the 2.3.2 version of peer and orderer and without chaincode as a service. But whenever I run kubectl hlf chaincode install --path=./chaincodes/fabcar/go --config=org1.yaml --language=golang --label=fabcar --user=$ORG1_ADMIN_USER --peer=org1-peer0.default I get  could not build chaincode: docker build failed: docker build is disabled. Why that? Note that I can use the hlf version 1.5.1 with the 2.4.1 peer and orderer images without deploying CaaS.

I would like to use plugin version 1.6.4 with the operator 1.6.1 which are compatible as you said with the 2.3.2 version of peer and orderer and without chaincode as a service. But whenever I run kubectl hlf chaincode install --path=./chaincodes/fabcar/go --config=org1.yaml --language=golang --label=fabcar --user=$ORG1_ADMIN_USER --peer=org1-peer0.default I get could not build chaincode: docker build failed: docker build is disabled. Why that? Note that I can use the hlf version 1.5.1 with the 2.4.1 peer and orderer images without deploying CaaS.

https://stackoverflow.com/questions/73100516/docker-build-is-disabled-error-when-installing-my-chaincode-on-hyperledger-fabri/73153204#73153204


How to perform ntlm authentication when using alpine as base image?

Hello,
We have followed the steps suggested here but, nothing is working. We are trying to run the application in Azure AKS. Any suggestions please
Code
               var cred= new CredentialCache();
                cred.Add(new Uri("url"), "NTLM", new NetworkCredential("user", "pwd", "***.com"));

                var hwd= new HttpClientHandler() { Credentials = credentialsCache, PreAuthenticate = true };

                hwd.ClientCertificateOptions = ClientCertificateOption.Manual;
                hwd.ServerCertificateCustomValidationCallback =
                    (httpRequestMessage, cert, cetChain, policyErrors) => true;
                hwd.UseDefaultCredentials = false;

                var client = new FlurlClient(new HttpClient(hwd) { Timeout = new TimeSpan(0, 0, 30) };);
                 var response = await request
                    .AllowHttpStatus(HttpStatusCode.NotFound)
                    .WithHeader("Accept", "application/json")
                    .WithClient(client)
                    .WithHeader("Content-Type", "application/json; charset=utf-8")
                    .GetAsync();

Exception
Flurl.Http.FlurlHttpException: Call failed. NTLM authentication is not possible with default credentials on this platform:
System.PlatformNotSupportedException: NTLM authentication is not possible with default credentials on this platform. at

POD base image

NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.16.3
PRETTY_NAME="Alpine Linux v3.16"

dotnet version:- 6.0.14

Hey @Maoni0 @richlander, sorry for tagging you directly. If possible could you please help us here. Our production environment is impacted because of this issue. Would be grateful for help and support.

@mangod9 do you know who might be able to help with this?

Looks to be related to this issue: https://github.com/dotnet/runtime/issues/66633. Might make sense to discuss on that issue.

Thank you so much @Maoni0 @mangod9
We entered into a war room yesterday for 7 hours but unable to figure out anything. As a backup plan we can only change the base image from alpine to someone else. But, it requires approvals and lots  of changes in our ci/cd pipelines.
Once you have any updates please let me know. Really appreciate. Have a great weekend.


Annotate openjdk images with EOL date

This change adds the ability to annotate the current image with an EOL (end of life) date prior to building and deploying the latest image. The EOL (end of life) date is the date when new images are built and pushed.
A new parameter is also added to indicate when an image to be deployed is "new" or not. If this is the case, then we do not need to annotate any previous image since there would be none.
I also co-located the various sh scripts into a scripts folder. This should cut down on bash written in YAML and make the YAML more readable and maintainable.

@jmjaffe37 and @Luigi96 can I get another round of reviews on this? Thanks.
I added some extra params and made style changes that @jmjaffe37 wanted.


Update windows-sys.

Release notes: https://github.com/microsoft/windows-rs/releases/tag/0.59.0

Should probably coordinate with Tokio on this.
/cc @Darksonn

Yes. I don't think we need to force people to only use Tokio/mio combinations with the same windows-sys, but we should also update it in Tokio.

@westy92 are you running the tests locally? Or only using the CI for testing?

@Thomasdezeeuw tests are passing on my Mac, but I am unable to test on Windows.

Since this is failing the CI and no progress has been made to fix it I'm going to close this.


[luajit] add 2.1.0-beta3

Library name: luajit
New version number: 2.1.0-beta3
Many people are using the v2.1 branch of https://github.com/LuaJIT/LuaJIT and it would be useful to have that as an option, even if it's not the default

@Wires7,  Our policy does not allow port to be upgraded to beta version, I will wait for the 2.1.0 stable version to be released and continue to upgrade to the latest version and then merge pr

@JonLiu1993 This beta has been out for 5 years now, so I'm not hopeful for a timely stable version to be released.  I understand that you have to tie the vcpkg version to a git hash, though.  Is there another workaround besides creating my own port file or using your PR branch?

@JonLiu1993 This beta has been out for 5 years now, so I'm not hopeful for a timely stable version to be released. I understand that you have to tie the vcpkg version to a git hash, though. Is there another workaround besides creating my own port file or using your PR branch?

If you want to use this beta, just use my pr, you can also ask upstream if they will release the latest version soon, because I found that they are still submitting pr upstream to solve the problem recently


Add script to generate output files

This adds a shell script which can be used both locally and on CI to download external files and process them and the input files in this repository to generate the Turtle files to be loaded onto the database.

Example execution
$ scripts/generate.sh
== CN_2024.rdf.zip ==
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 15.4M  100 15.4M    0     0  1192k      0  0:00:13  0:00:13 --:--:-- 3003k
Archive:  CN_2024.rdf.zip
== combined_nomenclature ==
2024-10-09 12:28:09.462 | INFO     | __main__:CN2024:17 - Reading input RDF file /home/bbguimaraes/dds/src/cauldron/sentier_vocab/sentier_vocab/CN_2024.rdf
2024-10-09 12:29:08.649 | INFO     | __main__:CN2024:20 - Changing labels to remove notation
2024-10-09 12:29:39.224 | INFO     | sentier_vocab.open_energy_ontology:__init__:58 - Parsing and creating Open Energy Ontology elements
2024-10-09 12:29:39.631 | INFO     | sentier_vocab.utils:streaming_download:70 - Downloading oeo-2.5.0.zip to /home/bbguimaraes/.local/share/sentier.dev/oeo-2.5.0.zip
2024-10-09 12:29:41.234 | INFO     | __main__:CN2024:28 - Creating reciprocal relations
2024-10-09 12:29:42.822 | INFO     | __main__:CN2024:34 - Writing output TTL file sentier_vocab/CN_2024.ttl
== custom_products ==
2024-10-09 12:30:27.756 | INFO     | __main__:<module>:24 - Created custom graph at /home/bbguimaraes/dds/src/cauldron/sentier_vocab/sentier_vocab/data/custom-products.ttl
== envo ==
<frozen runpy>:128: RuntimeWarning: 'sentier_vocab.envo' found in sys.modules after import of package 'sentier_vocab', but prior to execution of 'sentier_vocab.envo'; this may result in unpredictable behaviour
== model_terms ==
2024-10-09 12:30:33.778 | INFO     | __main__:ModelTerms:11 - Reading input TTL file /home/bbguimaraes/dds/src/cauldron/sentier_vocab/sentier_vocab/data/model-terms.ttl
2024-10-09 12:30:33.788 | INFO     | __main__:ModelTerms:13 - Creating reciprocal relations
2024-10-09 12:30:33.789 | INFO     | __main__:ModelTerms:19 - Writing output TTL file /home/bbguimaraes/dds/src/cauldron/sentier_vocab/sentier_vocab/data/model-terms.reciprocal.ttl
== nace ==
2024-10-09 12:30:33.988 | INFO     | __main__:CN2024:17 - Reading input RDF file /home/bbguimaraes/dds/src/cauldron/sentier_vocab/sentier_vocab/CN_2024.rdf
2024-10-09 12:31:37.455 | INFO     | __main__:CN2024:20 - Changing labels to remove notation
2024-10-09 12:32:06.639 | INFO     | sentier_vocab.open_energy_ontology:__init__:58 - Parsing and creating Open Energy Ontology elements
2024-10-09 12:32:07.808 | INFO     | sentier_vocab.utils:streaming_download:70 - Downloading oeo-2.5.0.zip to /home/bbguimaraes/.local/share/sentier.dev/oeo-2.5.0.zip
2024-10-09 12:32:09.440 | INFO     | __main__:CN2024:28 - Creating reciprocal relations
2024-10-09 12:32:11.052 | INFO     | __main__:CN2024:34 - Writing output TTL file sentier_vocab/CN_2024.ttl
== open_energy_ontology ==
2024-10-09 12:32:55.795 | INFO     | __main__:__init__:58 - Parsing and creating Open Energy Ontology elements
2024-10-09 12:32:56.211 | INFO     | sentier_vocab.utils:streaming_download:70 - Downloading oeo-2.5.0.zip to /home/bbguimaraes/.local/share/sentier.dev/oeo-2.5.0.zip
== qudt ==
<frozen runpy>:128: RuntimeWarning: 'sentier_vocab.qudt' found in sys.modules after import of package 'sentier_vocab', but prior to execution of 'sentier_vocab.qudt'; this may result in unpredictable behaviour
2024-10-09 12:32:58.947 | INFO     | sentier_vocab.utils:streaming_download:70 - Downloading qudt-qudt-public-repo-v2.1.43-0-g4d44787.zip to /home/bbguimaraes/.local/share/sentier.dev/qudt-qudt-public-repo-v2.1.43-0-g4d44787.zip
== supplements ==
$ git status --short
?? CN_2024.rdf
?? CN_2024.rdf.zip
?? cookies.txt
?? envo-sentier-dev.ttl
?? qudt.json
?? sentier_vocab/CN_2024.ttl
?? sentier_vocab/data/oeo-product-vocab.ttl

One thing I'm not sure about yet is some steps seem to have the same output file (e.g. combined_nomenclature and nace both say Writing output TTL file sentier_vocab/CN_2024.ttl). Is there a specific order of execution required?

Part of https://github.com/sentier-dev/sentier_vocab/issues/9.

Fixed a typo in the comments.

We can merge this one, and move to the next step of #9 in another one


Decoder instances for String and Long

The Decoder instances for String and Long are defined as defs.
Shouldn't these be defined as vals?

So the instance for Long can be defined as a val.
The String instance is being used in DecoderLowPriority3 (changing to a val throws a class initialization error at runtime).
This instance would have to be defined as a lazy val.
Alternatively, such dependencies could be eliminated with a method like
object JsonDecoder.{
  def mapStringOrFail[A](f: String => Either[String, A]): JsonDecoder[A] = ???
}


Rolling back uncommitted entries in FasterLog

I'm currently evaluating Faster for use as a backend for a distributed system synchronized using raft. Is it currently possible to rollback uncommitted entries from FasterLog ?

Short answer is no, see #461.


Pinpoint：About link，I want to change the number color ? As Shown.

dear team!
Pinpoint：About link，I want to change the number color ? As Shown.

My version is 1.6.0v


How to exclude multiple subdomains from being archived?

I am archiving a site that has many dead subdomains. Those subdomains used to be something like media.example.com, but many of them aren't really used anymore. My problem is that this script can easily exclude one subdomain (ex. api.example.com) but using regex to exclude them (ex. (media|api|arhive).example.com) doesn't work. Is there any way to exclude multiple subdomains at once? If there isn't, could it be implemented?

Hi,
excluding several subdomains works fine on my side.
I've been using extensive subdomain filtering over the last year, for example:
'(id-neu|service|stellenmarkt|immobilien|produkte|zeitung|trauer|auto|flirt).schwarzwaelder-bote.de|(registrations|suche)\?'

As long as it is a valid regex it seems to work.
Here are some things you could check and consider that may help you solve the issue:

If you entered the regex in the command line argument, maybe your shell swallowed special characters? You can check in the exclude_pattern.txt file if the regex is correct, and even modify it there on the fly.
Verify the regex with the url it should filter on a site like https://regex101.com/
Once a page has entered the index.txt, it is not filtered anymore, even if you adjust the regex. Filtering only happens when discovering outlinks.

Good luck.

Once a page has entered the index.txt, it is not filtered anymore, even if you adjust the regex. Filtering only happens when discovering outlinks.

Thanks! This was the issue. I got flooded with thousand of links from certain subdomain, but I didn't know that the links from index.txt are not filtered again.


Time span settings parsing

Adds tests to verify timespan field parsing correctness for the issue reported in #159

[x] Add a Utility class for building test configs
[x] Add tests for all 4 TimeSpan fields

@reviewbybees

CC @pkeusem and @jriffel
The tests pass correctly on my machine and the PR builder.
Could you please provide your configs in #159 ?

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

Merging since I want to deliver another fix on the top of the test framework
@reviewbybees done (I've tried to get reviews)


Add Arrow DST tests based on two false positives

Pull Request Checklist
Thank you for taking the time to improve Arrow! Before submitting your pull request, please check all appropriate boxes:

[ ] 🧪 Added tests for changed code.
[ ] 🛠 All tests pass when run locally (run tox or make test to find out!).
[ ] 📚 Updated documentation for changed code.
[ ] ⏩ Code is up-to-date with the master branch.

If you have any questions about your code changes or any of the points above, please submit your questions along with the pull request and we will try our best to help!
Description of Changes
Added comments explaining the new tests and referenced the correct issues.
Replaces #732
Closes #376
Closes #551

Codecov Report

Merging #747 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #747   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           9      9
  Lines        1669   1669
  Branches      282    282
=====================================
  Hits         1669   1669

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b12f4a6...cbefb91. Read the comment docs.


Border of top panel overlaps bottom panel

https://github.com/nvim-zh/colorful-winsep.nvim/assets/33354262/29660cd9-ab4b-4b7f-81c9-675a78a62924
Minimal config:
local fn = vim.fn
local install_path = fn.stdpath('data') .. '/site/pack/packer/start/packer.nvim'
vim.opt.laststatus = 3

if fn.empty(fn.glob(install_path)) > 0 then
  packer_bootstrap = fn.system({
    'git',
    'clone',
    '--depth',
    '1',
    'https://github.com/wbthomason/packer.nvim',
    install_path
  })
  vim.o.runtimepath = vim.fn.stdpath('data') .. '/site/pack/*/start/*,' .. vim.o.runtimepath
end

vim.cmd [[
  augroup packer_user_config
    autocmd!
    autocmd BufWritePost packer_init.lua source <afile> | PackerSync
  augroup end
]]

local status_ok, packer = pcall(require, 'packer')
if not status_ok then
  return
end

packer.init {
  display = {
    open_fn = function()
      return require("packer.util").float { border = "rounded" }
    end,
  },
  git = {
    clone_timeout = 300, -- Timeout, in seconds, for git clones
  },
}

return packer.startup(function(use)

use {
    "nvim-zh/colorful-winsep.nvim",
    config = function ()
        require('colorful-winsep').setup()
    end
}

  if packer_bootstrap then
    require('packer').sync()
  end
end)

you should adjust the anchor parameters, which is better suited to everyone's configuration, see the alpha branch documentation to help

Or you can fix the branch to the main branch, now the default branch is alpha, but main will no longer be updated

Indeed it helped. Thank You.
In case anyone else have the same problem here is my config:
  anchor = {
    left = { height = 0, x = -1, y = -1 },
    right = { height = 0, x = -1, y = 0 },
    up = { width = 0, x = -1, y = 0 },
    bottom = { width = 0, x = 0, y = 0 },
  },

It also fixes an issue when vertical separator breaks global statusline (which You can see on the video above).

Indeed it helped. Thank You. In case anyone else have the same problem here is my config:
  anchor = {
    left = { height = 0, x = -1, y = -1 },
    right = { height = 0, x = -1, y = 0 },
    up = { width = 0, x = -1, y = 0 },
    bottom = { width = 0, x = 0, y = 0 },
  },

It also fixes an issue when vertical separator breaks global statusline (which You can see on the video above).

I think that's the right thing to do, rather than adapt everyone's configuration, let everyone adjust the parameters
Thank you very much for your question


Update Realm Dependency to 3.17.3and above (xcode 11 support)

can we please Update Realm Dependency to 3.17.3 and above
for xcode 11 support and IOS13

Same problem too

faced the same problem. Please update realm for xcode 11 support

Unfortunately, it doesn't work with xcode 11. Support guys above.

Kamino cloned this issue to vector-im/riot-ios

This was fixed by https://github.com/matrix-org/matrix-ios-sdk/pull/740


Release Google.Cloud.BeyondCorp.ClientGateways.V1 version 1.3.0

Changes in this release:
New features

Add IServiceCollection extension methods for client registration where an IServiceProvider is required. (commit 022fab2)

Created release for Google.Cloud.BeyondCorp.ClientGateways.V1-1.3.0


Use root node for detached node lookup in location retrieval

Fixes #2791
Maybe just let nodeInOriginalTree = sharedState.detachedNodes[Syntax(node.root)] is sufficient? I tried and no existing tests failed.

@swift-ci Please test

Thanks for fixing this @mateusrodriguesxyz! 🙏🏽


support for parameter type bytes

The CNAB spec merged in https://github.com/deislabs/cnab-spec/pull/83/ to allow bytes as a supported parameter type. It would great to see this implemented in duffle so that other runtimes have an idea on how to support this use case.

@youreddy do you think this is still relevant with the move to JSON schema based definitions? I think that the proper way to handle this is with a string type parameter and appropratie contentEncoding.
We likely need to have some documentation for this.
Duffle could be nice and try and automatically un-encode when things are loaded into the invocation image, but maybe for 1.0 we just support the passing of encoded strings?


Upgrade to using ITK version 5.1b01

ITKV4 compatibility is enabled, along with not removing deprecated
code.
The goal of migration to ITKv5 for SimpleITK is to maintain a
compatible SimpleITK interface and provide as little disruption as
possible to the algorithms.

Lets merge this update and fix things in master.