ingester's compatibility with kafka 2.3

When ingester has more than one instance,it will continuous display those messages.

Here are env info:
ingester:1.14.0
kafka:2.3
Here are error msgs:
====ingester====
2019/09/21 10:42:18 maxprocs: Leaving GOMAXPROCS=1: CPU quota undefined
WARNING: found deprecated command line option --span-storage.type=elasticsearch, please use environment variable SPAN_STORAGE_TYPE instead
{"level":"info","ts":1569033738.0063226,"caller":"flags/service.go:115","msg":"Mounting metrics handler on admin server","route":"/metrics"}
{"level":"info","ts":1569033738.006453,"caller":"flags/admin.go:108","msg":"Mounting health check on admin server","route":"/"}
{"level":"info","ts":1569033738.006529,"caller":"flags/admin.go:114","msg":"Starting admin HTTP server","http-port":14270}
{"level":"info","ts":1569033738.006546,"caller":"flags/admin.go:100","msg":"Admin server started","http-port":14270,"health-status":"unavailable"}
{"level":"info","ts":1569033738.023475,"caller":"healthcheck/handler.go:129","msg":"Health Check state change","status":"ready"}
{"level":"info","ts":1569033738.023505,"caller":"consumer/consumer.go:78","msg":"Starting main loop"}
{"level":"info","ts":1569033738.151742,"caller":"consumer/consumer.go:169","msg":"Starting error handler","partition":0}
{"level":"info","ts":1569033738.1518486,"caller":"consumer/consumer.go:112","msg":"Starting message handler","partition":0}
{"level":"info","ts":1569033741.4189322,"caller":"consumer/consumer.go:180","msg":"Finished handling errors","partition":0}
{"level":"info","ts":1569033741.4189994,"caller":"consumer/consumer.go:138","msg":"Message channel closed. ","partition":0}
{"level":"info","ts":1569033741.4190173,"caller":"consumer/consumer.go:162","msg":"Closing partition consumer","partition":0}
{"level":"info","ts":1569033741.4191213,"caller":"consumer/consumer.go:165","msg":"Closed partition consumer","partition":0}
{"level":"info","ts":1569033741.8808475,"caller":"consumer/consumer.go:169","msg":"Starting error handler","partition":0}
{"level":"info","ts":1569033741.8809078,"caller":"consumer/consumer.go:112","msg":"Starting message handler","partition":0}
{"level":"info","ts":1569033744.2168658,"caller":"consumer/processor_factory.go:62","msg":"Creating new processors","partition":0}
{"level":"info","ts":1569033745.9766564,"caller":"consumer/consumer.go:180","msg":"Finished handling errors","partition":0}
{"level":"info","ts":1569033745.9767509,"caller":"consumer/consumer.go:138","msg":"Message channel closed. ","partition":0}
{"level":"info","ts":1569033745.9780123,"caller":"processor/parallel_processor.go:78","msg":"Completed shutdown of processor goroutines"}
{"level":"info","ts":1569033745.9780428,"caller":"consumer/consumer.go:162","msg":"Closing partition consumer","partition":0}
{"level":"info","ts":1569033745.9780908,"caller":"consumer/consumer.go:165","msg":"Closed partition consumer","partition":0}
{"level":"info","ts":1569033746.7944613,"caller":"consumer/consumer.go:169","msg":"Starting error handler","partition":0}
{"level":"info","ts":1569033746.7945256,"caller":"consumer/consumer.go:112","msg":"Starting message handler","partition":0}
{"level":"info","ts":1569033750.0735219,"caller":"consumer/consumer.go:180","msg":"Finished handling errors","partition":0}
{"level":"info","ts":1569033750.07358,"caller":"consumer/consumer.go:138","msg":"Message channel closed. ","partition":0}
{"level":"info","ts":1569033750.0735936,"caller":"consumer/consumer.go:162","msg":"Closing partition consumer","partition":0}
{"level":"info","ts":1569033750.0736668,"caller":"consumer/consumer.go:165","msg":"Closed partition consumer","partition":0}
{"level":"info","ts":1569033750.5355024,"caller":"consumer/consumer.go:169","msg":"Starting error handler","partition":0}
{"level":"info","ts":1569033750.535565,"caller":"consumer/consumer.go:112","msg":"Starting message handler","partition":0}
{"level":"info","ts":1569033753.813964,"caller":"consumer/consumer.go:180","msg":"Finished handling errors","partition":0}
{"level":"info","ts":1569033753.8140304,"caller":"consumer/consumer.go:138","msg":"Message channel closed. ","partition":0}
{"level":"info","ts":1569033753.8140442,"caller":"consumer/consumer.go:162","msg":"Closing partition consumer","partition":0}
{"level":"info","ts":1569033753.8141136,"caller":"consumer/consumer.go:165","msg":"Closed partition consumer","partition":0}
{"level":"info","ts":1569033754.2764068,"caller":"consumer/consumer.go:169","msg":"Starting error handler","partition":0}
{"level":"info","ts":1569033754.2764654,"caller":"consumer/consumer.go:112","msg":"Starting message handler","partition":0}
^C{"level":"info","ts":1569033755.513566,"caller":"flags/service.go:145","msg":"Shutting down"}
{"level":"info","ts":1569033755.5136282,"caller":"healthcheck/handler.go:129","msg":"Health Check state change","status":"unavailable"}
{"level":"info","ts":1569033755.5136454,"caller":"consumer/consumer.go:162","msg":"Closing partition consumer","partition":0}
{"level":"info","ts":1569033755.5326853,"caller":"consumer/consumer.go:180","msg":"Finished handling errors","partition":0}
{"level":"info","ts":1569033755.5327137,"caller":"consumer/consumer.go:138","msg":"Message channel closed. ","partition":0}
{"level":"info","ts":1569033755.532727,"caller":"consumer/consumer.go:162","msg":"Closing partition consumer","partition":0}
{"level":"info","ts":1569033755.5328152,"caller":"consumer/consumer.go:165","msg":"Closed partition consumer","partition":0}
{"level":"info","ts":1569033755.5328388,"caller":"consumer/consumer.go:165","msg":"Closed partition consumer","partition":0}
{"level":"info","ts":1569033755.53285,"caller":"consumer/consumer.go:107","msg":"Closing parent consumer"}
{"level":"info","ts":1569033755.5365846,"caller":"flags/service.go:153","msg":"Shutdown complete"}
You have new mail in /var/spool/mail/root
====ingester====
====kafka server.log===
[2019-09-21 10:42:08,286] INFO [GroupCoordinator 188]: Preparing to rebalance group jaeger-ingester-20190906 in state PreparingRebalance with old generation 1689 (__consumer_offsets-38) (reason: Adding new member jaeger-ingester-e9c21519-a721-4745-aa80-c6d2aee64231 with group instanceid None) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:08,290] INFO [GroupCoordinator 188]: Stabilized group jaeger-ingester-20190906 generation 1690 (__consumer_offsets-38) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:08,293] INFO [GroupCoordinator 188]: Assignment received from leader for group jaeger-ingester-20190906 for generation 1690 (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:18,130] INFO [GroupCoordinator 188]: Preparing to rebalance group jaeger-ingester-20190906 in state PreparingRebalance with old generation 1690 (__consumer_offsets-38) (reason: Adding new member jaeger-ingester-0eb85261-1de8-4f6f-b53a-29a2944c5765 with group instanceid None) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:18,147] INFO [GroupCoordinator 188]: Stabilized group jaeger-ingester-20190906 generation 1691 (__consumer_offsets-38) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:18,148] INFO [GroupCoordinator 188]: Assignment received from leader for group jaeger-ingester-20190906 for generation 1691 (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:21,124] INFO [GroupCoordinator 188]: Preparing to rebalance group jaeger-ingester-20190906 in state PreparingRebalance with old generation 1691 (__consumer_offsets-38) (reason: Adding new member jaeger-ingester-a30be48c-7c7c-4011-9c83-071ee7140cb6 with group instanceid None) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:21,134] INFO [GroupCoordinator 188]: Stabilized group jaeger-ingester-20190906 generation 1692 (__consumer_offsets-38) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:21,136] INFO [GroupCoordinator 188]: Assignment received from leader for group jaeger-ingester-20190906 for generation 1692 (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:21,876] INFO [GroupCoordinator 188]: Preparing to rebalance group jaeger-ingester-20190906 in state PreparingRebalance with old generation 1692 (__consumer_offsets-38) (reason: Adding new member jaeger-ingester-0bb14181-b214-476f-a77e-cab9dbaa08d7 with group instanceid None) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:21,877] INFO [GroupCoordinator 188]: Stabilized group jaeger-ingester-20190906 generation 1693 (__consumer_offsets-38) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:21,877] INFO [GroupCoordinator 188]: Assignment received from leader for group jaeger-ingester-20190906 for generation 1693 (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:24,674] INFO [GroupCoordinator 188]: Preparing to rebalance group jaeger-ingester-20190906 in state PreparingRebalance with old generation 1693 (__consumer_offsets-38) (reason: Adding new member jaeger-ingester-e1043d6a-0134-4ad3-af1f-c0285b355e0d with group instanceid None) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:24,675] INFO [GroupCoordinator 188]: Stabilized group jaeger-ingester-20190906 generation 1694 (__consumer_offsets-38) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:24,676] INFO [GroupCoordinator 188]: Assignment received from leader for group jaeger-ingester-20190906 for generation 1694 (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:26,790] INFO [GroupCoordinator 188]: Preparing to rebalance group jaeger-ingester-20190906 in state PreparingRebalance with old generation 1694 (__consumer_offsets-38) (reason: Adding new member jaeger-ingester-7231aa34-d430-42d7-bfd0-ffbcb87de626 with group instanceid None) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:26,791] INFO [GroupCoordinator 188]: Stabilized group jaeger-ingester-20190906 generation 1695 (__consumer_offsets-38) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:26,791] INFO [GroupCoordinator 188]: Assignment received from leader for group jaeger-ingester-20190906 for generation 1695 (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:28,408] INFO [GroupCoordinator 188]: Preparing to rebalance group jaeger-ingester-20190906 in state PreparingRebalance with old generation 1695 (__consumer_offsets-38) (reason: Adding new member jaeger-ingester-cc9fa2c5-cbbf-4b11-956a-a2b2baf51513 with group instanceid None) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:28,408] INFO [GroupCoordinator 188]: Stabilized group jaeger-ingester-20190906 generation 1696 (__consumer_offsets-38) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:28,437] INFO [GroupCoordinator 188]: Assignment received from leader for group jaeger-ingester-20190906 for generation 1696 (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:30,531] INFO [GroupCoordinator 188]: Preparing to rebalance group jaeger-ingester-20190906 in state PreparingRebalance with old generation 1696 (__consumer_offsets-38) (reason: Adding new member jaeger-ingester-56a13689-d051-4e97-8819-1dd028a2dff3 with group instanceid None) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:30,532] INFO [GroupCoordinator 188]: Stabilized group jaeger-ingester-20190906 generation 1697 (__consumer_offsets-38) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:30,532] INFO [GroupCoordinator 188]: Assignment received from leader for group jaeger-ingester-20190906 for generation 1697 (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:32,178] INFO [GroupCoordinator 188]: Preparing to rebalance group jaeger-ingester-20190906 in state PreparingRebalance with old generation 1697 (__consumer_offsets-38) (reason: Adding new member jaeger-ingester-05ed8b29-cda5-4fb4-a730-bb206d25f66a with group instanceid None) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:32,179] INFO [GroupCoordinator 188]: Stabilized group jaeger-ingester-20190906 generation 1698 (__consumer_offsets-38) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:32,180] INFO [GroupCoordinator 188]: Assignment received from leader for group jaeger-ingester-20190906 for generation 1698 (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:34,270] INFO [GroupCoordinator 188]: Preparing to rebalance group jaeger-ingester-20190906 in state PreparingRebalance with old generation 1698 (__consumer_offsets-38) (reason: Adding new member jaeger-ingester-0b4bcbb0-5cbc-49f1-a93d-fc0b211e9000 with group instanceid None) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:34,271] INFO [GroupCoordinator 188]: Stabilized group jaeger-ingester-20190906 generation 1699 (__consumer_offsets-38) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:34,272] INFO [GroupCoordinator 188]: Assignment received from leader for group jaeger-ingester-20190906 for generation 1699 (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:35,534] INFO [GroupCoordinator 188]: Member jaeger-ingester-0b4bcbb0-5cbc-49f1-a93d-fc0b211e9000 in group jaeger-ingester-20190906 has left, removing it from the group (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:35,534] INFO [GroupCoordinator 188]: Preparing to rebalance group jaeger-ingester-20190906 in state PreparingRebalance with old generation 1699 (__consumer_offsets-38) (reason: removing member jaeger-ingester-0b4bcbb0-5cbc-49f1-a93d-fc0b211e9000 on LeaveGroup) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:35,534] INFO [GroupCoordinator 188]: Group jaeger-ingester-20190906 with generation 1700 is now empty (__consumer_offsets-38) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:35,914] INFO [GroupCoordinator 188]: Preparing to rebalance group jaeger-ingester-20190906 in state PreparingRebalance with old generation 1700 (__consumer_offsets-38) (reason: Adding new member jaeger-ingester-1f04fc99-d91b-4559-a1d5-507bdaa0010d with group instanceid None) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:35,915] INFO [GroupCoordinator 188]: Stabilized group jaeger-ingester-20190906 generation 1701 (__consumer_offsets-38) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:35,916] INFO [GroupCoordinator 188]: Assignment received from leader for group jaeger-ingester-20190906 for generation 1701 (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:39,191] INFO [GroupCoordinator 188]: Member jaeger-ingester-1f04fc99-d91b-4559-a1d5-507bdaa0010d in group jaeger-ingester-20190906 has left, removing it from the group (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:39,192] INFO [GroupCoordinator 188]: Preparing to rebalance group jaeger-ingester-20190906 in state PreparingRebalance with old generation 1701 (__consumer_offsets-38) (reason: removing member jaeger-ingester-1f04fc99-d91b-4559-a1d5-507bdaa0010d on LeaveGroup) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:42:39,192] INFO [GroupCoordinator 188]: Group jaeger-ingester-20190906 with generation 1702 is now empty (__consumer_offsets-38) (kafka.coordinator.group.GroupCoordinator)
[2019-09-21 10:47:53,329] INFO [GroupMetadataManager brokerId=188] Removed 0 expired offsets in 11 milliseconds. (kafka.coordinator.group.GroupMetadataManager)
====kafka server.log===
The rebalance is too frequently too Unbelievable.
ps:when use kafka 2.2.1 ,that's ok.

@yurishkuro @pavolloffay
please give it a little attention,thks.

This is a duplicate of https://github.com/jaegertracing/jaeger/issues/1774

Apart from the logs(which look normal), what user facing issue does this cause?

Apart from the logs(which look normal), what user facing issue does this cause?

The rebalance is too frequently too Unbelievable.

it looks to me that rebalances are initiated by the Kafka server. The only condition that I know of when the  ingester would cause a rebalance is if its deadlock detector kicks in and closes a partition due to inactivity, but I don't see those logs in the output.

I wonder if newer Kafka implements some heartbeat to the consumers which is not supported by sarama driver, and that might cause the server to rebalance consumers.

Also, it would be useful to have the following information

How frequently do you see these rebalances?
What is the read throughput?
What is the resource utilization on your containers? Are they oversubscribed?
What is the topic configuration?

Also, it would be useful to have the following information

How frequently do you see these rebalances?
What is the read throughput?
What is the resource utilization on your containers? Are they oversubscribed?
What is the topic configuration?

A1:3s
A2-4:container load is normal

We noticed the same with multiple instances of jaeger-ingester consuming from kafka. Partition ownership seems to cycle through being owned by the individual ingesters, this may happen before offsets have been committed, which may lead to "some amount" of re-consumption of the same messages. For us - dropping down to single ingester consuming from kafka seems to have mostly solved this for us.
Also - sarama-cluster seems to have been deprecated in favor of features merged into sarama.

We noticed the same with multiple instances of jaeger-ingester consuming from kafka. Partition ownership seems to cycle through being owned by the individual ingesters, this may happen before offsets have been committed, which may lead to "some amount" of re-consumption of the same messages. For us - dropping down to single ingester consuming from kafka seems to have mostly solved this for us.
Also - sarama-cluster seems to have been deprecated in favor of features merged into sarama.

@yurishkuro @vprithvi
please notice it.

Once again, the rebalance of partitions is initiated by the Kafka brokers. Broker logs don't show why it might be happening, so we cannot diagnose it. It could be the driver issue (sarama-cluster), or the fact that ingesters do not commit offsets immediately (we have outstanding ticket #1109 to look into that).
Upgrading to the latest sarama might help, if someone wants to give it a try.

@rubenvp8510 can we close this issue?
Your PR https://github.com/jaegertracing/jaeger/pull/2009#issuecomment-572703966 comments that the issue has been fixed in Kafka 2.3.1

It seems that the bug with Kafka was fixed with 2.3.1. I prefer that we go with option (3) for now.

@pavolloffay Yes, we can close it.

thanks @rubenvp8510


Move Firestore to Auth interop library.

This will be one less dependency on Core's Auth changes and handle the instance lifecycle for deleted FIRApps.

You probably need cmake changes for FirebaseAuthInterop similar to the ones I made for GoogleUtilities.

I love continuous integration.

Once I clear up the build problems, the test fails post run here:
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x20)
  * frame #0: 0x00007fff78d9ad6f libobjc.A.dylib`objc_retain + 31
    frame #1: 0x000000010008e23a firebase_firestore_auth_apple_test`-[FIRComponentContainer instanceForProtocol:](self=0x0000000100415ff0, _cmd="instanceForProtocol:", protocol=0x00000001000b8690) at FIRComponentContainer.m:172
    frame #2: 0x000000010008e8f3 firebase_firestore_auth_apple_test`+[FIRComponentType instanceForProtocol:inContainer:](self=FIRComponentType, _cmd="instanceForProtocol:inContainer:", protocol=0x00000001000b8690, container=0x0000000100415ff0) at FIRComponentType.m:25
    frame #3: 0x0000000100010dd0 firebase_firestore_auth_apple_test`firebase::firestore::auth::FirebaseCredentialsProvider::GetToken(this=0x00007ffeefbfef90, completion=0x00007ffeefbfef60)>) at firebase_credentials_provider_apple.mm:127
    frame #4: 0x00000001000026a1 firebase_firestore_auth_apple_test`firebase::firestore::auth::FirebaseCredentialsProviderTest_GetTokenUnauthenticated_Test::TestBody(this=0x0000000100406e20) at firebase_credentials_provider_test.mm:116
    frame #5: 0x000000010007697e firebase_firestore_auth_apple_test`void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(object=0x0000000100406e20, method=21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00, location="the test body")(), char const*) at gtest.cc:2402
    frame #6: 0x00000001000303eb firebase_firestore_auth_apple_test`void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(object=0x0000000100406e20, method=21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00, location="the test body")(), char const*) at gtest.cc:2438
    frame #7: 0x0000000100030316 firebase_firestore_auth_apple_test`testing::Test::Run(this=0x0000000100406e20) at gtest.cc:2474

@wilhuff I believe I addressed everything now and travis is passing, thanks again for the help with CMake!


[scribe ctrl counters] fix encoding in name of counter avoiding outag…

…e in monitoring

I created THRIFT-4185 for this change.  Please see https://thrift.apache.org/docs/HowToContribute for future pull requests.  Thanks!

sorry. I wanted to send the pr to a forked repo not this, was misclick.


Definition for what happens to packets experiencing parser errors?

Here is a PR to address this same question for the PSA specification in one particular way, which we should review and think about whether we want something similar for PNA, too: https://github.com/p4lang/p4-spec/pull/1026

I wonder if it would make sense to make the behavior for packets experiencing parsing errors configurable.
Even though it makes sense that the P4 program running in the Control is able to decide what to do with such packets, there may be cases where such packets should be discarded to reduce the load on the match-action pipeline.
External configuration means could fulfil this purpose.
If we agreed to have such means, I would guess we wouldn't need to define exactly what they are, but just say that they are available.

@mariobaldi Looks like a reasonable idea to me.  Should we consider it for the PSA specification as well, while we are at it?


Enhancement of the Footer , Proper Alignment of the Gmap and make this part Responsive

can you assign this issue to me under GSSOC'24 EXTD

@gauravsingh1281  I have raised PR for this issue. Kindly check it


Update Ruby to 3.3.1, and refresh github actions

Resolves: https://github.com/govuk-one-login/tech-docs/issues/166
Why
Spring cleaning and maintenance to ensure we're running reasonable versions.
The update to Ruby 3.3.x was delayed until they fixed a bug in 3.3.1.
Should now be unblocked on apple silicone.
How to review

@pauldougan could you switch to this branch and run ./preview-with-docker.sh on a mac? Check there's no outstanding issues?

confirmed works on mac. will merge tuesday

@pauldougan would you mind approving this so i can merge it?


Fails when using WASM-based libraries

I am trying to use this plugin in a vite-based project, where I am running a worker that uses a wasm-based library.  I can successfully use the library with standard imports into the project, but when I attempt to load the library within the web worker, it stalls, even if the library itself isn't used. I have created a sandbox that shows this behavior. A couple other notes:

In the worker.js file, the library is being imported. Commenting this out should allow the App.jsx to retrieve the result of the add function and display it (instead of null).
The other stuff in App.jsx just confirms that the wasm-based library is indeed functioning within the non-webworker environment.
I tried fiddling with the ordering of the various plugins, but couldn't get anything to work with that.

Is this something that is a limitation of the library, or could it be a configuration issue somewhere?
Thanks!

Thanks for reporting. Quick guess: is your lib running the wasm inside a webworker? Than it might be problematic.
Will digg into it later will take some time...

Thanks for the reply. It isn't running a webworker as far as I know, but I may be mistaken. The lib itself is generated through wasm-bindgen and wasm-pack using their bundler target (link). I inquired with them about any limitations this may have but so far haven't heard back.

might be fixed with v5 please try it and if it doesn't work reopen this issue.


Add container build / releases

It would be good to publish docker container builds / releases for Verible with the stand alone binaries.

@umarcor - Any thoughts on the best way to do this?

I'd suggest contributing to https://github.com/hdl/containers/tree/main/debian-bullseye.
https://hdl.github.io/containers/dev/Contributing.html#single-file-example or https://hdl.github.io/containers/dev/Contributing.html#example-with-hdlc-script can be used as a reference. See also https://hdl.github.io/containers/dev/Contributing.html#step-by-step-checklist.
The target architectures to build the containers for are defined in https://github.com/hdl/containers/blob/main/utils/pyHDLC/config.yml#L128-L143. I would start with SysDebianAmd64 and then change to SysDebianDefaultArchSet.


offline support

What is missing?
Unlike other cloudalchemy roles, this role has no offline support, would be great to
have this here as well.
https://github.com/cloudalchemy/ansible-prometheus/issues/296

I am open to PRs which will implement it. Reference PRs are in https://github.com/cloudalchemy/ansible-alertmanager/pull/83 and https://github.com/cloudalchemy/ansible-prometheus/pull/239

If there is no good reason to keep the binary writable to the user running the service I'll change that to root (task: propagate blackbox exporter binary)

If there is no good reason to keep the binary writable to the user running the service I'll change that to root

root seems good to me

This role has been deprecated in favor of a the prometheus-community/ansible collection.


Initial registration of EnergyModelsGeography

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/99881
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.8.1 -m "<description of version>" 54d377eb385001727c0f7be9cec1ba6cfa055d70
git push origin v0.8.1

Also, note the warning: This looks like a new registration that registers version 0.8.1.
Ideally, you should register an initial release with 0.0.1, 0.1.0 or 1.0.0 version numbers
This can be safely ignored. However, if you want to fix this you can do so. Call register() again after making the fix. This will update the Pull request.


RUMM-2019: Update schemas with new telemetry events

What does this PR do?
This change brings support of new telemetry events added in https://github.com/DataDog/rum-events-format/pull/54.
Review checklist (to be filled by reviewers)

[x] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[x] Make sure you discussed the feature or bugfix with the maintaining team in an Issue
[x] Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

Codecov Report

Merging #864 (85e0ec2) into develop (3da4145) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #864   +/-   ##
========================================
  Coverage    81.72%   81.72%
========================================
  Files          258      258
  Lines         8763     8763
  Branches      1495     1495
========================================
  Hits          7161     7161
- Misses        1257     1259    +2
+ Partials       345      343    -2

Impacted Files
Coverage Δ

...ain/java/com/datadog/opentracing/PendingTrace.java
56.41% <0.00%> (-3.42%)
:arrow_down:

...rc/main/java/com/datadog/opentracing/DDTracer.java
54.77% <0.00%> (-1.24%)
:arrow_down:

.../android/rum/internal/monitor/DatadogRumMonitor.kt
94.81% <0.00%> (+0.65%)
:arrow_up:

...android/rum/internal/ndk/DatadogNdkCrashHandler.kt
86.19% <0.00%> (+1.66%)
:arrow_up:

...droid/rum/tracking/ActivityViewTrackingStrategy.kt
88.46% <0.00%> (+1.92%)
:arrow_up:

...main/java/com/datadog/exec/CommonTaskExecutor.java
51.02% <0.00%> (+4.08%)
:arrow_up:


Remove gendocs from master

Repo settings are now configured to serve the gh-pages branch, where these files were just added, so these files are no longer being served:

https://github.com/mesosphere/dcos-commons/settings
https://github.com/mesosphere/dcos-commons/tree/gh-pages => http://mesosphere.github.io/dcos-commons/

TODO in a separate PR: Add a script in master:docs/ which will automatically regenerate/update all content in gh-pages upon changes to master.

retest this please


More EIP tests

related #2628
fix #2952

Okay try with 3.12.0-SNAPSHOT for the service call native test - it should be reflection free now.


CMake fails on Ubuntu Server

Running Cmake with default recommended parameters
`

$ mkdir ~/cpp-netlib-build
$ cd ~/cpp-netlib-build
$ cmake -DCMAKE_BUILD_TYPE=Debug
-DCMAKE_C_COMPILER=gcc
-DCMAKE_CXX_COMPILER=g++
~/cpp-netlib

ERROR: cmake build fails with following message

CMake Error at CmakeLists.txt:136 (add_subdirectory):
The source directory

/root/cpp-netlib/deps/googletest

does not contain a CMakeLists.txt file.

CMake Error at CmakeLists.txt:136 (add_subdirectory):
add_subdirectory given source "deps/uri/test" which is not an existing directory.

--Configuration incomplete, errors occurred!
`
I had been trying to build this but it seems like I am missing some subdirectories. I pulled the original source from git. Hope someone can help me with this.

Try running the following from the command line before running CMake:
git submodule update --init --recursive

Thanks. It solved the error


Time series reconstruction

I am trying to run the reverse pipeline of RobustSTL method. That is, constructing the original time series based on the 3 components (Trend, seaso, Residue). Did you implement this by any chance?

I didn't implement that, but you can just add the three terms.


x/tools/cmd/gopls: add support for handling deltas in DidChange

This is a tracking issue for adding support for handling deltas in textDocument/didChange.
https://github.com/Microsoft/language-server-protocol/blob/gh-pages/specification.md#didchangetextdocument-notification-arrow_right
Currently clients are required to send the entire file contents for each change. This starts to get noticeable for large-ish files.
cc @stamblerre @ianthehat

If you set `incrementalSync=true' in the initialize params it will be enabled. We will enable it by default when we have reasonable confidence that it works properly (I have had it enabled for a while now and it seems to be okay)

Thanks - I'm still waiting on a change on the Vim side to be able to do this (without workarounds) https://github.com/vim/vim/issues/4191


Project file not parsed when file in sub-folder is opened

For instance, when I do atom -d . in my atom-fsharp dev dir, atom will typically open up
with a file that is not in project root folder. Nothing works then, you get compilation errors etc.
To make atom-fsharp 'get it', I have to open a file in the project root, which makes it find the fsproj file.
To fix this, directories will need to be searched recursively going upward from current file, about here.

#89 merged and released as part of 0.6.4


Spanish language translations for home and downloads

Changes:
Updated Spanish language translations for home and downloads.

thanks!


Adding a waste classification section

Adding basic information about waste classification can help users understand the different types of waste and how to manage them effectively.

@aditiverma-21 this issue is already assigned you can work on another issue .


refactor(pageEvents): let vue component instance bound to pageEvent function

The event functions such like pageInit, pageBeforeRemove are hard to get vue instance, so I add feature that make the on could be function and bind to vue component.
export default {
    methods: {
      openStandalone: function () {
        const self = this;
        self.standalone.open();
      },
    },
    on: {
        pageInit: function () {
          const self = this
          // before this change, `self` was the dom object, will get error
          self.standalone = self.$f7.photoBrowser.create({
            photos: self.photos,
          });
        },
    }
    on() {
      const self = this;
      return {
        pageInit: function () {
          // now, self is vue instance, `openStandalone` become available
          self.standalone = self.$f7.photoBrowser.create({
            photos: self.photos,
          });
        },
      }
    }
  };

Thanks. But found two issues with this approach:

Method on() { return { ... }} not so comfortable as the previous option 😀
We have binding to parent router component pageEvents.apply(routerVue); instead of the current page component which i guess is not what we expect. routerVue refers to parent <f7-view> component. So if you have something like this:

data() {
  return { foo: 'bar' },
},
on() {
  const self = this;
  return { pageInit() { console.log(self.foo) } }
}

will output undefined

So i have tried few things too and pushed this fix https://github.com/framework7io/Framework7-Vue/commit/dbbf442e405ab3ec0de1db5633478fd8762af7e0
where we are searching for related Vue component and bind page events to its context

Yes, it's  a better solution and will not influence existing codes, thanks


GI probe: Compress option adds green tint to scene

Godot version:
3.2.1.stable.mono.official
OS/device including version:
Win10 pro 64bit, nivida GTX 1060, GLES3
Issue description:
Baking the GIProbe with compressed option checked adds a green tint to the scene that's not visible when compressed is unchecked.

Steps to reproduce:
Build GI probe without compressed checked and compare with scene after checking compressed and rebuild.
Minimal reproduction project:
GIProbe.zip

Duplicate of #18449 and #32427. We should remove the compress property entirely at some point.


Unable to force renewal

The automated task appeared to stall out when it ran.  When I closed it and re-ran, the client shows "renew after 8/5/2016" which to me says that it did try to renew, but I cannot find where it stored the renewed certificates.
I had originally requested them with --san and --centralsslstore, however, the scheduled task that was created does not have these options (not sure if that is really any issue).
I would like to try to run the renewal again and have seen references to other implementations that have the option (--renewal-by-default or --force-renew).

You should check your event log to see what was logged during the renewal.
You might have to enable debug logging and rerun the renewal again. However the renewals are currently driven off the registry (HKCU\Software\letsencrypt-win-simple\https://acme-v01.api.letsencrypt.org/), so you will have to edit the registry key to change the date to make it try to renew the cert.
The san and centralsslstore options are stored in the registry information. That way only 1 renewal task is needed no matter what arguments you run the app with.
There isn't currently any other options besides the regular --renew .
My guess is that it either failed somewhere (enhancement request to fix that in #162), or the same issue as in https://github.com/Lone-Coder/letsencrypt-win-simple/issues/221#issuecomment-222999651.

Actually, this looks like it might be Issue #195 , so you can probably dupe this to that.  I've added my thumbs up on that issue/request.  Also, you might get more people here with that same issue if they followed this guide like I did: https://forums.servethehome.com/index.php?resources/letsencrypt-a-2012-r2-web-application-proxy.16/

Yep, the manual plugin doesn't support renewals right now, but will in the future.


Support of EKS-Anywhere with NetApp S3

We are running EKS-Anywhere (with sunscription) in house (our data must stay in house). We have a NetApp device with S3 server support.
I may overlooked something but it seems this CSI driver only Amazon S3 buckets. If this was true then this is a feature request to support 3rd party S3 bucket solutions (that are fully compatible with Amazon's S3 protocol).

Thank you for the request. The CSI driver is built on top of mountpoint-s3, which dictates the server compatibility. From the README on that project:

Mountpoint for Amazon S3 is designed for high-performance access to the Amazon S3 service. While it may be functional against other storage services that use S3-like APIs, we aren't able to provide support for those use cases, and they may inadvertently break when we make changes to better support Amazon S3. We welcome contributions of minor compatibility fixes or performance improvements for these services if the changes can be tested against Amazon S3.

You can try the endpoint-url option in your persistent volume configuration to point at a different endpoint, but do note the caveat that it is not officially supported and there is the potential for breaking changes. To set the endpoint-url in a persistent volume configuration, simply add a line like this under mountOptions (see the static_provisioning example for more details on volume configuration):
  mountOptions:
    - endpoint-url https://my.s3.server.com

Also take a look at https://github.com/awslabs/mountpoint-s3/issues/144, which has some additional notes on compatibility and a report that someone was able to use mountpoint-s3 with a NetApp appliance.

Hi @jjkr,
Thanks a lot for the information, it was very useful and makes it clear that this ticket is opened for the wrong github project :)
We will give it a try and also try to get NetApp to take a look at it (they are normally good in such integrations/contributions).
Thanks.


Small syntax update for including style-loader

Hi team 👋
This simple syntax change will allow for other CRA extension utilities (like customize-cra) to add options the 'style-loader'. Specifically the "insert" prop (fka "insertInto") can be quite useful.
E.g. https://github.com/arackaf/customize-cra/blob/master/api.md#adjuststyleloaderscallback
It's possible that preventing overrides to the 'style-loader' configuration was intentional as a way to prevent downstream webpack/hot-update bugs, but I haven't run into any when running this update in an ejected create-react-app. So would appreciate any veteran thoughts on whether this is safe to update.
Thanks for considering!

Looks like each of the Azure Devops Pipeline test run reports since Tuesday are failing with the same error:
Cannot find module '@babel/helper-create-regexp-features-plugin'

So, likely independent of this PR?

Hi @rfreling, can you please rebase? That should fix the CI issue.

Hi @rfreling, can you please rebase? That should fix the CI issue.

Worked like a charm, thanks @mrmckeb

Hi @rfreling, it looks like your rebase failed. I see commits/changes from outside of your branch. Can you take a look at cleaning this up? Sorry for the troubles.

@mrmckeb – No problem, my bad.
It was simpler to create a new PR, so I did that here -> https://github.com/facebook/create-react-app/pull/9076

@rfreling want to close this one since you opened #9100 ?


Validate label names correctly

Use the proper regex for label names and don't expose regex directly, but use a validation function.

Still needs a test case!


syscall: document Setrlimit behavior change on Go 1.12 on macOS

HI
my go version is 1.12.1,  if i run command go run openbazaard.go start, The error is "error setting ulimit: invalid argument".
error comes from func syscall.Setrlimit()
I this this maybe help "https://github.com/golang/go/issues/30401"

Thank you for the report @lvbin2012, greatly appreciate it.


Check for BIO_eof before reading -- it is significant when reading fr…

Check for BIO_eof before reading -- it is significant when reading from terminal
See #9355 Ctrl-d twice?

Sorry, but why should we check for eof before read ?
that is usually necessary after read returns 0.

It's fairly common to have something like this with the FILE API:
while(!feof(fp) && !ferror(fp)) {
    size_t n = fread(buf, bufsize, 1, fp);

    /* process n bytes in buf */
}

Sure, it means that the first feof() call is basically a no-op.  So?
Either way, the BIO code has the same type of functionality for FILE BIOs, why not follow that same common pattern?

Yes, that is just a flag that gets set by the first unsuccessful read.
Nevertheless I think it is better style to check immediately after the read.

I dunno... A check after read means a break out of the loop. Not sure I qualify that as "better style"

Hmm, maybe but if this makes a difference, then there must have been a read before which
returned 0, and where the eof got set, right?

Well terminal is a special case, as the EOF-condition (pressing ^D in Unix) is not permanent; both read(2) and fread(3) can return data even if the user terminates the input with ^D (the difference is that fread sets the eof-bit). So the returned length is positive, you process the data then call read/fread again, without noticing that EOF occured. So the user has to press ^D again to actually terminate the reading loop.
More detailed discussion can be found in the linked issue #9355

Wait a second please...

Okay since the same style is used else.
However this would fix it too:
--- a/crypto/bio/bss_file.c
+++ b/crypto/bio/bss_file.c
@@ -143,9 +143,9 @@ static int file_read(BIO *b, char *out, int outl)

     if (b->init && (out != NULL)) {
         if (b->flags & BIO_FLAGS_UPLINK_INTERNAL)
-            ret = UP_fread(out, 1, (int)outl, b->ptr);
+            ret = UP_fread(out, (int)outl, 1, b->ptr);
         else
-            ret = fread(out, 1, (int)outl, (FILE *)b->ptr);
+            ret = fread(out, (int)outl, 1, (FILE *)b->ptr);
         if (ret == 0
             && (b->flags & BIO_FLAGS_UPLINK_INTERNAL
                 ? UP_ferror((FILE *)b->ptr) : ferror((FILE *)b->ptr))) {

No, disregard my last comment, probably time to go to bed :-)

This would work but is probably an indication of an underlying problem in BIO_eof:
diff --git a/apps/enc.c b/apps/enc.c
index 57ce924..2a35c18 100644
--- a/apps/enc.c
+++ b/apps/enc.c
@@ -594,6 +594,8 @@ int enc_main(int argc, char **argv)
             BIO_printf(bio_err, "error writing output file\n");
             goto end;
         }
+        if (inl < bsize)
+            break;
     }
     if (!BIO_flush(wbio)) {
         BIO_printf(bio_err, "bad decrypt\n");

There is a subtle difference between fread and read.
When fread returns less than requested, it is either eof or an error which stopped the read.
OTOH, fread will not return after typing one line.
when read returns > 0 it is not an error, when it returns = 0 it means EOF, and -1 means error.
fread never returns -1, but file_read returns -1 on error in some cases.

when I look at https://github.com/openssl/openssl/blob/5800ba761052894145abe7a74a1159df007b6875/crypto/evp/bio_enc.c#L151-L160
I see there is also a loop that calls BIO_read in a non-blocking style,
but uses BIO_should_retry after BIO_read instead of BIO_eof before BIO_read.
So we have more than those places where BIO_read is called w/o first calling BIO_eof.

The thing is also that the BIO API is inconsistent, it's behavior depends on the underlying API. For example, bss_fd.c doesn't support BIO_eof(), at least as far as I recall (not in a position to check this fir the moment)

On the EOF side of things, note also #8208.

Hi @mspncp would you mind re-evaluating the latest version?

Hi @mspncp would you mind re-evaluating the latest version?

Sorry for letting you wait. My change requests habe been satisfied and I am not planning to do a full review, because @levitte and @bernd-edlinger are already reviewing. So I'm just going to dismiss my review.
In fact, @levitte's approval from Jul 19 is outdated, so he needs to re-review too.

What about the CI failures? Are they related?
not ok 4 - aes-128-cbc base64
not ok 6 - aes-128-ecb base64
not ok 8 - aes-192-cbc base64
not ok 10 - aes-192-ecb base64
not ok 12 - aes-256-cbc base64
not ok 14 - aes-256-ecb base64
not ok 16 - aria-128-cbc base64
not ok 18 - aria-128-cfb base64
not ok 20 - aria-128-cfb1 base64
not ok 22 - aria-128-cfb8 base64
not ok 24 - aria-128-ctr base64
not ok 26 - aria-128-ecb base64
not ok 28 - aria-128-ofb base64
not ok 30 - aria-192-cbc base64
not ok 32 - aria-192-cfb base64
not ok 34 - aria-192-cfb1 base64
not ok 36 - aria-192-cfb8 base64
not ok 38 - aria-192-ctr base64
not ok 40 - aria-192-ecb base64
not ok 42 - aria-192-ofb base64
not ok 44 - aria-256-cbc base64
not ok 46 - aria-256-cfb base64
not ok 48 - aria-256-cfb1 base64
not ok 50 - aria-256-cfb8 base64
not ok 52 - aria-256-ctr base64
not ok 54 - aria-256-ecb base64
not ok 56 - aria-256-ofb base64
not ok 57 - base64
not ok 58 - base64 base64
not ok 60 - bf base64
not ok 62 - bf-cbc base64
not ok 64 - bf-cfb base64
not ok 66 - bf-ecb base64
not ok 68 - bf-ofb base64
not ok 70 - camellia-128-cbc base64
not ok 72 - camellia-128-ecb base64
not ok 74 - camellia-192-cbc base64
not ok 76 - camellia-192-ecb base64
not ok 78 - camellia-256-cbc base64
not ok 80 - camellia-256-ecb base64
not ok 82 - cast base64
not ok 84 - cast-cbc base64
not ok 86 - cast5-cbc base64
not ok 88 - cast5-cfb base64
not ok 90 - cast5-ecb base64
not ok 92 - cast5-ofb base64
not ok 94 - des base64
not ok 96 - des-cbc base64
not ok 98 - des-cfb base64
not ok 100 - des-ecb base64
not ok 102 - des-ede base64
not ok 104 - des-ede-cbc base64
not ok 106 - des-ede-cfb base64
not ok 108 - des-ede-ofb base64
not ok 110 - des-ede3 base64
not ok 112 - des-ede3-cbc base64
not ok 114 - des-ede3-cfb base64
not ok 116 - des-ede3-ofb base64
not ok 118 - des-ofb base64
not ok 120 - des3 base64
not ok 122 - desx base64
not ok 124 - idea base64
not ok 126 - idea-cbc base64
not ok 128 - idea-cfb base64
not ok 130 - idea-ecb base64
not ok 132 - idea-ofb base64
not ok 134 - rc2 base64
not ok 136 - rc2-40-cbc base64
not ok 138 - rc2-64-cbc base64
not ok 140 - rc2-cbc base64
not ok 142 - rc2-cfb base64
not ok 144 - rc2-ecb base64
not ok 146 - rc2-ofb base64
not ok 148 - rc4 base64
not ok 150 - rc4-40 base64
not ok 152 - seed base64
not ok 154 - seed-cbc base64
not ok 156 - seed-cfb base64
not ok 158 - seed-ecb base64
not ok 160 - seed-ofb base64
not ok 162 - sm4-cbc base64
not ok 164 - sm4-cfb base64
not ok 166 - sm4-ctr base64
not ok 168 - sm4-ecb base64
not ok 170 - sm4-ofb base64

Yes, I think so.
Layering the cipher BIOs over a fread BIO don't work at all.

It should work, and I can't quite understand why this makes the tests fail...

The cipher bio has the final block still cached when the outer loop terminates because
of BIO_feof, I think it is not clear which semantic the layered BIO should follow.

Ah, it seems to be flawed...  it doesn't at all account for buf_len - buf_off being non-zero.  So the fault lies in crypto/evp/bio_enc.c

My general feeling here is that BIO is supposed to abstract from the underlying socket
or file BIO but the eof handling does shine thru.  That might be the problem.
When you use a BIO you should not need to know if it has a fread or read underneath the hood?

Hi, in the light of the last post, I think this PR cannot be applied right now... If you don't mind, I'd like to close it for now. (And hopefully retry it later.)

Thanks for your contribution nevertheless, and (hopefully) see you next time!

I think I figured it out...  A check of BIO_pending() was needed as well...


Infer (unspecify) generic type for members in recursively defined classes & interfaces

I didn't find anything similar among the available feature requests, but it's possible that I was just looking badly) So I'm totally ok with closing this suggestion if it duplicate.
Suggestion
In most cases recursive generic structures specify the same parametric types so I suggest ability for skipping fully specify parametric types for cases when it is possible (See examples).
Use Cases
This suggestion remove verbosity and simplify refactoring. On the other hand, it violates the principle of “Explicit is better than implicit”. That's why I suggest use GenericClass without explicit parametric types instead implicit Self like in Rust. Also this approach allows you infer parametric types for base class as well like in Example 2. So apparently it's good balance.
Examples
Example 1
interface TreeNode<T> {
  left:  TreeNode | T,
  right: TreeNode | T
}

which infer as
interface TreeNode<T> {
  left:  TreeNode<T> | T,
  right: TreeNode<T> | T
}

Example 2
class BTree<K, V, Comp> extends BNode<K, V, Comp> {
  children: BNode[]
  constructor(children: BNode[], keys?: K[]) {
    //...
  }
  clone(): BNode {
    //...
  }
}

infers as:
class BTree<K, V, Comp> extends BNode<K, V, Comp> {
  children: BNode<K, V, Comp>[]
  constructor(children: BNode<K, V, Comp>[], keys?: K[]) {
     //...
  }
  clone(): BNode<K, V, Comp> {
    //...
  }
}

Example 3
type ValueOrArray<T> = T | Array<ValueOrArray>;

infers as:
type ValueOrArray<T> = T | Array<ValueOrArray<T>>;

Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

I think this would be confusing especially since typescript already allows omitting type arguments if defaults are specified. This means inside the type it would be clear if the type has defaults, or if this new scheme is being used. Also how would you deal with the case where the type does have default ?
interface TreeNode<T = number> {
  left:  TreeNode | T, // TreeNode is TreeNode<T> or TreeNode<number> ?
  right: TreeNode | T
}

that's good point. I guess parametric types have some omitting precedences (like operator precedences)? Where omitting as default has lowest priority. In this case it should infer as
interface TreeNode<T = number> {
  left:  TreeNode<T> | T,
  right: TreeNode<T> | T
}

I agree with @dragomirtitian -- this would simply be too confusing given that a missing type argument already means "use the default", and there's a desire for it to also mean "perform inference" in other cases.

Regarding this ambiguous case (with default parameters) semantic analyser could just some report and ask to explicitly specify is it TreeNode<T> or TreeNode<number>


feat(common-rollup): add common-rollup package

Coverage decreased (-2.3%) to 85.273% when pulling c2e14a16c00a02ae244690f97aac0bfcb9f91e17 on commonrollup into c29d213c6a76f706a1824c263cb372c0d9bb5425 on dev.


feat: Upgrade to relay 13

Fixes #211
Most of the compiler options have been removed with the rust compiler so you have to use a relay.config.js or the like
e.g.
So the eager es modules are not required anymore
module.exports = {
    language: 'typescript',
    src: './src/.',
    eagerEsModules: true,
    'schema': './schemas/schema.gql',
  };

The pinned graphql version is odd. Explanation here

Depens on #304


docs(material/theming): add tokens section to our docs

Documentation Feedback
Add documentation to material.angular.io to list the tokens that our components expose.
Design
There are still some open questions that the team should discuss.

Should we write a description for each token?

Critiques:

A unique description for every token may be too much data thrown at the user which the user might mentally filter out when looking through our docs.
Many tokens are self-explanatory. It seems silly to write "selected-checkmark-color": The color of the checkmark when the checkbox is selected.

A more useful approach may be to provide a subsection that explains terminology that is obscure to most users. For example, the section could describe the following:

What state-layer commonly refers to.
Listing the different states - active, pressed, etc. Material has a page dedicated to this we could also link to.

Where should this token list live?

IMO under the "API" tab for each component makes the most sense.

This design satisfies the following pain point for our users:

CSS variables are difficult to identify / discover.

Affected documentation page
https://material.angular.io/components/autocomplete/api

Is this refering to things like:

mat-autocomplete-background: The background color of the autocomplete input.
mat-autocomplete-disabled-background: The background color of the autocomplete input when disabled.
mat-autocomplete-overlay-background: The background color of the autocomplete overlay.
mat-autocomplete-border-color: The border color of the autocomplete input.

etc? because I can try to start adding them under the API tab


Style XML output using XSLT

Hello, do you know if there is any way to customize the XML output using https://en.wikipedia.org/wiki/XSLT ? Thanks

Due to the recent developments of Caddy (v2!) and the incompatibility of this plugin with newer versions, as well as not being maintained, I'm closing this issue and archiving the repository.


How to disable the image feed?

There is a red X on the feed, next to the clear button, if you click that it will close.

https://github.com/pythongosssss/ComfyUI-Custom-Scripts/issues/29#issuecomment-1663737093

There is a red X on the feed, next to the clear button, if you click that it will close.

oh thank you and thank you for making this scritp.

How do I get it back after clicking the x?

Click the little 🖼 icon on the menu

Wow that was fast. Thank you!

There's an issue when it's covered.

That's on MS Edge but when I switch to Safari, that panel is detached and I can see the buttons.

@pythongosssss @mizukarada
Same issue on Firefox


Dockerhub very out of date

https://hub.docker.com/r/gambol99/vault-sidekick/
Is there a new location for the dockerfile? or do I need to build my own?

oh found the location while trying to compile my own
https://quay.io/repository/ukhomeofficedigital/vault-sidekick
maybe doc updates for the kubernetes example to use right path?


Exception ignored in: 'kivy.graphics.instructions.RenderContext.set_texture'

Versions

Python: 3.6.7
OS: Debian Testing
Kivy: 1.10.1
Kivy installation method: pip in a virtualenv per the official installation instructions. I've made sure I have the correct version of Cython (0.25.2).

Description
I've successfully run the Pong tutorial without hiccups. However, the following Hello World code taken from the book Kivy: Interactive Applications in Python - Second Edition generates an exception and the buttons appear garbled/corrupted.
Code and Logs
## widgets.py
from kivy.app import App
from kivy.uix.widget import Widget

class MyWidget(Widget):
        pass

class WidgetsApp(App):
        def build(self):
                return MyWidget()

if __name__ == '__main__':
        WidgetsApp().run()

## widgets.kv
<MyWidget>:
        Button:
                text: 'Hello'
                font_size: 32
                color: .8, .9, 1
                pos: 0, 100
                size: 100, 50
        Button:
                text: 'World!'
                font_size: 32
                color: .8, .9, 1
                pos: 100, 0
                size: 100, 50

Here is the log:
[INFO   ] Logger: Record log in /home/garda/.kivy/logs/kivy_18-11-08_5.txt
[INFO   ] Kivy: v1.10.1
[INFO   ] Python: v3.6.7 (default, Oct 21 2018, 08:08:16)
[GCC 8.2.0]
[INFO   ] Factory: 194 symbols loaded
[INFO   ] Image: Providers: img_tex, img_dds, img_sdl2, img_gif (img_pil, img_ffpyplayer ignored)
[INFO   ] Window: Provider: sdl2(['window_egl_rpi'] ignored)
[INFO   ] GL: Using the "OpenGL" graphics system
[INFO   ] GL: Backend used <gl>
[INFO   ] GL: OpenGL version <b'2.1 Mesa 18.1.9'>
[INFO   ] GL: OpenGL vendor <b'Intel Open Source Technology Center'>
[INFO   ] GL: OpenGL renderer <b'Mesa DRI Intel(R) 965GM '>
[INFO   ] GL: OpenGL parsed version: 2, 1
[INFO   ] GL: Shading version <b'1.20'>
[INFO   ] GL: Texture max size <8192>
[INFO   ] GL: Texture max units <16>
[INFO   ] Window: auto add sdl2 input provider
[INFO   ] Window: virtual keyboard not allowed, single mode, not docked
[INFO   ] Text: Provider: sdl2
[INFO   ] Base: Start application main loop
[INFO   ] GL: NPOT texture support is available
[WARNING] stderr: Exception ignored in: 'kivy.graphics.instructions.RenderContext.set_texture'
[WARNING] stderr: Traceback (most recent call last):
[WARNING] stderr:   File "kivy/graphics/texture.pyx", line 789, in kivy.graphics.texture.Texture.bind (/tmp/pip-install-8jmcdld_/kivy/kivy/graphics/texture.c:11612)
[WARNING] stderr:   File "/media/Plain/Codes/kivy/lib/python3.6/site-packages/kivy/core/text/__init__.py", line 662, in _texture_fill
[WARNING] stderr:     self.render(real=True)
[WARNING] stderr:   File "/media/Plain/Codes/kivy/lib/python3.6/site-packages/kivy/core/text/__init__.py", line 603, in render
[WARNING] stderr:     return self._render_real()
[WARNING] stderr:   File "/media/Plain/Codes/kivy/lib/python3.6/site-packages/kivy/core/text/__init__.py", line 586, in _render_real
[WARNING] stderr:     self.render_lines(lines, options, self._render_text, y, size)
[WARNING] stderr:   File "/media/Plain/Codes/kivy/lib/python3.6/site-packages/kivy/core/text/__init__.py", line 564, in render_lines
[WARNING] stderr:     render_text(line, x, y)
[WARNING] stderr:   File "/media/Plain/Codes/kivy/lib/python3.6/site-packages/kivy/core/text/text_sdl2.py", line 48, in _render_text
[WARNING] stderr:     self._surface.render(self, text, x, y)
[WARNING] stderr:   File "kivy/core/text/_text_sdl2.pyx", line 127, in kivy.core.text._text_sdl2._SurfaceContainer.render (/tmp/pip-install-8jmcdld_/kivy/kivy/core/text/_text_sdl2.c:2535)
[WARNING] stderr: IndexError: list index out of range
[WARNING] stderr: Exception ignored in: 'kivy.graphics.instructions.RenderContext.set_texture'
[WARNING] stderr: Traceback (most recent call last):
[WARNING] stderr:   File "kivy/graphics/texture.pyx", line 789, in kivy.graphics.texture.Texture.bind (/tmp/pip-install-8jmcdld_/kivy/kivy/graphics/texture.c:11612)
[WARNING] stderr:   File "/media/Plain/Codes/kivy/lib/python3.6/site-packages/kivy/core/text/__init__.py", line 662, in _texture_fill
[WARNING] stderr:     self.render(real=True)
[WARNING] stderr:   File "/media/Plain/Codes/kivy/lib/python3.6/site-packages/kivy/core/text/__init__.py", line 603, in render
[WARNING] stderr:     return self._render_real()
[WARNING] stderr:   File "/media/Plain/Codes/kivy/lib/python3.6/site-packages/kivy/core/text/__init__.py", line 586, in _render_real
[WARNING] stderr:     self.render_lines(lines, options, self._render_text, y, size)
[WARNING] stderr:   File "/media/Plain/Codes/kivy/lib/python3.6/site-packages/kivy/core/text/__init__.py", line 564, in render_lines
[WARNING] stderr:     render_text(line, x, y)
[WARNING] stderr:   File "/media/Plain/Codes/kivy/lib/python3.6/site-packages/kivy/core/text/text_sdl2.py", line 48, in _render_text
[WARNING] stderr:     self._surface.render(self, text, x, y)
[WARNING] stderr:   File "kivy/core/text/_text_sdl2.pyx", line 127, in kivy.core.text._text_sdl2._SurfaceContainer.render (/tmp/pip-install-8jmcdld_/kivy/kivy/core/text/_text_sdl2.c:2535)
[WARNING] stderr: IndexError: list index out of range
[INFO   ] Base: Leaving application in progress...

Same error here, python 3.7.2

Error disappears if color: is changed to have alpha value, like this: color: .8, .9, 1, 1

I had the same error and, after search a lot and almost punched my pc, I change the color and now it works well...

Button class inherits from Label which has color property in rgba format, so you have to set color in that format to change the color of displayed text. See https://kivy.org/doc/stable/api-kivy.uix.label.html#kivy.uix.label.Label.color .
Maybe a good solution would be to replace ListProperty with ColorProperty for all color-like properties in Kivy widgets.

Pull request https://github.com/kivy/kivy/pull/6918 replaces ListProperty with ColorProperty, so setting color in rgb format will use 1.0 as alpha value and not raise an error. Also a string in format #rrggbb or #rrggbbaa can be used to set the value for color.

Fixed in https://github.com/kivy/kivy/pull/6918.


part 5. MongoDB not connected

After following part 4 and 5 an fixing all errors I'm facing a small problem. First of all can not connect to the server. I get this error:
backend\server.ts:11
Colors.colors('', '');
^
TypeError: Cannot read properties of undefined (reading 'colors')
After commenting this Colors.colors('', '') section I am connected to server, but NOT to database.
Im wondering if it is because this colors package..
What I tried to do:

Do some changes in db.ts like removing colors in those console.logs:
console.log('MongoDB connected'.blue.underline.bold);
console.log(err.message.red.underline.bold);
Check whole code for typos.
Checked whole code for potential sources of problems
Search sollutions in the internet for some tips...

I didnt find sollution for this issue, and will try to fix it on my own, but im running out of ideas..
Maybe somebody faced a similar problem and can help here.

I've had a look at your repo, the colors issue is unrelated to the connection to the DB issue.
Colors:
change import Colors from 'colors.ts' to:
import * as Colors from 'colors.ts';
DB:
You are defining the function db in this line:
export const db = async (): Promise => {
await connectDB();
};
But you are never calling that function. Add this line afterwards:
void db();
That solved your issues on my local, though I also had to fiddle with the tsconfig.json and package.json to get it running properly. In case you have the same issues, I ended up adding:
tsconfig.json:
"target": "es2017",
"module": "Commonjs",
package.json:
"compilerOptions": {
"module": "CommonJS"
},
On top of the existing things. Hope it helps!

Nope, it didnt help. Now throws this:
MONGO_URL is not defined in the env file!
and this is console.log from db.ts.
.env file is ok. I changed the code as you mentioned in the post above, and changed tsconfig.json and package.json
Actually it doesnt matter if this lines are in those json files, it is the same.
I will try to mess around with code to get it connected.

So that's a positive step forward in the debugging process. The error message changed.
In db.ts,   if (MONGO_URI === '' || MONGO_URI === null) {
console.log(
'MONGO_URL is not defined in the env file!'.red.underline.bold
);
process.exit(1);
}
That is throwing the error.
In config.ts, export const MONGO_URI = process.env.MONGO_URI ?? null;
So you have to make sure that the env is correct.
If you want to debug this, I'd suggest going to server.ts, after the imports, before any code and console.log(MONGO_URI) and update the import like such: import { MONGO_URI, PORT } from './utils/config';
What gets console logged? Does your mongo connection url string get console logged out?
But that specific, new error is 100% to do with the .env file and/or the variables names within the env file.

I tried to fix it. console.log shows null, but not url string. After following your alterntive way it shows something different, but im not sure it is a 'positive' kind of error or it just need more debugging.
So it looks like that something is wrong as you suppose with variables names in the .env file. But cant figure it out what would be.  Followed your tips, few times in a row including changes in package.json and tsconfig. Still no sucess.
I uploaded picture how  errors looks like.

Also, I have to ask, are you familiar / have done similar projects before with with Javascript / Node / Express and are following along to learn how to do the same with typescript or is this your first exposure to this?

Problem fixed. With some console.logging and actually messing around in .env file. Changed totally everything and copied mongo string from mongoCompass changed single quotes to double quotes and suddenly it worked.
So, thanks for your help and time. Now Im moving forward and studied the next part. Very good content, Im got some troubles with Postman and generating tokens, Cant figure out how tou use them, but i remember it was in one of your previous videos.
Im familar with JS, Node, express, and databases (mysql2, mongo) Wrote some projects, some of them on my own, some with tutorials. Now im rewriting my old JS projects in Typescript to be more familiar.  so it is not my first  exposure to TS.
In addition Im on half way through 1 year long complete JS course (JS, node, express, db, tscript, react, nest).


pretrained model on scene flow dataset

Hi @JiaRenChang ,
Thanks for your excellent work. Could you please release your pretrained model on scene flow dataset?

@shanyuhu
We will put it on the github soon.

Thanks, looking forward to your update!


RFC: Bring in the attrs plugin from mypy

Note: The lint tests are failing because mypy code is 120 vs 79 here.  I plan to fix those but there are some bikesheds to decide first:

Is the incantation:

[mypy]
plugins = attr.mypy

what we want?  It's how https://github.com/samuelcolvin/pydantic/tree/master/pydantic ships its plugin and it seemed neater than how sqlalchemy-stubs does it.  (They ship a separate module but it looks like this)
[mypy]
plugins = sqlmypy

I know people have been clamoring to fix the "How do I make my method an attr.s method". Are we ok with landing this as is and then in a later revision adding that, possibly breaking whatever hacks people have already written?  i.e. do we need to worry about any backwards compatibility issues?
Do we wish to preserve any of the history from the mypy repo?
Any licensing issues?

Tagging the following people since you contributed to the attrs plugin on mypy:
@ilevkivskyi @msullivan @JukkaL @Zac-HD @tkukushkin @Bogdanp
@natemcmaster @Michael0x2a @markusschmaus @ceh
Please let me know if this is a huge problem.  And let me know if you want me to somehow preserve the history of the file changes (or just your contribution).  This is completely new territory for me.  I'm not trying to just steal people's hard work. I'm just trying to make it easier for attrs to maintain the plugin outside of the regular mypy release cycle.
Pull Request Check List
This is just a friendly reminder about the most common mistakes.  Please make sure that you tick all boxes.  But please read our contribution guide at least once, it will save you unnecessary review cycles!
If an item doesn't apply to your pull request, check it anyway to make it apparent that there's nothing left to do.  If your pull request is a documentation fix or a trivial typo, feel free to delete the whole thing.

[ ] Added tests for changed code.
[ ] New features have been added to our Hypothesis testing strategy.
[ ] Changes or additions to public APIs are reflected in our type stubs (files ending in .pyi).

[ ] ...and used in the stub test file tests/typing_example.py.

[ ] Updated documentation for changed code.

[ ] New functions/classes have to be added to docs/api.rst by hand.
[ ] Changes to the signature of @attr.s() have to be added by hand too.
[ ] Changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated directives.  Find the appropriate next version in our __init__.py file.

[ ] Documentation in .rst files is written using semantic newlines.
[ ] Changes (and possible deprecations) have news fragments in changelog.d.

If you have any questions to any of the points above, just submit and ask!  This checklist is here to help you, not to deter you from contributing!

I know people have been clamoring to fix the "How do I make my method an attr.s method". Are we ok with landing this as is and then in a later revision adding that, possibly breaking whatever hacks people have already written? i.e. do we need to worry about any backwards compatibility issues?

As one of the people clamoring for this I think taking a little while to get this right is more important than backwards comp right now.

I know people have been clamoring to fix the "How do I make my method an attr.s method". Are we ok with landing this as is and then in a later revision adding that, possibly breaking whatever hacks people have already written? i.e. do we need to worry about any backwards compatibility issues?

Unfortunately I'm busy until next year, but could you elaborate what this means please? Would embracing this break my attrs-ng plugin?
(I like attr.mypy better I think)

Would embracing this break my attrs-ng plugin?
Yes and no.  Your plugin currently does this:

from mypy.plugin import Plugin
from mypy.plugins.attrs import attr_attrib_makers, attr_dataclass_makers

attr_dataclass_makers.add("attr.define")
attr_dataclass_makers.add("attr.mutable")
attr_dataclass_makers.add("attr.frozen")
attr_attrib_makers.add("attr.field")

Which will pretty much do nothing because it's trying to patch mypy.plugins.attrs
However the plugin in attr.mypy actually supports attrs-NG so there's no need for this.
But what I'm talking about is the attr_dataclass_makers.add("attr.define") itself.  Maybe we change it so that you can configure it using mypy.ini config file or some other thing like register_attr_dataclass_maker(...) or something like that.  How important is it to preserve this "hack" for backwards compatibility.  (And do we even want to answer this right now?)

I really don't want to break anything and that would actually break almost all of my work projects. :D
But let's back up a little. If I understand it correctly, people will have to opt in to use our plugin and otherwise they'll fall back to mypy, is that correct? That would mean that we wouldn't break anything and people would have to touch their mypy.ini anyways, correct?
I mean mid-term we could ask mypy to automatically recognize our plugin, but ISTM we have some leeway thanks to this?

I really don't want to break anything and that would actually break almost all of my work projects. :D

I think I lost the meaning of "that" in this sentence.  Could you elaborate what would break almost all your work projects?

But let's back up a little. If I understand it correctly, people will have to opt in to use our plugin and otherwise they'll fall back to mypy, is that correct? That would mean that we wouldn't break anything and people would have to touch their mypy.ini anyways, correct?

We could also remove the plugin from mypy.  In fact we should otherwise we'll get version skew bug reports which would be really annoying.  In mypy we could error out when it sees an attr.s and tell you to install the plugin.

I mean mid-term we could ask mypy to automatically recognize our plugin, but ISTM we have some leeway thanks to this?

Are you suggesting that something in mypy detect that the code is using attrs and load our plugin?   This could be possible but I think it might have a lot of weird issues because it changes when our plugin gets intialized by the mypy plugin system and who knows what else.
Is having to modify mypy.ini a deal breaker?

I don't have a strong opinion on this, but I have a few concerns:

The plugin uses a bunch of undocumented, internal mypy APIs that are not necessarily stable. It's possible that updating mypy could break the attrs plugin (at least older versions of the plugin, if we are careful to keep attrs and mypy in sync). This is my main concern. Maybe we'd continue to test the plugin in mypy CI to catch regressions -- but this would effectively turn these APIs into stable APIs.
It may become unclear which mypy versions are supported by the plugin, and the plugin may accidentally break on older mypy versions that are still in active use. It would be nice if attrs CI could test the plugin using the oldest supported mypy version and the latest one. If somebody tries to use the plugin on an unsupported mypy version, the plugin probably shouldn't crash but suggest updating to a more recent mypy version.
As proposed above, mypy should start suggesting to install attrs and enabling the plugin, as otherwise users could silently lose some type checking precision. In case a mypy user doesn't want to use the plugin shipped with attrs for some reason, we can make it possible to ignore the error by giving it a unique mypy error code (this needs to be documented, however).

I don't have a strong opinion on this, but I have a few concerns:

The plugin uses a bunch of undocumented, internal mypy APIs that are not necessarily stable. It's possible that updating mypy could break the attrs plugin (at least older versions of the plugin, if we are careful to keep attrs and mypy in sync). This is my main concern. Maybe we'd continue to test the plugin in mypy CI to catch regressions -- but this would effectively turn these APIs into stable APIs.
It may become unclear which mypy versions are supported by the plugin, and the plugin may accidentally break on older mypy versions that are still in active use. It would be nice if attrs CI could test the plugin using the oldest supported mypy version and the latest one. If somebody tries to use the plugin on an unsupported mypy version, the plugin probably shouldn't crash but suggest updating to a more recent mypy version.
As proposed above, mypy should start suggesting to install attrs and enabling the plugin, as otherwise users could silently lose some type checking precision. In case a mypy user doesn't want to use the plugin shipped with attrs for some reason, we can make it possible to ignore the error by giving it a unique mypy error code (this needs to be documented, however).

Hey Jukka, thanks for chiming in!

Maybe we'd continue to test the plugin in mypy CI to catch regressions -- but this would effectively turn these APIs into stable APIs.

Correct me if I'm wrong, but aren't they de-facto stable already? How are pydantic and sqlalchemy stubs handle this?

It would be nice if attrs CI could test the plugin using the oldest supported mypy version and the latest one. If somebody tries to use the plugin on an unsupported mypy version, the plugin probably shouldn't crash but suggest updating to a more recent mypy version.

That seems reasonable.

As proposed above, mypy should start suggesting to install attrs and enabling the plugin, as otherwise users could silently lose some type checking precision. In case a mypy user doesn't want to use the plugin shipped with attrs for some reason, we can make it possible to ignore the error by giving it a unique mypy error code (this needs to be documented, however).

Long-term I would really like to make it opt-out, not opt-in. I.e. mypy picks up attrs's plugin automatically and there should be a switch to disable that – would you find that reasonable?

Hey Jukka, thanks for chiming in!

Maybe we'd continue to test the plugin in mypy CI to catch regressions -- but this would effectively turn these APIs into stable APIs.

Correct me if I'm wrong, but aren't they de-facto stable already? How are pydantic and sqlalchemy stubs handle this?

It would be nice if attrs CI could test the plugin using the oldest supported mypy version and the latest one. If somebody tries to use the plugin on an unsupported mypy version, the plugin probably shouldn't crash but suggest updating to a more recent mypy version.

That seems reasonable.

As proposed above, mypy should start suggesting to install attrs and enabling the plugin, as otherwise users could silently lose some type checking precision. In case a mypy user doesn't want to use the plugin shipped with attrs for some reason, we can make it possible to ignore the error by giving it a unique mypy error code (this needs to be documented, however).

Long-term I would really like to make it opt-out, not opt-in. I.e. mypy picks up attrs's plugin automatically and there should be a switch to disable that – would you find that reasonable?

I really don't want to break anything and that would actually break almost all of my work projects. :D
I think I lost the meaning of "that" in this sentence. Could you elaborate what would break almost all your work projects?

Not having some attrs plugin active by default.

I mean mid-term we could ask mypy to automatically recognize our plugin, but ISTM we have some leeway thanks to this?

Are you suggesting that something in mypy detect that the code is using attrs and load our plugin? This could be possible but I think it might have a lot of weird issues because it changes when our plugin gets intialized by the mypy plugin system and who knows what else.

Yeah, that's what I'm suggesting. If it's not possible, so be it but it would be really nice if we could make that work.

Is having to modify mypy.ini a deal breaker?

Not a deal breaker per se, but it's definitely a usability regression (especially over dataclasses) that I would like to get rid of eventually. Also it's breaking backward-compat.

I really don't want to break anything and that would actually break almost all of my work projects. :D
I think I lost the meaning of "that" in this sentence. Could you elaborate what would break almost all your work projects?

Not having some attrs plugin active by default.

I mean mid-term we could ask mypy to automatically recognize our plugin, but ISTM we have some leeway thanks to this?

Are you suggesting that something in mypy detect that the code is using attrs and load our plugin? This could be possible but I think it might have a lot of weird issues because it changes when our plugin gets intialized by the mypy plugin system and who knows what else.

Yeah, that's what I'm suggesting. If it's not possible, so be it but it would be really nice if we could make that work.

Is having to modify mypy.ini a deal breaker?

Not a deal breaker per se, but it's definitely a usability regression (especially over dataclasses) that I would like to get rid of eventually. Also it's breaking backward-compat.


#1172, for comments

Fixes #1172.

Pull Request Test Coverage Report for Build 5026

9 of 12 (75.0%)  changed or added relevant lines in 3 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.01%) to 63.278%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

sharding-jdbc/src/main/java/io/shardingsphere/core/jdbc/adapter/AbstractConnectionAdapter.java
6
9
66.67%

Files with Coverage Reduction
New Missed Lines
%

sharding-orchestration/sharding-orchestration-reg/src/main/java/io/shardingsphere/orchestration/reg/newzk/client/zookeeper/base/Holder.java
2
70.49%

Totals

Change from base Build 5025:
-0.01%

Covered Lines:
7999

Relevant Lines:
12641

💛  - Coveralls


[RV_DM,dv] Add mem_tl_access_halted test

I have added a new test sequence of RV_DM. Kindly review it.

Can you rebase and push again? It has conflict.


Fix deadlock issue in HTTP2 connector

Fix for #16427
Some tcp connect implementations require flushing closures before returning. This would result in a deadlock for the connector because the closure itself needs a lock, and currently the closure would be run while holding the lock.

****************************************************************

libgrpc.so

     VM SIZE              FILE SIZE
 ++++++++++++++ GROWIN ++++++++++++++
  [ = ]       0 [None]    +312  +0.0%

  [ = ]       0 TOTAL     +312  +0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,997,278      Total (>)      1,997,274

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
11,021,705      Total (>)     11,021,701

 No significant differences in binary sizes

Corrupt JSON data (indicates timeout or crash):
    bm_call_create.BM_IsolatedFilter_ClientChannelFilter_NoOp_.counters.new: 10
    bm_call_create.BM_IsolatedFilter_ClientChannelFilter_NoOp_.counters.old: 10

[microbenchmarks] No significant performance differences

From a quick glance, this looks reasonable to me, but @ncteisen should review.

So grpc_tcp_client_connect is now doing all of its mutations outside of a lock? How do we have a guarantee that the things it is touching won't be modified or deallocated? Could you add a note in the code about how this is safe

From what I see, only c->endpoint is going to be changed, and it actually going to be populated by connect.  All other places seem to be only triggerred after connect is done or in shutdown. For the shutdown case, we set connecting = true to avoid races there.

Added a comment

****************************************************************

libgrpc.so

     VM SIZE              FILE SIZE
 ++++++++++++++ GROWIN ++++++++++++++
  [ = ]       0 [None]    +312  +0.0%

  [ = ]       0 TOTAL     +312  +0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

****************************************************************

libgrpc.so

     VM SIZE                                               FILE SIZE
 ++++++++++++++ GROWING                                 ++++++++++++++
  +0.0%     +92 [None]                                  +1.46Ki  +0.0%
  +2.5%     +28 src/core/lib/iomgr/tcp_client_custom.cc     +28  +2.5%
      [NEW]    +176 custom_connect_callback_internal           +176  [NEW]

  +0.0%    +120 TOTAL                                   +1.48Ki  +0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 2,014,177      Total (>)      2,014,173

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
11,113,481      Total (<)     11,113,482

 No significant differences in binary sizes

[trickle] No significant performance differences

Corrupt JSON data (indicates timeout or crash):
    bm_call_create.BM_IsolatedFilter_ClientChannelFilter_NoOp_.counters.new: 10
    bm_call_create.BM_IsolatedFilter_ClientChannelFilter_NoOp_.counters.old: 10

[microbenchmarks] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 2,014,177      Total (>)      2,014,173

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
11,113,701      Total (>)     11,113,473

 No significant differences in binary sizes

Corrupt JSON data (indicates timeout or crash):
    bm_call_create.BM_IsolatedFilter_ClientChannelFilter_NoOp_.counters.new: 10
    bm_call_create.BM_IsolatedFilter_ClientChannelFilter_NoOp_.counters.old: 10

[microbenchmarks] No significant performance differences


Edit host not work

In setting menu edit host not work

Dear mir,
I explained that you should give permission to the file and file exactly should be in requested path  or you should change the path in app.
Thanks for your attention,
Pooyan


[Fix](inverted index) fix empty array index writer bug

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

It's better to provide the bug stacktrace .


[WFLY-14587] JCA subsystem: throw parsing exception if name for workm…

…anager pools is configured
https://issues.redhat.com/browse/WFLY-14587
I believe this is not a model change but a bug fix. The name was never a part of a model was a side effect of delegating parsing to jboss-threads. Otoh, I think that current naming in which thread pool matches workmanager name is pretty clean and I would vote for not changing it.
@ehsavoie FYI

@rhusar  fixed (I have reverted log removal as it is necessary with CLI usage)

Having [long|short]-running-thread-pool be resources instead of ObjectTypeAttributeDefinition attributes is the fundamental flaw here; that's why these things have names. But the effort to correct that would be pretty high, even ignoring the backward compatibility code that would be needed. Between this and WFLY-14579 we have reasonable behavior.

Thanks @tadamski and @rhusar


Add AWS-LC pre-processor directive similar to BoringSSL

Resolved issues:
CryptoAlg-549
Description of changes:
When using BoringSSL as the cryptographic provider a number of features are disabled during pre-compilation:

ChaCha20-Poly1305
Composite ciphers
OCSP
HMAC through the EVP API
Setting custom randomness callback
X25519

This PR disables the same features for AWS-LC using the AWS-LC-specific pre-compilation macro: OPENSSL_IS_AWSLC.
This change is necessary before enabling AWS-LC as a cryptographic provider dimension in the S2N CI.
Call-outs:
Subsequent PR's will add AWS-LC to the S2N CI and re-enable features as they get introduced.
Testing:
Produced artefacts from an AWS-LC build with OPENSSL_IS_AWSLC defined. Linked S2N against these artefacts and ran unit tests on AL2:
$ ctest3 --output-on-failure

Ran integration tests on Ubuntu for BoringSSL:
$ S2N_LIBCRYPTO=boringssl BUILD_S2N=true TESTS=integration GCC_VERSION=9
$ source codebuild/bin/s2n_setup_env.sh
$ codebuild/bin/s2n_install_test_dependencies.sh
$ codebuild/bin/s2n_codebuild.sh

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #2273 into main will decrease coverage by 0.00%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main    #2273      +/-   ##
==========================================
- Coverage   80.72%   80.72%   -0.01%
==========================================
  Files         265      265
  Lines       17872    17873       +1
==========================================
  Hits        14428    14428
- Misses       3444     3445       +1


Backups Failing...

I can't seem to get this working...here is the output when I try to run the container:
DEBU[0000] Using /backups to match uid and gid
DEBU[0000] Resolved UID=1000 from match path
DEBU[0000] Resolved GID=1000 from match path
[20:37:04.002][info    ] Initializing Bedrockifier Daemon
[20:37:04.003][info    ] Loading Configuration From: /backups/config.yml
[20:37:04.006][info    ] Configuration Loaded, Entering Event Loop...
[20:37:04.051][info    ] Host PTY Handle Opened: /dev/pts/1 (3)
[20:37:04.052][info    ] Child PTY Handle Opened: /dev/pts/1 (4)
[20:37:04.052][info    ] Backup Interval: 10800.0 seconds
[20:37:04.053][info    ] Starting Full Backup
[20:37:04.131][error   ] Docker was blocked from accessing docker.sock, make sure UID/GID are set correctly
[20:37:04.131][error   ] Container mc_murder_land failed to backup properly
[20:37:04.131][info    ] Performing Trim Jobs
[20:37:04.132][info    ] Full Backup Completed
[20:37:04.132][error   ] The operation could not be completed. (PTYKit.PTYError error 4.)
[20:37:04.133][error   ] Full Backup Failed

Now, it seems to be a problem accessing "docker.sock" but I'm not sure how to go about fixing it.
This file is located here:  /var/run/docker.sock
With these permissions:  srw-rw---- 1 root docker
I'd love a nudge in the right direction...

Ok, seemed to have fixed the docker.sock issue by setting the GID in the docker-compose.yml file to match the "docker" group.
Now, I have a new error:
DEBU[0000] Using /backups to match uid and gid
DEBU[0000] Resolved UID=1000 from match path
DEBU[0000] Resolved 999 from environment variable GID
[21:10:17.200][info    ] Initializing Bedrockifier Daemon
[21:10:17.202][info    ] Loading Configuration From: /backups/config.yml
[21:10:17.204][info    ] Configuration Loaded, Entering Event Loop...
[21:10:17.234][info    ] Host PTY Handle Opened: /dev/pts/1 (3)
[21:10:17.235][info    ] Child PTY Handle Opened: /dev/pts/1 (4)
[21:10:17.236][info    ] Backup Interval: 10800.0 seconds
[21:10:17.236][info    ] Starting Full Backup
[21:10:27.239][error   ] Server container failed to pause autosave before timeout was reached
[21:10:27.239][error   ] Container mc_murder_land failed to backup properly
[21:10:27.239][info    ] Performing Trim Jobs
[21:10:27.241][info    ] Full Backup Completed

Ok, so looks like there was also an small error in my config.yml file.  Problem solved now.

Glad to see you were able to work through it.  This error should have been more descriptive: “[20:37:04.132][error   ] The operation could not be completed. (PTYKit.PTYError error 4.)“, but the code looks okay, so I don’t want to go chasing phantoms unless this was a recent pull.
Also, you can chown the backups folder to the docker group (so something like me:docker) and the entrypoint demoter will pick up the GID that way as well. But either way works.

@elietech
Care to share what caused this? I have the same issue.

I got it working by setting stdin_open and tty to true in docker-compose.


TypeError: coreTracing.createTracingClient is not a function

@azure/storage-blob:
12.23.0:
Ubuntu22:
[x] nodejs

20.11.0:

[x] typescript

5.5.2:

Describe the bug
When I run test case, it throws error.
I downgraded version to 12.18.0, it works, but it doesn't work with 12.23.0
TypeError: coreTracing.createTracingClient is not a function

    4 |
    5 | import { DefaultAzureCredential } from '@azure/identity';
  > 6 | import {
      | ^
    7 |   BlobCopyFromURLResponse,
    8 |   BlobDeleteIfExistsResponse,
    9 |   BlobDeleteOptions,

    at Object.<anonymous> (node_modules/@azure/storage-blob/src/utils/tracing.ts:11:30)
    at Object.<anonymous> (src/azure/storage.ts:6:1)
    at Object.<anonymous> (src/azure/index.ts:1:1)
    at Object.<anonymous> (tests/azure/storage.test.ts:3:1)

Seems like an issue where the new version of @azure/storage-blob needs to bump its minimum dependency on @azure/core-tracing -- @StanislavHT can you tell me what version of core-tracing was being loaded when you got the failure?

@xirzec
Now I'm using @azure/storage-blob 12.18.0, @azure/core-tracing 1.0.1 and it works.
I'm not sure @azure/core-tracing version for @azure/storage-blob 12.23.0

+1 to this, we faced the exact same issue with our server. reverting back to 12.18.0 fixed it for us as well

Seems like an issue where the new version of @azure/storage-blob needs to bump its minimum dependency on @azure/core-tracing -- @StanislavHT can you tell me what version of core-tracing was being loaded when you got the failure?

Faced the same problem with 12.24.0. @azure/core-tracing was at version 1.1.2.
Reverting to 12.18.0 switched back to @azure/core-tracing 1.0.0-preview.13

This issue is still active in 12.24.0 and updates of @azure/storage-blob to newer versions than 12.18.0 are not possible. Is there any roadmap to fix this? The urgency should be increased since without the fix updates of @azure/storage-blob are not possible and projects, which are running in highly regulated environments with the obligation to keep their 3rd party dependencies up to date will need to deal with compliance findings.

Hi All,
I cannot reproduce the issue. Maybe it only happens in some specific environment. Could anyone help to provide a little repro project?

Continuing the conversation from #31242 - @dhowell2000 (or other folks here) could you share more information or a small repro project that can be used to reproduce the issue?
You mentioned that things work fine locally, but not when pushing to Azure Web App. Do you have a lockfile that could be pulling an older version of core-tracing?
If you can, please run npm ls @azure/core-tracing in an environment that reproduces the issue and let us know the results. We'll continue investigating on our end

It works fine on my development box (vscode on a mac)
When i push to my Azure Web App it breaks. I opened a Kudo console to the Web App and ran your requested command. This is what i got:
DEBUG CONSOLE | AZURE APP SERVICE ON LINUX
Documentation: http://aka.ms/webapp-linux
Kudu Version : 20240822.2
Commit : a86ad9d31002b0e2111a20f21ebaeae4be986b94
kudu_ssh_user@a84d3d69020e:/$ npm ls @azure/core-tracing
/
└── (empty)
kudu_ssh_user@a84d3d69020e:/$
Here is the dependency part of my package.json
"dependencies": {
"@azure/communication-email": "^1.0.0",
"@azure/communication-sms": "^1.1.0",
"@azure/core-tracing": "^1.1.2",
"@azure/identity": "^4.4.1",
"@azure/keyvault-keys": "^4.8.0",
"@azure/keyvault-secrets": "^4.8.0",
"@azure/monitor-opentelemetry": "^1.7.1",
"@azure/storage-blob": "^12.25.0",
"@ffmpeg-installer/ffmpeg": "^1.1.0",
"apn": "^2.2.0",
"applicationinsights": "^3.3.0",
"chalk": "^4.1.2",
"dayjs": "^1.11.11",
"dotenv": "^16.3.1",
"express": "^4.18.2",
"ffmpeg-static": "^5.2.0",
"fluent-ffmpeg": "^2.1.3",
"json5": "^2.2.3",
"jsonwebtoken": "^9.0.2",
"mongodb": "^6.8.0",
"mongoose": "^8.0.3",
"ms": "^2.1.3",
"multer": "^1.4.5-lts.1",
"sharp": "^0.33.4",
"swagger-jsdoc": "^6.2.8",
"swagger-ui-express": "^5.0.1",
"uuid": "^10.0.0",
"ws": "^8.18.0"
},
"devDependencies": {
"chai": "^5.1.1",
"jest": "^29.7.0",
"mocha": "^10.7.3",
"supertest": "^7.0.0",
"swagger-autogen": "^2.23.7"
},
"pkg": {
"scripts": [
"bin/www",
"api/v1/v1ApiDiscoveryRouter.js"
],
"assets": [
"public//",
"views//",
"config/**/",
"bin//",
"node_modules/sharp//*",
"node_modules/open/xdg-open"
],
"targets": [
"node16-macos-x64"
]
}
}

it works in Azure if i go back to this:
"@azure/storage-blob": "12.18.0",

I'm not sure that when i run the npm ls @azure/core-tracing command it is working though. i just tried it against @azure/storage-blob on my working service and got the same empty result.

it appears i was in the wrong directory when i ran the bash command that returned the empty result. If needed i can redeploy the broken state tomorrow and run it.

Yes, that would be great - let us know what outputs then.

since it isn't listed as a dependency in the working case (so maybe not needed by 12.18), i am wondering if you took a dependency post 12.18 and forgot to somehow register it.

It's possible but right now I don't think likely. I'll give some context here that might help.

<EMAIL_ADDRESS>depends on<EMAIL_ADDRESS><EMAIL_ADDRESS>depends on<EMAIL_ADDRESS>createTracingClient was added to @azure/core-tracing as part of GA version (1.0.0)

Technically I believe it was added in preview.14 but for all intents and purposes we can focus on preview.13 vs 1.0.0

When I see coreTracing.createTracingClient is not a function, my first hunch is that @azure/storage-blob is still finding preview.13 of core-tracing which does not have createTracingClient.
Theoretically this should all work seamlessly when you update your dependencies - when you update a dependency and run npm update <name> (or npm install after updating package.json, npm (or yarn or pnpm)) npm should resolve correctly and make any updates necessary to transitive dependencies.
I've seen cases where partial updates or other dependency resolution changes are not fully applied, and the new version of a package continues "finding" the older version of its dependency.
Some things that have helped in the past

Deleting node_modules and package-lock.json , then running npm install is the most likely way to fix the dependency resolution issues; however, this is not always possible or feasible.
Running npm ls @azure/core-tracing (or yarn why or pnpm list depending on your package manager) should list out all transitive and direct dependencies on @azure/core-tracing. This could help find older versions of core-tracing still hanging around
All else fails, I do believe the workaround listed here should help https://github.com/Azure/azure-sdk-for-js/issues/30147#issuecomment-2327198020

Hope this helps a bit, and possibly offers some debugging / workaround tips, but of course we want to help so feel free to reach out with any information that may help us repro this!

Thanks for the info.
This is ONLY happening when I push to an Azure Web App. Not when I build and run locally. (BTW explicitly adding core tracing to the dependencies didn't work for me.)
So if your theory of an older preview "hanging around" is correct, it is only happening in Azure (for me). I could see that might happen if Azure "upgrades" vs "clean installs" since my web app has been around for a while. I'm not sure how Azure handles the update pushes. I use a GitHub action to push and deploy in Azure.
How do I clean out Azure properly to force the preview to be cleared? And as a second question isn't this an Azure bug/issue.

Thanks for the info.
This is ONLY happening when I push to an Azure Web App. Not when I build and run locally. (BTW explicitly adding core tracing to the dependencies didn't work for me.)

Right, I know this. It would be great to know what npm ls @azure/core-tracing from the project directory returns when its in a bad state.

So if your theory of an older preview "hanging around" is correct, it is only happening in Azure (for me). I could see that might happen if Azure "upgrades" vs "clean installs" since my web app has been around for a while. I'm not sure how Azure handles the update pushes. I use a GitHub action to push and deploy in Azure.
How do I clean out Azure properly to force the preview to be cleared?

As a test you could deploy to a new environment

And as a second question isn't this an Azure bug/issue?

It may be, and we would love to get it sorted out, but it's relatively rare and we've been unable to reproduce the issue. Any repro steps would be very helpful! @azure/core-tracing gets roughly 7 million downloads per week. @azure/storage-blob gets roughly 2 million downloads per week with ~50% of those being 12.23 and higher. By comparison, reports of this issue have been very rare.
To be clear, we don't want to see anyone struggle here - with a minimal repro we'd love to get to the bottom of it and help y'all. Some workarounds have been posted but ideally would not be needed if we can get a stable repro of the issue

Well I'm facing this issue with @azure/storage-blob=^12.14.0