text:
Sync mDNS first browse

Signed-off-by: Joni Collinge jonathancollinge@live.com
Description
As discussed in dapr/java-sdk#709 the mDNS name resolver can result in inconsistent performance. I added a concurrency test to understand better how it was behaving and it did indeed suffer poor performance when concurrently called. I believe this was because if the appID was not in the cache, all the concurrent requesters would perform a mDNS browse - to which only some would get a response - this meant others would periodically retry (every 4 seconds) until they got a response and eventually returned the correct address. I've updated this so that when the appID is not in the cache, the first browse is only done by 1 requester per appID and that requester pushes the result to the other waiters via a channel. This has allowed me to run the concurrency test with 1000 requesters and have them all resolve within ~3 seconds.
However, there is still some behaviour I need to understand better. If you perform the test with 1 requester, the test takes 0.254s, if you perform the test with 2 requesters then the test takes 3.2s, if you perform the test with 1000 requesters the test takes 3.2s. I've ran a pprof profile against the test but it hasn't given me much insights - I will continue to dig into this to try and understand better why this is the case.
Issue reference
We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.
Please reference the issue this PR will close: #dapr/dapr/4323
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[x] Created/updated tests
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

It does appear that the 3s correlates to the refreshTimeout, for every unique appID you get (n-1) * 3s delay.

@mukundansundar there tests were flaky as there is no Close() method on the Resolver interface yet (raised https://github.com/dapr/components-contrib/issues/1472) - I've decided to go ahead and implement the Close method on this resolver and use it in the tests to stop all the goroutine leaks etc. and make sure they run cleanly.

Ok I believe I fixed that issue - I can now safely remove the catch all and scale to 100,000s without issue. I will keep the catch all in place just in case but I do not expect it to be used.

@jjcollinge Is there some flakiness added to the test for mdns? I am seeing that it failed in Darwin alone and windows got cancelled ....

I'll investigate

@mukundansundar so this is a balancing act - the previous tests were "flakey" because they took too long to get the address and timed out - I think this was because they were trying to do 50,000 concurrent ResolveID requests and this suffers performance degradation due to lock contention. We cannot support infinite concurrent requesters in finite time so we'll need to decide what behaviour we want. We can keep the timeout at 2 seconds and at some scale this will start to return timeout errors or we remove the timeout and just let the resolver get slower and slower. It probably makes a lot more sense to use 1000 concurrent requesters in the test. WDYT?

@mukundansundar so this is a balancing act - the previous tests were "flakey" because they took too long to get the address and timed out - I think this was because they were trying to do 50,000 concurrent ResolveID requests and this suffers performance degradation due to lock contention. We cannot support infinite concurrent requesters in finite time so we'll need to decide what behaviour we want. We can keep the timeout at 2 seconds and at some scale (hardware depending) this will start to return timeout errors (which is what failed the tests) or we remove the timeout and just let the resolver get slower and slower but not return errors. It probably makes a lot more sense to use 1000 concurrent requesters in the test as this is not a high perf runner and we probably don't expect more than 1000 concurrent calls to ResolveID before the cache is populated in an actual Dapr deployment. On my MBP I can run 300k without hitting the timeout. WDYT? Let's hold off merging this until I can confirm my theory.

As you rightly put it is a balancing act.
Do you think 1000 concurrent requests might cause issues with low powered dev laptops? And would that cause a flaky test when developer runs the test locally?

@mukundansundar I wouldn't think it would causes issues - but I guess we want to be on the safe side here as the importance of this tests is really to exercise the concurrent code path and that can be done at much lower concurrency levels. I will reduce it from 1000 to 100 as that should be high enough to highlight any issues but low enough to not be flakey on any hardware.

@mukundansundar I'm fairly happy this is working as expected and I've reduced the concurrency levels to 100. I've just ran this test suite through a few hundred times on my machine (with no cache) and they all passed.

authors: jjcollinge mukundansundar


text:
Add context in bindings interface

Signed-off-by: pigletfly wangbing.adam@gmail.com
Description
add context.Context in bindings interface.
Issue reference
https://github.com/dapr/dapr/issues/2716
https://github.com/dapr/components-contrib/issues/1601
We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.
Please reference the issue this PR will close: #[issue number]
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[x] Created/updated tests
[x] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

This PR looks good, but we shouldn't reorder the imports like this :)

Also as you can see the stable components certification tests for bindings will fail because of this PR. You will need to update the runtime to set the context, and then you will need to update those tests as I mentioned before.

ok, I will update this PR step by step

@daixiang0 could you help to review this PR and trigger the CI workflow ?

@pigletfly the CI workflow already ran when you pushed to it. There is still a linter failure -- you need to gofumpt the files you modified.
There is no need to also get a review from @daixiang0 since I am a maintainer, but feel free. Once you fix the linter issues (by making components-contrib / Build linux_amd64 pass) I can approve and merge this.
In the meantime, could you please start making the dapr/dapr PR? You can later update that PR by adding a commit with the go.mod and go.sum update to import the latest contrib via go get github.com/dapr/components-contrib@master, we really want to be quick about merging all of these things so that our tests will not be failing for a longer period of time.

Thanks for already updating the certification tests @pigletfly. By the way it is expected that these will fail at this time.
That's why it is important we get the dapr/dapr created and merged soon, and then another PR for contrib for the submodule test/certification to pin the latest dapr/dapr there.

@berndverst I pinged @daixiang0 because we are in the same time zone. PR in dapr/dapr https://github.com/dapr/dapr/pull/4550

@pigletfly unfortunately even as a maintainer I cannot merge this because of the breaking certification tests -- I will need to work with a steering committee member to force merge this. Maintainers do not have this power unfortunately.
Maybe @yaron2 or @artursouza can help out here.
Certification test failures are expected as discussed. To resolve those failures we must merge https://github.com/dapr/dapr/pull/4550 (and bring in the latest contrib with this very PR here), then we need to update the certification tests to pin the latest dapr/dapr.

sounds like there is a circular dependency between dapr/dapr and dapr/components-contrib ?

@pigletfly sort of -- the main issue is that the stable certification tests are a submodule within contrib. That has some advantages (e.g. you can immediately run certification tests when you modify a component due to the local replace directive) but it also has the disadvantage of this complicated process whenever you change the Dapr runtime.

thanks for your detailed explanations. @berndverst

source: gharchive/pull-request

authors: berndverst pigletfly

repo: dapr/components-contrib

license_type: permissive

license_source: github-api


text:
STATE - Get State Operation should support sending metadata

The client state operations for "get" does not take a metadata dictionary.
This makes using "partitionKey" in the cosmos state component "impossible".
cosmos state component usage.

cc @yaron2 @youngbupark

ack. I think this should be P1 ?

@yaron2 @amanbha do we want to fix this in this milestone? In this case, we need to add metadata property to all state apis.
cc/ @orizohar @msfussell @yolember

@youngbupark this will not be breaking, correct? its addition to existing api and given that today is code freeze, it can come in next release.

@youngbupark this will not be breaking, correct? its addition to existing api and given that today is code freeze, it can come in next release.

this should not be a breaking change. it is just addition.

source: gharchive/issue

authors: amanbha perokvist youngbupark

repo: dapr/dapr


text:
Dapr runtime panic when handle Pub/Sub without CloudEvents  status retry or drop

In what area(s)?

/area runtime
What version of Dapr?

1.2.0
panic log
panic: interface conversion: interface {} is nil, not string

goroutine 106 [running]:
github.com/dapr/dapr/pkg/runtime.(*DaprRuntime).publishMessageHTTP(0xc0001e0d80, 0x4998520, 0xc0000b9800, 0xc000a0a740, 0x44df401, 0xc000a0a740)
	/Users/runner/work/dapr/dapr/pkg/runtime/runtime.go:1222 +0x163f
github.com/dapr/dapr/pkg/runtime.(*DaprRuntime).beginPubSub.func1(0x4998520, 0xc0000b9800, 0xc00092edd0, 0x4998520, 0xc0000b9800)
	/Users/runner/work/dapr/dapr/pkg/runtime/runtime.go:487 +0x39d
github.com/dapr/components-contrib/pubsub/redis.(*redisStreams).processMessage(0xc0009fac60, 0xc00078a960, 0xf, 0xc00078a990, 0x13, 0x18, 0xc0006cb0e0, 0xf, 0x0, 0xc000eac240, ...)
	/Users/runner/go/pkg/mod/github.com/dapr/components-contrib@v1.2.0/pubsub/redis/redis.go:475 +0x1bf
github.com/dapr/components-contrib/pubsub/redis.(*redisStreams).worker(0xc0009fac60)
	/Users/runner/go/pkg/mod/github.com/dapr/components-contrib@v1.2.0/pubsub/redis/redis.go:458 +0xd9
created by github.com/dapr/components-contrib/pubsub/redis.(*redisStreams).Init
	/Users/runner/go/pkg/mod/github.com/dapr/components-contrib@v1.2.0/pubsub/redis/redis.go:373 +0x3f3

related source code:
https://github.com/dapr/dapr/blob/8e960e2632d435ccc4cf1cd1d2f8446784e0c39a/pkg/runtime/runtime.go#L1220
rawPayload not always have the pubsub.IDField(id) field

/assign

https://github.com/dapr/dapr/pull/3330 and https://github.com/dapr/components-contrib/pull/967 should be able to fix this issue.

@zcong1993 @beiwei30 this should be supported if the instructions here are followed: https://docs.dapr.io/developing-applications/building-blocks/pubsub/pubsub-raw/
Specifying as a subscriber that you're interested in a raw payload will cause daprd to inspect the data as raw and not as a Cloud Event.

This doesn't seem like an issue in components-contrib but instead in the logging statement. id is a mandatory field, but I don't think the logging statement should assume it is present and safe to cast as a string. In fact, if you remove the cast it should probably fix this problem.
change
return errors.Errorf("RETRY status returned from app while processing pub/sub event %v", cloudEvent[pubsub.IDField].(string))

to
return errors.Errorf("RETRY status returned from app while processing pub/sub event %v", cloudEvent[pubsub.IDField])

@pkedy pls. review dapr/components-contrib#967 again.


text:
Enable route based proxying for HTTP in addition to gRPC

In 1.3, we improved developer experience for gRPC by allowing users to use their existing proto services and telling Dapr which service to discover using standard metadata headers.
Today, lift and shift scenarios or integrating Dapr into existing code requires users to change their URL paths to the following:
/v1.0/invoke/myservice/targetmethod

In the example above, targetmethod is the full URL endpoint of the target service, so for example:
/v1.0/invoke/myservice/api/products

I suggest to enable users to, like gRPC, call Dapr over / and specify the target service through HTTP headers.
In this case, users keep their existing HTTP clients and URL routes and in place, and make the following changes:

Change the address in the URL to localhost
Add a dapr-app-id header to specify the ID of the target service

I'd +1 @yaron2 to make the friction and lift much smaller for existing HTTP developers to immediately get value out of Dapr.  today you have to rewrite your HTTP code to tokenize and call our special dapr URIs

We implemented something similar to this functionality in the .NET SDK and it really simplifies life for uses. Adding Dapr service invocation to an existing service can be a one line change!
I'm strongly supportive of this being added to the runtime (rather than the SDK). This will make the functionality accessible to everyone without thick SDKs acting as a polyfill.

I am supportive of this approach.
It probably means that the header will be handled in the runtime before the URL's path.

I am supportive of this approach.
It probably means that the header will be handled in the runtime before the URL's path.

Exactly!

I don't understand the problem here; almost all settings require the base url to be passed as input. This is the same for any pre-packaged solutions that we are trying to add dapr to via annotations. We haven't had an issue changing the env/config/setting from https://tempuri.org/ to http://localhost:3500/v1.0/invoke/tempuri/method/ . It literally works like magic and suddenly we can make sense of the hundreds of systems in our environments. its the ease of use of a service mesh with added benefits
How would we do that with this proposal without modifying the code to add the header?
If we want to simplify, there is an alternative, how about
http://localhost:port/dapr-id instead of http://localhost:port and adding a custom header
As an aside, we are primarily using Dapr as a way to bring our existing hundreds of polyglot microservices forward and getting some of the benefits of the observability, service location, mTLS, and retrys. We would not be able to do this without changing the code for all existing services.
I do not support this.

I don't understand the problem here; almost all settings require the base url to be passed as input. This is the same for any pre-packaged solutions that we are trying to add dapr to via annotations. We haven't had an issue changing the env/config/setting from https://tempuri.org/ to http://localhost:3500/v1.0/invoke/tempuri/method/ . It literally works like magic and suddenly we can make sense of the hundreds of systems in our environments. its the ease of use of a service mesh with added benefits
How would we do that with this proposal without modifying the code to add the header?
If we want to simplify, there is an alternative, how about
http://localhost:port/dapr-id instead of http://localhost:port and adding a custom header
As an aside, we are primarily using Dapr as a way to bring our existing hundreds of polyglot microservices forward and getting some of the benefits of the observability, service location, mTLS, and retrys. We would not be able to do this without changing the code for all existing services.
I do not support this.

Just to be clear, this will not replace the current service invocation format but will be an added option.

Ah! That's a relief and makes much more sense. I don't see why that wouldn't be a great addition!

I actually like the idea from @ewassef about not setting a header because it requires code change in the app do include the special Dapr header. If we can reuse the endpoint configuration, it makes adoption much easier. What if (in addition to HTTP header), we also allow this to be passed in via HTTP Basic Auth: http://dapr-app-id:MyAppId@localhost:3500/any/path

The Dapr header is consistent with how we do it for gRPC (using metadata), but I'm ok with adding more options for users to best choose how they want to format their service invocation URL best.

authors: artursouza ewassef paulyuk rynowak yaron2


text:
Migrate HTTP server from fasthttp to net/http

Since at least 2020, Dapr has been using the fasthttp library for the internal HTTP API server. An Architectural Decision Record from June 2020 (that is still in "proposed" status) contains information on this decision, which was based on the fact that, at least on synthetic benchmarks, fasthttp is optimized for performance and raw speed, primarily thanks to avoiding almost any memory allocation.
However, with more experience building Dapr and with the desire to push it forward, we are now uncovering a series of issues that could make it advisable to convert the internal HTTP server to be based on the Go standard library (net/http). It's likely that our use cases are not what fasthttp is meant for, and as we invest in things like streaming supports, the issues will only be growing. This is advice that was provided by the maintainer (it appears to be a single person now) of fasthttp too.
Although switching from net/http to fasthttp will have a negative performance impact, arguably this should be negligible in the context of Dapr. Each one of our handlers performs a lot of operations (and are in large part I/O bound) and a lot of allocations and spanning of goroutines, which mask the effect of any micro-optimization performed by fasthttp.

Note that fasthttp contains both a server and client, and Dapr uses both, although the client part plays a very small role.

I am categorizing the issues in 3 groups.
Problems with Dapr currently
Lack of context support
With fasthttp, each request does not get a context that is tied to the lifetime of the request.
Although each handler is passed a ctx which does implement the context.Context interface (and we use it a lot in Dapr, example), the lifecycle of that context is tied to the server's context and not the request's context. This seems to be an explicit design decision (although not clearly documented).
This is an issue for Dapr because if the user (app) cancels a request, we do not have a way to be notified of that and abort in-progress operations.
According to the fasthttp maintainer:

If people want to use contexts they really shouldn't be using fasthttp. When you are using contexts it shows that you don't need the performance increase fasthttp gives. If you really needed that performance you wouldn't be using contexts to begin with.

No support for HTTP/2
fasthttp does not include support for HTTP/2. This means application cannot use HTTP/2 to connect to Dapr, possibly missing out on the performance benefits of things like multiplexing, etc.
Problems with handling streams
At a high level, fasthttp has incomplete support for streaming.
For example, the fasthttp client does not support making requests and sending/reading streams. In the PR adding support for streams, I had no choice but to use net/http for outbound requests (in the pkg/channel/http package, for Dapr to invoke the app).
According to the maintainer, streaming support has never been a priority because the kind of apps fasthttp is designed for do not need streaming, as they work with small blobs of data:

fasthttp is all about performance and it achieves this by not supporting these kinds of things. Streaming of response bodies doesn't make sense in the use cases fasthttp is for. If you need body streaming it's better to use net/http.

More specifically, even with the limited support for streaming, a lot of things are left to the developers (and are generally un-documented):
No explicit support for streaming response body from the server
In a fasthttp server, responding with a stream is not something that is available as built-in, and requires "hijacking" the request. Example:
https://github.com/dapr/dapr/blob/bcb202c79d41e311b259af5414c355c2be7f1e4d/pkg/http/responses.go#L109-L138
(Issue opened in fasthttp's repo)
Support for reading requests as a stream seems not mature
The only area where fasthttp does have "complete" support for streams seems to be in reading the request body in the server. However, that was a contribution from the community and it seems implemented in a spotty way. At a high level:

Even when streaming is enabled, some requests do not come in as streams, so trying to read them with the methods to get a stream returns no data.
When the request body is coming in as stream, the "max request body size" is ignored

Examples of "workarounds" required:
https://github.com/dapr/dapr/blob/bcb202c79d41e311b259af5414c355c2be7f1e4d/pkg/http/api.go#L2478-L2487
Even more, support for using streams seems not fully stable. In the PR adding streaming support, E2E tests seems more flaky with occasional "EOF" errors. (It appears that it is not just us: 1 2 3)
General consideration
Lastly, a few general considerations:

As the maintainers made it very clear (and are not shy of repeating to everyone in the repo), fasthttp is optimized for certain use cases that are not really aligned with what we are doing. It seems to shine in situations where it's dealing with small amounts of data and the response is generated synchronously (perhaps apps that closely resemble "helloworld-style benchmarks"). This is different from Dapr, where each handler can take a lot of time processing the request, makes a lot of allocations, and is generally I/O-bound
The code of fasthttp is very complex and documentation is not always clear (see how we've been using the contexts "wrong" all this time). This is especially true if you are looking at the code that implements the (partial) support for streams.
Lastly, from a risk perspective, net/http is maintained by the Go team and receives lots of attention. It is tested heavily in production in a variety of scenarios, and it is the target of extensive scrutiny also for security vulnerabilities. At this time, it appears that fasthttp has a single, part-time maintainer. While not uncommon in the OSS space, and not necessarily a deal-breaker per se, given the extent to which Dapr depends on this library, and the fact that servers are often a high-risk point for attacks, it's a point worth considering too in the risk calculations.

fasthttp https://github.com/valyala/fasthttp/issues/144 support for HTTP/2. This means application cannot use HTTP/2 to connect to Dapr, possibly missing out on the performance benefits of things like multiplexing, etc.

For me, the fact fasthttp still doesn't support HTTP/2 (though it is in-progress, albeit slow) and will likely not support HTTP/3 is alone good enough of a reason to switch to net/http.

fasthttp is optimized for certain use cases that are not really aligned with what we are doing

This I disagree with, I think fasthttp is almost completely aligned with what we are doing (backend calls with thousands of small to medium requests optimized for low-latency). Before streaming support was proposed in Dapr, we were clear the runtime wasn't optimized for large requests. Also, Dapr was never used as an HTTP/1.1 web front proxy and so the lack of HTTP standards support was also not applicable to us. With streaming support making its way into Dapr, it makes sense to switch to net/http that offers better support.
The maintainability aspect of the package is also very important and is a big advantage for net/http.

Although switching from net/http to fasthttp will have a negative performance impact, arguably this should be negligible in the context of Dapr. Each one of our handlers performs a lot of operations (and are in large part I/O bound) and a lot of allocations and spanning of goroutines, which mask the effect of any micro-optimization performed by fasthttp.

There's strong evidence to suggest otherwise. fasthttp seems to be way ahead in tests that are I/O bound (see here and here) and other non-hello worlds scenarios. Luckily, it'll be easy for us to assess the performance degradation as we have performance tests in place.
Overall I'm supportive of the transition to net/http, barring any major performance regressions. (Will discuss with @daixiang0 and @artursouza to come up with what's an acceptable performance loss).

Thanks for your thoughts.

fasthttp seems to be way ahead in tests that are I/O bound (see here and here) and other non-hello world scenarios.

With I/O bound I was referring to what our handlers are doing: most of our handlers connect to external services (a state store, a binding, etc) or perform service-invocation. I think it's fair to assume that the complexity of the code inside the handlers, and the number of allocations (and opportunities for improvements), is orders of magnitude bigger than the complexity (and allocations) of the server itself.

I think a good first step @ItalyPaleAle would be to create a net/http branch with a change that enables net/http support only for the handlers that deal with service invocation and/or state management/pubsub so that we can run performance tests and get data points before spinning off any major work.

I agree it would be nice, but I don't think we can do that without rewriting the entire pkg/http module. fasthttp is taking up the listener, so it's not possible do update just a few of the handlers and not all of them.
Also worth pointing out that the API for middleware components would need to change too, in case of a migration.

is orders of magnitude bigger than the complexity (and allocations) of the server itself

Maybe, but the net latency of the server adds up and becomes more critical as the I/O operations are slower.
If it's not going to shorten the path much to change minimally to test performance, we'll just need to test when all the work is done and make a decision then whether the perf loss is acceptable.

Since fasthttp does not support HTTP2 and net/http is in a very well maintained and optimized state, switch is meaningful.
For performance, a benchmark result is necessary to detect the true perf loss.

Still very much relevant

@ItalyPaleAle Still looking for help with this? It looks like there's a fair amount of work here because of how pervasive FastHTTP is, but none of it actually looks terribly difficult.

@ItalyPaleAle I have some spare cycles in the next couple of weeks, and I think I can get the bulk of this done pretty quickly. I'm sure I'll have questions as I proceed, but I'll start digging into it and see how far I'm able to get.

@alandavidreyes sounds good, thanks for volunteering :) I can help reviewing

@alandavidreyes Were you able to make any progress on this by any chance? If not, no worries, just wanted to check if someone's done any work

@ItalyPaleAle Sorry for not checking in sooner!
Yes, I have been making progress, although it hasn't gone quite as quickly as I had hoped. Most things have pretty clear 1:1 matches between the two libraries, but a few things (most notably the routing, where I've been spoiled by Gin) have been taking a bit longer to unpack.
I have a version that has the bulk of pkg/http moved over from FastHttp. What I mean by that is that the requests are being handled by net/http, but there are still a number of places where I'm cheating and using nethttpadaptor because I haven't had a chance to rewrite the handlers. There are also still a handful of failing test cases that I need to dig into. I've also been removing it from other places as I've had pockets of time - I've gotten rid of something like 60 percent of the FastHTTP references at this point.
I'm expecting to have a bit more focused time in the next few days. My current goal is to try to get something for you all to look at - although it might still need a bit more work - this weekend.

Sounds good, thanks a lot for the update :)
Please let me know if you need help

pls just use this, http2 is included and http3 too
github.com/cloudwego/hertz


text:
[Workflows][1.14] Execution of fanout of Activities are happening sequentially, not in parallel due to new scheduler reminders

runtime 1.14.0-rc.3
Scheduler enabled (1 replica)

20 Activities are scheduled at the same time in parallel using WhenAll strategy (green box demonstrates the same timestamp for all 20 activities)

The first 10 activities use the SlowActivity Activity - this activity simply waits for exactly 3 seconds before returning.

You can see in the screen shot that the activated time of each Activity are spaced by exactly 3 seconds in the first 10 activities (blue box)

The last 10 activities use the VerySlowActivityActivity - this activity simply waits for exactly 10 seconds before returning.

You can see in the screen shot that the activated time of each Activity are spaced by exactly 10 seconds in the last 10 activities (purple box)

Actual
This indicates that the Activities are not being activated in parallel, but are being activated sequentially.
Expected
The WhenAll strategy should activate the Activities in a near-parallel fashion. You would see the activated time being very close across all 20 Activities.

Now lets repeat the same experiment using the legacy actor reminders (No scheduler)
Notice how the scheduled time and activated time are exactly the same across the board (green box) - this is what I would expect as correct behaviour.

What happens if we run two instances of the workflow at the same time?
Once again, I would expect that all Activity activations happen very close to each other (in a small scale example like this)
However what we actually see is that only 1 Activity is allowed to be running at anyone time across both Workflow instances.
So not only is max concurrency of Activities once per Workflow Instance, it's worse as its actually once per Workflow Type (spanning many workflow instances) which is very bad indeed.
In the screen shot below you can see the 2 workflow instances denoted as 0-4098 and 1-4098

Fixed in 1.14 🎉


text:
Unify the logic on sidecar injection and service creation

Description
The k8s resource that needs to be injected needs to be created at the same time as the k8s service to ensure that the service can be provided externally
Issue reference

Please reference the issue this PR will close: #6967
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[x] Created/updated tests
[x] Unit tests passing
[ ] End-to-end tests passing
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Specification has been updated / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Provided sample for the feature / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

@JasonChen86899 it would be great if you could add support for a StatefulSet also

@yaron2 StatefulSet has been already supported before my modify.

@yaron2 StatefulSet has been already supported before my modify.

The problem we have with StatefulSets today is that we don't allow to invoke a particular pod within the set and that's a common ask. I know what needs to be done for this but let's leave it out of this PR.
In the meantime, the end to end tests are failing on current changes.

The problem we have with StatefulSets today is that we don't allow to invoke a particular pod within the set and that's a common ask. I know what needs to be done for this but let's leave it out of this PR.
understood, we can use headless service to meet this need

In the meantime, the end to end tests are failing on current changes.
this e2e test failed, It doesn't seem to be logically related to my changes

=== FAIL: tests/e2e/tracing_zipkin TestInvoke/Simple_HTTP_invoke_with_tracing (0.67s)
2024/06/23 18:18:09 Waiting until service ingress is ready for tracingapp-a...
2024/06/23 18:18:09 Service ingress for tracingapp-a is ready...: url=172.18.0.5:31885
2024/06/23 18:18:09 Waiting until service ingress is ready for tracingapp-b...
2024/06/23 18:18:10 Service ingress for tracingapp-b is ready...: url=172.18.0.5:30526
    tracing_zipkin_test.go:105:
            Error Trace:    /home/runner/work/dapr/dapr/tests/e2e/tracing_zipkin/tracing_zipkin_test.go:105
            Error:          Received unexpected error:
                            invalid character '{' after top-level value
            Test:           TestInvoke/Simple_HTTP_invoke_with_tracing
    --- FAIL: TestInvoke/Simple_HTTP_invoke_with_tracing (0.67s)

=== FAIL: tests/e2e/tracing_zipkin TestInvoke (0.67s)

@JasonChen86899 please resolve the conflicts

@JasonChen86899 please resolve the conflicts

I will work out it recently


text:
add rocketmq consumer config item description

In addition, please fill out the following to help reviewers understand this pull request:
Description
add rocketmq consumer config item description.
Issue reference
https://github.com/dapr/components-contrib/issues/2756

done

repo: dapr/docs


text:
preserve reentrant header used for actors ... through the service invocation process

In the dapr doc info, they show some reentrant actor scenarios. It looks like the dapr dotnet sdk automatically creates and passes the reentrant header id ... so as long as you follow the basic scenarios described in the docs it works fine.
ActorA -> ActorA
ActorA -> ActorB -> ActorA

https://docs.dapr.io/developing-applications/building-blocks/actors/actor-reentrancy/
I am wanting a do a slightly different scenario that includes a service invocation in the process.
ActorA -> invoke some service -> ActorA

This is currently not working because the reentrant header is not automatically preserved during a service invocation.

I actually have this working with out too many changes ... that said I am sure the implementation is not up proper standards ... is it worth submitting a PR or pointing to a fork to have folks take a look?

basically tuck away the reentrant header id here (before service invocation)
https://github.com/dapr/dotnet-sdk/blob/01cdc89710c16712442474afea97693f22c5852b/src/Dapr.Client/DaprClientGrpc.cs#L278
// aktxyz tuck away reentrant header id before service invocation
if (Dapr.Actors.ActorReentrancyContextAccessor.ReentrancyContext != null)
{
    request.Headers.TryAddWithoutValidation(Constants.ReentrancyRequestHeaderName, Dapr.Actors.ActorReentrancyContextAccessor.ReentrancyContext);
}

and then on the receiving end, pluck out the reentrant header id here
https://github.com/dapr/dotnet-sdk/blob/01cdc89710c16712442474afea97693f22c5852b/src/Dapr.AspNetCore/CloudEventsMiddleware.cs#L59
// aktxyz pluck out the reentrant header id after service service invocation
if (httpContext.Request.Headers.ContainsKey(Dapr.Client.Constants.ReentrancyRequestHeaderName))
{
    var daprReentrancyHeader = httpContext.Request.Headers[Dapr.Client.Constants.ReentrancyRequestHeaderName];
    Dapr.Actors.ActorReentrancyContextAccessor.ReentrancyContext = daprReentrancyHeader;
}

This seems to work fine ... so good enough to keep working ... would love to see support for this added in a proper way sometime in the future.

Does anyone on the DAPR team have any thoughts on this ... I think maintaining the reentrant header id across service invocations is a good thing !

I understand that this functionality is technical feasible. However, it would be really helpful if you could provide more details about the specific scenario where this shortcoming is blocking you and your project. This information would strengthen the case for addressing this issue, rather than it being seen as an interesting aspect of an otherwise incomplete but usable feature.

basically I have a case where I do something like this ...
ActorA -> invoke some service -> ActorA

ActorA receives a request
ActorA pubs out a message (service invoke), which is picked up by multiple services listening for this message type
when each service completes it's task, it sends results back to ActorA via a message

so basically
ActorA -> invoke some services (reentrant ID lost here) -> ActorA

Why do you need re-entrancy for this scenario? Why not simply call the actor anew with the message results?

authors: WhitWaldo aktxyz

repo: dapr/dotnet-sdk


text:
[Snyk] Security upgrade werkzeug from 2.2.3 to 3.0.3

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to fix one or more vulnerable packages in the `pip` dependencies of this project.
Changes included in this PR

Changes to the following files to upgrade the vulnerable dependencies to a fixed version:

dev-requirements.txt

⚠ Warning
virtualenv 20.26.1 has requirement importlib-metadata>=6.6; python_version < "3.8", but you have importlib-metadata 4.2.0.
tox 4.8.0 has requirement importlib-metadata>=6.7; python_version < "3.8", but you have importlib-metadata 4.2.0.
opentelemetry-api 1.22.0 has requirement importlib-metadata<7.0,>=6.0, but you have importlib-metadata 4.2.0.
Flask 2.2.5 requires Werkzeug, which is not installed.

Vulnerabilities that will be fixed
By pinning:

Severity
Priority Score (*)
Issue
Upgrade
Breaking Change
Exploit Maturity

661/1000  Why? Recently disclosed, Has a fix available, CVSS 7.5
Remote Code Execution (RCE) SNYK-PYTHON-WERKZEUG-6808933
werkzeug:  2.2.3 -> 3.0.3
No
No Known Exploit

(*) Note that the real score may have changed since the PR was raised.
Some vulnerabilities couldn't be fully fixed and so Snyk will still find them when the project is tested again. This may be because the vulnerability existed within more than one direct dependency, but not all of the affected dependencies could be upgraded.
Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
🛠 Adjust project settings
📚 Read more about Snyk's upgrade and patch logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Remote Code Execution (RCE)

@artursouza if you open these automated PRs, please do make sure the commits are signed.

This PR is not necessary and I think this is a false positive.
Try:
pip3 uninstall Flask --yes
pip3 uninstall Werkzeug --yes

then
pip3 install Flask>=1.0
pip3 freeze

You will see that the latest Flask gets installed with Werkzeug==3.0.3 which the CVE requests.
Therefore Dapr does not need to force the version since we don't force a maximum Flask version either.
Closing this issue here as a false positive.

Probably was a caching problem before.

authors: artursouza berndverst

repo: dapr/python-sdk


text:
Create a default implementation of Authentication class

Everything can be defaulted into AuthenticationDomain (or an implementation of it) except for getServiceInfo.
or maybe look at putting it into authServerModule function...

The concept of this is changing.

repo: darkadept/imperium

license: MIT


text:
Automation Use No Interactive Prompt?

Greetings,
Maybe my PS inexperience is shining brightly in this question, but I'm trying execute a PS script, that invokes Posh-SSH,  from a monitoring tool called PRTG. It's a simple process where I've written a script that is fired by PRTG when an event occurs. The script is bellow, my issue is it appears that Posh-SSH will invoke a interactive dialog window and wait for credentials and because of this the script never completes it's execution. I'm puzzled why that dialog window from the New-SSHSession even presents itself considering I'm using a key file for authentication, but again, I don't that much PS experience so I might be missing something simple. This Newbie says thanks for any insight on my issue.
`

Test values
$phoneNumber = 'xxxXXXxxxx'
$message = (Get-Date).DateTime

Capture phone and message parameters from CLI
#param([string]$phoneNumber = "phoneNumber", [string]$message = "message")

Assembly send command string.
$SendCommand = "sendsms " + $phoneNumber + " " + "'" + $message + "'"

Test code to pass credentials
#$username = "alert"
#$password = " " | ConvertTo-SecureString -asPlainText -Force
#$credential = New-Object System.Management.Automation.PSCredential($username,$password)

#Open SSH session using key authentication.
New-SSHSession -ComputerName 1.1.1.1 -Credential alert -KeyFile "C:\keys\keyA.key" -Port 2220

Send command to fire SMS alert
Invoke-SSHCommand -Command $SendCommand -SessionId 0

Kill SSH session
Remove-SSHSession -SessionId 0

Jobs done, next?
`

The reason is that even if you provide a key the credentials param is still mandatory so we know to what user we should associate the key to. You can create a credential object with the user and a empty password and pass the key param.

authors: darkoperator philipathomas

repo: darkoperator/Posh-SSH


text:
Feature Request: Image format function

I would like to see a rich-pixel version of the standard library .format() which would allow users to do something like this:
There may additionally need to be a function that tells rich-pixels what color is going to be used for string replacement
i.e)
my_image = example.png
image.set_format('pink')
render.image(my_image).format(ip_address01, ip_address02)

Which would take this image and fill in two IP addresses with the format of 000.000.000.000

This is outwith the scope of what I want to offer with this library, sorry!

repo: darrenburns/rich-pixels


text:
Contextily install in google colab

When I try to install contextily on google colab (! Pip install contextily), an error appears in the cartopy installation. This I solved this way: https://github.com/googlecolab/colabtools/issues/85#issuecomment-372532728.
The installed version is 0.99. The problem is that it does not have the "contextily.add_basemap" function.
After searching, I saw pypi.org for the latest version and installed it without problems:
pip install contextily==1.0rc2
Now everything is working!
Here is the hint if someone has the same difficulties.

Thanks! I had the same problem installing contextily on linux. With the 1.0rc2 it works

I faced this morning (2020_0321) and solved as @hugonbgg suggested.

When I try to install contextily on google colab (! Pip install contextily), an error appears in the cartopy installation. This I solved this way: googlecolab/colabtools#85 (comment).
The installed version is 0.99. The problem is that it does not have the "contextily.add_basemap" function.
After searching, I saw pypi.org for the latest version and installed it without problems:
pip install contextily==1.0rc2
Now everything is working!
Here is the hint if someone has the same difficulties.

authors: ahmetanildindar hugonbgg kerooksblog

repo: darribas/contextily


text:
DateFormat.jms(locale) returns in english a character \u8239 (Narrow No-Break Space), which cannot be used in latin1.encode

Describe the bug
DateFormat.jms(locale) returns in english a character \u8239 (Narrow No-Break Space), which cannot be used in latin1.encode, it's an invalid character.
To Reproduce
1----------

Locale is en_GB
Create a formatter f = DateFormat.jms(locale)
Format a Datetime myString = f.format(dateTime)
as now (flutter 3.13), it will return a string with NNBSP between seconds and AM/PM marker.

2----------
encode the string to latin1:
latin1.encode(myString)
3-----------
We got an exception about an invalid character, which is NNBSP:
`
6:01:47 PM
dart:convert                         Latin1Codec.encode
test/latin1_cleaner_test.dart 18:27  main..
Invalid argument (string): Contains invalid characters.: "6:01:47 PM"
`
Expected results
A Uint8List, and format should not return a string containing an invalid character
import 'dart:convert';

import 'package:intl/date_symbol_data_local.dart';
import 'package:intl/intl.dart';
import 'package:test/test.dart';

void main() async {
  /// Initialize date formatting now
  await initializeDateFormatting("en", null);

  group('Latin1 cleaner', () {
    test('latin1 test', () async {
      final createdAt = DateTime.now();
      DateFormat df = DateFormat.jms("en");
      var date = df.format(createdAt);
      print(date);
      var result = latin1.encode(date);
      expect(result.isNotEmpty, true);
    });
  });
}

System info
% dart pub deps --style compact
Dart SDK 3.1.0
Flutter SDK 3.13.1
iTabla_Pandit 1.0.1+252
dependencies:

antlr4 4.13.0 [logging collection]
auto_size_text 3.0.0 [flutter]
barcode 2.2.4 [meta qr]
barcode_image 2.0.3 [args barcode image meta]
barcode_widget 2.0.4 [barcode flutter]
cupertino_icons 1.0.5
device_info_plus 9.0.3 [device_info_plus_platform_interface ffi file flutter flutter_web_plugins meta win32 win32_registry]
disk_space_plus_new 0.0.1 [flutter plugin_platform_interface]
ffi 2.1.0
flutter 0.0.0 [characters collection material_color_utilities meta vector_math web sky_engine]
flutter_localizations 0.0.0 [flutter intl characters clock collection material_color_utilities meta path vector_math web]
flutter_markdown 0.6.17+1 [flutter markdown meta path]
flutter_midi_command 0.4.11 [flutter flutter_midi_command_platform_interface]
flutter_virtual_piano 0.0.9 [flutter]
fraction 5.0.2
google_fonts 5.1.0 [flutter http path_provider crypto]
grouped_list 5.1.3 [flutter]
image 4.0.17 [archive meta xml]
image_picker 1.0.2 [flutter image_picker_android image_picker_for_web image_picker_ios image_picker_linux image_picker_macos image_picker_platform_interface image_picker_windows]
intl 0.18.1 [clock meta path]
logger 2.0.1
onboarding_overlay 3.2.1 [flutter vector_math auto_size_text]
open_mail_app 0.4.5 [platform url_launcher flutter]
package_info_plus 4.1.0 [ffi flutter flutter_web_plugins http meta path package_info_plus_platform_interface win32]
path_provider 2.1.0 [flutter path_provider_android path_provider_foundation path_provider_linux path_provider_platform_interface path_provider_windows]
permission_handler 10.4.3 [flutter meta permission_handler_android permission_handler_apple permission_handler_windows permission_handler_platform_interface]
photo_view 0.14.0 [flutter]
popover 0.2.8+2 [flutter]
purchases_flutter 5.6.2 [flutter freezed_annotation json_annotation]
scan 1.6.0 [flutter]
scroll_to_index 3.0.1 [flutter]
sentry_flutter 7.9.0 [flutter flutter_web_plugins sentry package_info_plus meta]
share_plus 7.1.0 [cross_file meta mime flutter flutter_web_plugins share_plus_platform_interface file url_launcher_web url_launcher_windows url_launcher_linux url_launcher_platform_interface ffi win32]
shared_preferences 2.2.0 [flutter shared_preferences_android shared_preferences_foundation shared_preferences_linux shared_preferences_platform_interface shared_preferences_web shared_preferences_windows]
sprintf 7.0.0
url_launcher 6.1.12 [flutter url_launcher_android url_launcher_ios url_launcher_linux url_launcher_macos url_launcher_platform_interface url_launcher_web url_launcher_windows]
wakelock_plus 1.1.1 [flutter flutter_web_plugins meta wakelock_plus_platform_interface win32 dbus package_info_plus js]

dev dependencies:

flutter_lints 2.0.2 [lints]
test 1.24.6 [analyzer async boolean_selector collection coverage http_multi_server io js matcher node_preamble package_config path pool shelf shelf_packages_handler shelf_static shelf_web_socket source_span stack_trace stream_channel test_api test_core typed_data web_socket_channel webkit_inspection_protocol yaml]

transitive dependencies:

_fe_analyzer_shared 64.0.0 [meta]
analyzer 6.2.0 [_fe_analyzer_shared collection convert crypto glob meta package_config path pub_semver source_span watcher yaml]
archive 3.3.7 [crypto path pointycastle]
args 2.4.2
async 2.11.0 [collection meta]
boolean_selector 2.1.1 [source_span string_scanner]
characters 1.3.0
clock 1.1.1
collection 1.17.2
convert 3.1.1 [typed_data]
coverage 1.6.3 [args logging package_config path source_maps stack_trace vm_service]
cross_file 0.3.3+4 [js meta]
crypto 3.0.3 [typed_data]
dbus 0.7.8 [args ffi meta xml]
device_info_plus_platform_interface 7.0.0 [flutter meta plugin_platform_interface]
file 6.1.4 [meta path]
file_selector_linux 0.9.2 [cross_file file_selector_platform_interface flutter]
file_selector_macos 0.9.3+1 [cross_file file_selector_platform_interface flutter]
file_selector_platform_interface 2.6.0 [cross_file flutter http plugin_platform_interface]
file_selector_windows 0.9.3 [cross_file file_selector_platform_interface flutter]
flutter_midi_command_platform_interface 0.4.0 [flutter plugin_platform_interface]
flutter_plugin_android_lifecycle 2.0.15 [flutter]
flutter_web_plugins 0.0.0 [flutter characters collection material_color_utilities meta vector_math web]
freezed_annotation 2.4.1 [collection json_annotation meta]
frontend_server_client 3.2.0 [async path]
glob 2.1.2 [async collection file path string_scanner]
http 1.1.0 [async http_parser meta]
http_multi_server 3.2.1 [async]
http_parser 4.0.2 [collection source_span string_scanner typed_data]
image_picker_android 0.8.7+4 [flutter flutter_plugin_android_lifecycle image_picker_platform_interface]
image_picker_for_web 3.0.0 [flutter flutter_web_plugins image_picker_platform_interface mime]
image_picker_ios 0.8.8+1 [flutter image_picker_platform_interface]
image_picker_linux 0.2.1 [file_selector_linux file_selector_platform_interface flutter image_picker_platform_interface]
image_picker_macos 0.2.1 [file_selector_macos file_selector_platform_interface flutter image_picker_platform_interface]
image_picker_platform_interface 2.9.0 [cross_file flutter http plugin_platform_interface]
image_picker_windows 0.2.1 [file_selector_platform_interface file_selector_windows flutter image_picker_platform_interface]
io 1.0.4 [meta path string_scanner]
js 0.6.7 [meta]
json_annotation 4.8.1 [meta]
lints 2.1.1
logging 1.2.0
markdown 7.1.1 [args meta]
matcher 0.12.16 [async meta stack_trace term_glyph test_api]
material_color_utilities 0.5.0 [collection]
meta 1.9.1
mime 1.0.4
node_preamble 2.0.2
package_config 2.1.0 [path]
package_info_plus_platform_interface 2.0.1 [flutter meta plugin_platform_interface]
path 1.8.3
path_provider_android 2.1.0 [flutter path_provider_platform_interface]
path_provider_foundation 2.3.0 [flutter path_provider_platform_interface]
path_provider_linux 2.2.0 [ffi flutter path path_provider_platform_interface xdg_directories]
path_provider_platform_interface 2.1.0 [flutter platform plugin_platform_interface]
path_provider_windows 2.2.0 [ffi flutter path path_provider_platform_interface win32]
permission_handler_android 10.3.4 [flutter permission_handler_platform_interface]
permission_handler_apple 9.1.4 [flutter permission_handler_platform_interface]
permission_handler_platform_interface 3.11.3 [flutter meta plugin_platform_interface]
permission_handler_windows 0.1.3 [flutter permission_handler_platform_interface]
petitparser 5.4.0 [meta]
platform 3.1.1
plugin_platform_interface 2.1.5 [meta]
pointycastle 3.7.3 [collection convert js]
pool 1.5.1 [async stack_trace]
pub_semver 2.1.4 [collection meta]
qr 3.0.1 [meta]
sentry 7.9.0 [http meta stack_trace uuid]
share_plus_platform_interface 3.3.0 [cross_file flutter meta mime plugin_platform_interface path_provider uuid]
shared_preferences_android 2.2.0 [flutter shared_preferences_platform_interface]
shared_preferences_foundation 2.3.3 [flutter shared_preferences_platform_interface]
shared_preferences_linux 2.3.0 [file flutter path path_provider_linux path_provider_platform_interface shared_preferences_platform_interface]
shared_preferences_platform_interface 2.3.0 [flutter plugin_platform_interface]
shared_preferences_web 2.2.0 [flutter flutter_web_plugins shared_preferences_platform_interface]
shared_preferences_windows 2.3.0 [file flutter path path_provider_platform_interface path_provider_windows shared_preferences_platform_interface]
shelf 1.4.1 [async collection http_parser path stack_trace stream_channel]
shelf_packages_handler 3.0.2 [path shelf shelf_static]
shelf_static 1.1.2 [convert http_parser mime path shelf]
shelf_web_socket 1.0.4 [shelf stream_channel web_socket_channel]
sky_engine 0.0.99
source_map_stack_trace 2.1.1 [path source_maps stack_trace]
source_maps 0.10.12 [source_span]
source_span 1.10.0 [collection path term_glyph]
stack_trace 1.11.1 [path]
stream_channel 2.1.2 [async]
string_scanner 1.2.0 [source_span]
term_glyph 1.2.1
test_api 0.6.1 [async boolean_selector collection meta source_span stack_trace stream_channel string_scanner term_glyph]
test_core 0.5.6 [analyzer args async boolean_selector collection coverage frontend_server_client glob io meta package_config path pool source_map_stack_trace source_maps source_span stack_trace stream_channel test_api vm_service yaml]
typed_data 1.3.2 [collection]
url_launcher_android 6.0.38 [flutter url_launcher_platform_interface]
url_launcher_ios 6.1.4 [flutter url_launcher_platform_interface]
url_launcher_linux 3.0.5 [flutter url_launcher_platform_interface]
url_launcher_macos 3.0.6 [flutter url_launcher_platform_interface]
url_launcher_platform_interface 2.1.3 [flutter plugin_platform_interface]
url_launcher_web 2.0.18 [flutter flutter_web_plugins url_launcher_platform_interface]
url_launcher_windows 3.0.7 [flutter url_launcher_platform_interface]
uuid 3.0.7 [crypto]
vector_math 2.1.4
vm_service 11.10.0
wakelock_plus_platform_interface 1.1.0 [flutter plugin_platform_interface meta]
watcher 1.1.0 [async path]
web 0.1.4-beta
web_socket_channel 2.4.0 [async crypto stream_channel]
webkit_inspection_protocol 1.2.0 [logging]
win32 5.0.7 [ffi]
win32_registry 1.1.1 [ffi win32]
xdg_directories 1.0.2 [meta path]
xml 6.3.0 [collection meta petitparser]
yaml 3.1.2 [collection source_span string_scanner]

This is WAI is general, the narrow non-breaking space was introduced by a CLDR data update.
Why should the results of formatting be latin1 encodable?

@mosuem I have a good use case here: unit tests. My tests fail because of this encoding difference:
expect(result, '1:00 PM');

Expected: '1:00 PM'
  Actual: '1:00 PM'
   Which: is different.
          Expected: 1:00 PM
            Actual: 1:00 PM

Quite ridiculous, IMO. I fixed it by doing the following, but I shouldn't have to do this.
final nbsp = '\u{202F}';
expect(result, '1:00${nbsp}PM');

authors: kristofb mosuem zakton5


text:
[native_toolchain_c] Add support for configuring preprocessor macro defines

This PR adds CBuilder.defines which can be used to specify definitions for preprocessor macros. Providing a value for a macro is optional.
Whether a macro with the name of the current BuildMode is defined is now configurable through CBuilder.buildModeDefine. Per default, this option is enabled.
Additionally, the standard NDEBUG macro is now being defined when not building with BuildMode.debug. This behavior is also configurable (CBuilder.ndebugDefine) and enabled by default.
Closes https://github.com/dart-lang/native/issues/61

Sorry about the many CI runs. 🙈 😅 The changelog/version validation step complained that the versions don't agree, even though they did, so I've removed wip.0 from the version to allow CI to run to completion if everything else works.

It should work, error: pubspec version (0.2.1-wip.0) and changelog (0.2.1-wip) don't agree they were different.
But I'm fine with merging this and just publishing 0.2.1.

flutter pub publish --dry-run

@mosuem Did we opt all repositories in to using flutter instead of dart for auto publishing? There should be nothing Flutter on this repo.

Should be resolved with https://github.com/dart-lang/ecosystem/pull/162 I hope?

Should be resolved with dart-lang/ecosystem#162 I hope?

@mosuem has that been published yet? I've rerun the job, but it fails with the same error.

The reruns always use the commit before the fix in dart-lang/ecosystem:
Uses: dart-lang/ecosystem/.github/workflows/publish.yaml@refs/heads/main (2e532e38cb6a4d784f58bfaf5afbabfcbd3e3531)

I've pushed a new commit, maybe that helps.

Thanks @blaugold ! 🚀

authors: blaugold dcharkes mosuem

repo: dart-lang/native


text:
Maintenance score takes significant hit when using git dependencies

Since the release of Dart 2.0, I've had to fork a couple of projects which are no longer actively maintained in order to bump their SDK constraints. I refer to these forks directly in my pubspec.yaml, but it appears that pana takes off 40 points on my package's maintenance score for doing this.
What's recommended workaround for this situation? I imagine there's plenty of package authors who will run into similar issues.

@bkonyi: We'll soon land a change where we'll display the actual maintenance score impacts along the suggestions. In the case of the package:draw, there is a 20 points penalty for the unconstrained dependencies (*), and another 20 points for the too short description. With that change it will be clear that we've applied those scores. There is no penalty for being a fork, and we don't track forks (yet).
(*) In this case it is considered unconstrained because they are git based. Git project can disappear or change without the package user's control, and it is likely that we should apply even harsher penalties in such cases, as it reduces the long-term reliability of the package.

@bkonyi: We'll soon land a change where we'll display the actual maintenance score impacts along the suggestions. In the case of the package:draw, there is a 20 points penalty for the unconstrained dependencies (*), and another 20 points for the too short description. With that change it will be clear that we've applied those scores. There is no penalty for being a fork, and we don't track forks (yet).
(*) In this case it is considered unconstrained because they are git based. Git project can disappear or change without the package user's control, and it is likely that we should apply even harsher penalties in such cases, as it reduces the long-term reliability of the package.

Ah, I didn't realize the short description had that large of a hit as well. Thanks!
With respect to the git based packages being considered unrestrained, is there a recommended workaround for dealing with packages which haven't (and likely won't) update their SDK constraints to support Dart 2.0? The ecosystem currently has plenty of packages which would work fine in Dart 2.0, but are unmaintained and have SDK constraints set for Dart 1.0.

is there a recommended workaround for dealing with packages which haven't (and likely won't) update their SDK constraints to support Dart 2.0? The ecosystem currently has plenty of packages which would work fine in Dart 2.0, but are unmaintained and have SDK constraints set for Dart 1.0.

If the package is something I care about, I usually reach out to the owner, and ask them if they want to maintain it. When they don't want to do that, they are usually cooperative to give ownership and uploading rights, and that means the package with the same name can be active again. Otherwise you can always pick a new package name...

If the package is something I care about, I usually reach out to the owner, and ask them if they want to maintain it. When they don't want to do that, they are usually cooperative to give ownership and uploading rights, and that means the package with the same name can be active again. Otherwise you can always pick a new package name...

Ah, that's unfortunate... I was hoping to avoid re-uploading and some package owners are unresponsive. Oh well, if that's what needs to be done that's what needs to be done. Thanks for clearing it up!

authors: bkonyi isoos

repo: dart-lang/pub-dartlang-dart


text:
When doing HTTP RPCs to services, do better logging

Log the full URL we're hitting before the request goes out. Allows us to understand why hitting User URL X -> search URL Y
If possible, it'd be great to log the version of the search service that was hit – should be in the reply headers – if at all possible, it'd be great to get the request ID, too...so we can debug a full round-trip

@mkustermann: is there an API to query the currently running instance's version in the appengine?

There is an package:googleapis/appengine/v1.dart api, it requires special IAM permission, i.e. the default service account the deployed service is using needs to have been added to the right IAM roles iirc.

I'm pretty sure it would not be that hard to use that API, but maybe we could use a simpler version, e.g. the last modified time of the .packages file? That should be set at the time we build the image, and could be used without much risk of exposing internal details.

The response header of the request should have the version in it...I think...

The response header of the request should have the version in it...I think...

Headers from the analyzer service, via curl:
< HTTP/1.1 200 OK
< Server: nginx
< Date: Tue, 21 Nov 2017 16:37:46 GMT
< Content-Type: application/json; charset="utf-8"
< Content-Length: 219
< Vary: Accept-Encoding
< x-frame-options: SAMEORIGIN
< x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
< Via: 1.1 google
< Alt-Svc: hq=":443"; ma=2592000; quic=51303431; quic=51303339; quic=51303338; quic=51303337; quic=51303335,quic=":443"; ma=2592000; v="41,39,38,37,35"

Version may be exposed, but because we are using the public URLs they are stripped off?

Huh...maybe.
Wonder if there is another URL...hrm...
On Tue, Nov 21, 2017 at 8:39 AM, István Soós notifications@github.com
wrote:

The response header of the request should have the version in it...I
think...
Headers from the analyzer service, via curl:
< HTTP/1.1 200 OK
< Server: nginx
< Date: Tue, 21 Nov 2017 16:37:46 GMT
< Content-Type: application/json; charset="utf-8"
< Content-Length: 219
< Vary: Accept-Encoding
< x-frame-options: SAMEORIGIN
< x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
< Via: 1.1 google
< Alt-Svc: hq=":443"; ma=2592000; quic=51303431; quic=51303339; quic=51303338; quic=51303337; quic=51303335,quic=":443"; ma=2592000; v="41,39,38,37,35"
Version may be exposed, but because we are using the public URLs they are
stripped off?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dart-lang/pub-dartlang-dart/issues/551#issuecomment-346085673,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABCitypaAuSS9uj5WjbI9l2t8cc1SGdks5s4vzSgaJpZM4QYUg1
.

authors: isoos kevmoo mkustermann


text:
Isolate.spawnUri does not load dart file from another directory when running as global package

This issue was originally filed by kunaldeo200...@gmail.com

What steps will reproduce the problem?
Future<Isolate> remote = Isolate.spawnUri(Uri.parse("../../stagehandData/isloader.dart"), [""], response.sendPort);
When the project containing this code is installed as a global package ( pub global activate -s path projdirectory). It gives an error.
What is the expected outcome?
Above line works when used as a regular dart application. It gives exception as a globally installed pub package as well.
What do you see instead?
Unhandled exception:
Uncaught Error: Failure getting http://localhost:54062/stagehandData/isloader.dart: 404 Not Found
Stack Trace:
#0      _asyncLoadError (dart:_builtin:285)
#1      _httpGet.<anonymous closure>.<anonymous closure> (dart:_builtin:228)
#2      _RootZone.runGuarded (dart:async/zone.dart:1082)
#3      _BufferingStreamSubscription._sendDone.sendDone (dart:async/stream_impl.dart:390)
#4      _BufferingStreamSubscription._sendDone (dart:async/stream_impl.dart:399)
#5      _BufferingStreamSubscription._close (dart:async/stream_impl.dart:290)
#6      _ForwardingStream._handleDone (dart:async/stream_pipe.dart:112)
Which Dart are you using?
Dart 1.8.5

This issue has been moved to dart-lang/pub#1246.

repo: dart-lang/sdk


text:
strong-mode check doesn't consider nested futures with async functions

Future<Stream> logs() async {
  return _requestStream(/*...*/);
}

Future<Stream> _requestStream(/*...*/) async {
  StreamController sc = new StreamController();
  ...
  return sc.stream;
}

Error:(345, 12) Type check failed: _requestStream(RequestType.get, '/containers/${container.id}/logs', query: query) (Future<Stream>) is not of type Stream

return _requestStream();

Looks like a dup of #24540


text:
Outdated samples are broken

There are two samples in the repo that have been broken since pub dropped support for older barback versions. samples/third_party/dromaeo depends directly on barback ^0.13.0 (outdated since April 2014), whereas samples/third_party/todomvc_performance depends on polymer ^0.10.0 (outdated since June 2014).

I think this belongs over here: https://github.com/dart-lang/www.dartlang.org/

The biggest problem with this is that these samples are breaking the test infrastructure for the SDK.

@nex3 We got these removed, right?

Yep!

authors: kevmoo nex3 srawlins


text:
Typo in LinkedListEntry.next documentation

Please see https://api.dartlang.org/stable/1.16.0/dart-collection/LinkedListEntry/next.html

Return the succeessor of this element in its linked list.

Please change to ...successor...

Fixed in revision e1bf3506

authors: lrhn sgrekhov


text:
Unexpected warning from dart analyzer in strong mode about type dynamic

The Dart Programming Language Speciﬁcation version 1.11 reads:

Type dynamic has methods for every possible identiﬁer and arity, with
every possible combination of named parameters. These methods all have dy-
namic as their return type, and their formal parameters all have type dynamic.
Type dynamic has properties for every possible identiﬁer. These properties all
have type dynamic.
From a usability perspective, we want to ensure that the checker does not
issue errors everywhere an unknown type is used. The deﬁnitions above ensure
that no secondary errors are reported when accessing an unknown type.

The following code demonstrates the problem:
typedef func();
typedef int func2(int x);

main() {
  dynamic x = null;
  int z = x.z; // ok
  func f = x.razorsedge; // ok
  func2 f2 = x.andromeda; // warning in strong mode
}

Output:

dartanalyzer.bat --strong --enable_type_checks test.dart
Analyzing [test.dart]...
[warning] Unsound implicit cast from dynamic to (int) -> int (D:\dev\dart\co19\Language\Types\Type_dynamic\test.dart, line 8, col 14)
[hint] The value of the local variable 'z' is not used (D:\dev\dart\co19\Language\Types\Type_dynamic\test.dart, line 6, col 7)
[hint] The value of the local variable 'f' is not used (D:\dev\dart\co19\Language\Types\Type_dynamic\test.dart, line 7, col 8)
[hint] The value of the local variable 'f2' is not used (D:\dev\dart\co19\Language\Types\Type_dynamic\test.dart, line 8, col 9)
1 warning and 3 hints found.

The problem is observed only in strong mode.
Dart VM version: 1.19.1 (Wed Sep 07 09:07:46 2016) on "windows_x64"

Similar problem:
class A {
}
class B<T> {
}

main() {
  A a = () {} (); // ok
  B<int> b = () {} (); // static warning in strong mode
}

dartanalyzer.bat --strong --enable_type_checks test.dart
Analyzing [test.dart]...
[warning] Unsound implicit cast from dynamic to B (D:\dev\dart\co19\Language\Types\Interface_Types\test.dart, line 8, col 14)
[hint] The value of the local variable 'a' is not used (D:\dev\dart\co19\Language\Types\Interface_Types\test.dart, line 7, col 5)
[hint] The value of the local variable 'b' is not used (D:\dev\dart\co19\Language\Types\Interface_Types\test.dart, line 8, col 10)
1 warning and 2 hints found.

This is intentional behavior. Implicit downcasts to composite types, like int -> int or List<int> are much more likely to fail in strong mode, because we do not allow List<dynamic> <: List<int>.
Strong Mode's subtyping rules do not work like Dart 1 spec. That's the whole point of strong mode :). CC @leafpetersen @vsmenon

I am still not clear in which cases warning appears.
Consider the first code example.
 func f = x.razorsedge; // ok

Why this line is ok?
func is ()->dynamic, assigning dynamic to it cause no warnings.
However, if we assign dynamic to (int)->dynamic, warning will appear.

Strong mode currently tries to give warnings on assignments that may cause cast failures on the checked mode VM but not on DDC.  All of the standard Dart subtypes of () -> dynamic are also strong mode subtypes, but standard Dart subtypes of (int) -> dynamic include (dynamic) -> dynamic which is not a strong mode subtype, and so code that ran correctly in checked mode might hit an error on DDC here.  Hence the warning.

authors: alsemenov jmesserly leafpetersen


text:
Process.run can't run batch files on windows without extensions

Dart VM version: 2.0.0-dev.6.0 (Thu Nov 02 09:04:29 2017) on "windows_x64"
With extension
import 'dart:io';

main(List<String> arguments) {
  print(Process.runSync('pub.bat', ['help']).stdout);
}

Pub is a package manager for Dart.
...

Without extension
import 'dart:io';

main(List<String> arguments) {
  print(Process.runSync('pub', ['help']).stdout);
}

Unhandled exception:
ProcessException: The system cannot find the file specified.

I have the same issue, I want to build and run dart-pad/dart-services, Firstly I got vulcanize command not found issue, I changed to vulcanize.cmd then it worked, and during the running, I got ProcessException: The system cannot find the file specified. Command: D:\apps\Dart\dart-sdk\bin\dart2js, I need to find and change dart2js to dart2js.bat.
I think Process.run/Process.runSync should consider the PATHEXT environment. And run without executable extension.

This affects flutterfire_cli's update command as it currently fails on Windows with "ProcessException: The system cannot find the file specified."
https://github.com/invertase/flutterfire_cli/issues/252


text:
Could approve_results.dart more gracefully handle lack of permissions?

This is the first time I have tried to preapprove some test failures. I ran:
$ tools/sdks/dart-sdk/bin/dart tools/approve_results.dart -b ddc-linux-release-chrome -b analyzer-analysis-server-linux -b analyzer-linux-release -p https://dart-review.googlesource.com/c/sdk/+/92480/1

The CLI tool crashed. I suspect I might not have the right permissions somewhere but the error isn't actionable enough for me to know what I should do to get the permissions I need:
Selected bot: ddc-linux-release-chrome
Selected bot: analyzer-analysis-server-linux
Selected bot: analyzer-linux-release
Unhandled exception:
Exception: Failed to run: python /Users/nshahan/code/dart-sdk/sdk/third_party/gsutil/gsutil.py [-m, cp, -r, -Z, gs://dart-test-results-approved-results/builders/analyzer-analysis-server-linux/approved_results.json, /var/folders/yf/rl2gr0w14cx38nq8bv4r2qlr009rgp/T/approve_results.UCjAL1/approved_results.json]
exitCode: 1
stdout:

stderr:
ServiceException: 401 Anonymous caller does not have storage.objects.get access to dart-test-results-approved-results/builders/analyzer-analysis-server-linux/approved_results.json.
CommandException: 1 file/object could not be transferred.

#0      runGsutil (file:///Users/nshahan/code/dart-sdk/sdk/tools/bots/results.dart:33:5)
<asynchronous suspension>
#1      cpRecursiveGsutil (file:///Users/nshahan/code/dart-sdk/sdk/tools/bots/results.dart:68:5)
#2      loadResultsFromBot (file:///Users/nshahan/code/dart-sdk/sdk/tools/approve_results.dart:120:7)
#3      _RootZone.runUnary (dart:async/zone.dart:1379:54)
#4      _FutureListener.handleValue (dart:async/future_impl.dart:126:18)
#5      Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:639:45)
#6      Future._propagateToListeners (dart:async/future_impl.dart:668:32)
#7      Future._complete (dart:async/future_impl.dart:473:7)
#8      _SyncCompleter.complete (dart:async/future_impl.dart:51:12)
#9      _AsyncAwaitCompleter.complete (dart:async/runtime/libasync_patch.dart:28:18)
#10     _completeOnAsyncReturn (dart:async/runtime/libasync_patch.dart:294:13)
#11     loadLog (file:///Users/nshahan/code/dart-sdk/sdk/tools/approve_results.dart)
#12     _RootZone.runUnary (dart:async/zone.dart:1379:54)
#13     _FutureListener.handleValue (dart:async/future_impl.dart:126:18)
#14     Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:639:45)
#15     Future._propagateToListeners (dart:async/future_impl.dart:668:32)
#16     Future._complete (dart:async/future_impl.dart:473:7)
#17     Stream.toList.<anonymous closure> (dart:async/stream.dart:975:18)
#18     _RootZone.runGuarded (dart:async/zone.dart:1302:10)
#19     _BufferingStreamSubscription._sendDone.sendDone (dart:async/stream_impl.dart:389:13)
#20     _RootZone.run (dart:async/zone.dart:1374:54)
#21     _FutureListener.handleWhenComplete (dart:async/future_impl.dart:150:18)
#22     Future._propagateToListeners.handleWhenCompleteCallback (dart:async/future_impl.dart:609:39)
#23     Future._propagateToListeners (dart:async/future_impl.dart:665:37)
#24     Future._addListener.<anonymous closure> (dart:async/future_impl.dart:348:9)
#25     _microtaskLoop (dart:async/schedule_microtask.dart:41:21)
#26     _startMicrotaskLoop (dart:async/schedule_microtask.dart:50:5)
#27     _Timer._runTimers (dart:isolate/runtime/libtimer_impl.dart:391:30)
#28     _Timer._handleMessage (dart:isolate/runtime/libtimer_impl.dart:416:5)
#29     _RawReceivePortImpl._handleMessage (dart:isolate/runtime/libisolate_patch.dart:171:12)

The issue was user error on my part. I had not authenticated with the gsutil.py script yet. I'm updating the issue as a request to handle the error and print a helpful message.

Thanks for the suggestion! Yeah I was meaning to do this.

Duplicate of https://github.com/dart-lang/sdk/issues/35377

authors: nshahan sortie


text:
Crash in dart::Type::IsEquivalent on macos

Happened at the end of CI run on the chromebots.
version=2.1.2-dev.0.0.flutter-0a7dcf17eb (Tue Feb 12 01:59:15 2019 +0000) on "macos_x64"
si_signo=Segmentation fault: 11(11), si_code=0, si_addr=0x0
thread=4103, isolate=test.dart.snapshot.dart2:main()(0x7fd176013000)
  [0x000000010edc1e3d] dart::Type::IsEquivalent(dart::Instance const&, dart::ZoneGrowableHandlePtrArray<dart::AbstractType const>*) const
  [0x000000010edc1e3d] dart::Type::IsEquivalent(dart::Instance const&, dart::ZoneGrowableHandlePtrArray<dart::AbstractType const>*) const
  [0x000000010edc2394] dart::Type::Canonicalize(dart::ZoneGrowableHandlePtrArray<dart::AbstractType const>*) const
  [0x000000010ed774a7] dart::Function::ImplicitClosureFunction() const
  [0x000000010ed7a35e] dart::Function::CreateMethodExtractor(dart::String const&) const
  [0x000000010ee4d266] dart::Resolver::ResolveDynamicAnyArgs(dart::Zone*, dart::Class const&, dart::String const&, bool)
  [0x000000010ee4ccd5] dart::Resolver::ResolveDynamicForReceiverClass(dart::Class const&, dart::String const&, dart::ArgumentsDescriptor const&, bool)
  [0x000000010ee5c36d] dart::InlineCacheMissHandler(dart::GrowableArray<dart::Instance const*> const&, dart::ICData const&)
  [0x000000010ee533c2] dart::DRT_InlineCacheMissHandlerOneArg(dart::NativeArguments)
  [0x0000000111ac0fa8] Unknown symbol
  [0x0000000111ac2158] Unknown symbol
  [0x0000000121d5a5b9] Unknown symbol
  [0x0000000121d5a2f8] Unknown symbol
  [0x0000000121d59f8c] Unknown symbol
  [0x0000000119cc6ea2] Unknown symbol
  [0x0000000119cc6c69] Unknown symbol
  [0x0000000119cc677f] Unknown symbol
  [0x0000000119cc45e1] Unknown symbol
  [0x0000000119cc402f] Unknown symbol
  [0x0000000119cc3ee2] Unknown symbol
  [0x0000000121d59ca4] Unknown symbol
  [0x0000000121d597f5] Unknown symbol
  [0x0000000120ac5b5d] Unknown symbol
  [0x0000000120ac573b] Unknown symbol
  [0x0000000120ac5b5d] Unknown symbol
  [0x0000000120ac573b] Unknown symbol
  [0x0000000121d56b58] Unknown symbol
  [0x0000000119ce361f] Unknown symbol
  [0x0000000121d56680] Unknown symbol
  [0x0000000121d5646b] Unknown symbol
  [0x0000000121d55e9e] Unknown symbol
  [0x0000000121d55a83] Unknown symbol
  [0x0000000121d4fce6] Unknown symbol
  [0x0000000116e32b35] Unknown symbol
  [0x0000000121d46f58] Unknown symbol
  [0x000000011a65b5e5] Unknown symbol
  [0x000000011a65b1e8] Unknown symbol
  [0x000000011a65a296] Unknown symbol
  [0x000000011a6591f2] Unknown symbol
  [0x000000011a7f1041] Unknown symbol
  [0x000000011a7ee849] Unknown symbol
  [0x000000011a7ee3aa] Unknown symbol
  [0x0000000116e35501] Unknown symbol
  [0x0000000121d46f58] Unknown symbol
  [0x000000011a65b5e5] Unknown symbol
  [0x000000011a65b1e8] Unknown symbol
  [0x000000011a65a296] Unknown symbol
  [0x000000011a6591f2] Unknown symbol
  [0x000000011a7f1041] Unknown symbol
  [0x000000011a7ee849] Unknown symbol
  [0x000000011a7ee3aa] Unknown symbol
  [0x0000000121d4856d] Unknown symbol
  [0x0000000121d46f58] Unknown symbol
  [0x000000011a65b5e5] Unknown symbol
  [0x000000011a65b1e8] Unknown symbol
  [0x000000011a65a296] Unknown symbol
  [0x000000011a6591f2] Unknown symbol
  [0x000000011a7f1041] Unknown symbol
  [0x000000011a7ee849] Unknown symbol
  [0x000000011a7ee3aa] Unknown symbol
  [0x0000000121d4de08] Unknown symbol
  [0x0000000121d46f58] Unknown symbol
  [0x000000011a65b5e5] Unknown symbol
  [0x000000011a65b1e8] Unknown symbol
  [0x000000011a65a296] Unknown symbol
  [0x000000011a65c866] Unknown symbol
  [0x000000011a65c05d] Unknown symbol
  [0x0000000121d46f58] Unknown symbol
  [0x000000011a65b5e5] Unknown symbol
  [0x000000011a65b1e8] Unknown symbol
  [0x000000011a65a296] Unknown symbol
  [0x000000011a65c866] Unknown symbol
  [0x000000011a65c05d] Unknown symbol
  [0x0000000121d46f58] Unknown symbol
  [0x000000011a65b5e5] Unknown symbol
  [0x000000011a65b1e8] Unknown symbol
  [0x000000011a65a296] Unknown symbol
  [0x000000011a6591f2] Unknown symbol
  [0x000000011a7f1041] Unknown symbol
  [0x000000011a7ee849] Unknown symbol
  [0x000000011a7ee3aa] Unknown symbol
  [0x0000000121d4ecec] Unknown symbol
  [0x0000000121d46f58] Unknown symbol
  [0x000000011a65b5e5] Unknown symbol
  [0x000000011a65b1e8] Unknown symbol
  [0x000000011a65a296] Unknown symbol
  [0x000000011a6591f2] Unknown symbol
  [0x000000011a7f1041] Unknown symbol
  [0x000000011a7f0bd2] Unknown symbol
  [0x0000000119fe4cdb] Unknown symbol
  [0x0000000119fe4885] Unknown symbol
  [0x0000000119fe475d] Unknown symbol
  [0x000000011a7d5e3c] Unknown symbol
  [0x000000011a7d4ac4] Unknown symbol
  [0x000000011a7d4820] Unknown symbol
  [0x0000000116e09a3c] Unknown symbol
  [0x0000000116e271b3] Unknown symbol
  [0x0000000111ac146c] Unknown symbol
  [0x000000010ecf6af0] dart::DartEntry::InvokeFunction(dart::Function const&, dart::Array const&, dart::Array const&, unsigned long)
  [0x000000010ecf9eb0] dart::DartLibraryCalls::HandleMessage(dart::Object const&, dart::Instance const&)
  [0x000000010ed285cc] dart::IsolateMessageHandler::HandleMessage(dart::Message*)
  [0x000000010ed587ce] dart::MessageHandler::HandleMessages(dart::MonitorLocker*, bool, bool)
  [0x000000010ed58da6] dart::MessageHandler::TaskCallback()
  [0x000000010eea115d] dart::ThreadPool::Worker::Loop()
  [0x000000010eea0faa] dart::ThreadPool::Worker::Main(unsigned long)
  [0x000000010edf7f69] dart::ThreadStart(void*)
  [0x00007fffce3c893b] _pthread_body
  [0x00007fffce3c8887] _pthread_body
  [0x00007fffce3c808d] thread_start
-- End of DumpStackTrace
🕐 ELAPSED TIME: 0:00:28.144037 for ../../bin/cache/dart-sdk/bin/pub run test -rcompact -j1 --no-color in dev/bots:
-----

Seems like a duplicate of https://github.com/dart-lang/sdk/issues/35974

authors: a-siva jonahwilliams


text:
dartdoc for parseIPv6Address ends up with an emoji

As seen on https://api.flutter.dev/flutter/dart-core/Uri/parseIPv6Address.html
::1
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
3ffe:2a00💯7031::1
::FFFF:129.144.52.38
2010:836B:4179::836B:4179

I think it'd be sane to just add backtics around the addresses to code-format them.

Opened  https://dart-review.googlesource.com/c/sdk/+/109317

Good catch. I'll accept the CL for now, and take it up with the DartDoc people.
I was not aware that DartDoc supported Github emoji syntax like :100: (:100:), and I'm not sure it should.

I'm afraid it might be part of the Markdown parsing stuff.  @jcollins-g or @kwalrath might know more.

It is part of the Dart Markdown package, but it is an optional extension that we don't have to have enabled.

authors: dnfield lrhn


text:
bug?

Analyzer Feedback from IntelliJ
Version information

IDEA AI-191.8026.42.35.5791312
<NO SDK>
AI-191.8026.42.35.5791312, JRE 1.8.0_202-release-1483-b49-5587405x64 JetBrains s.r.o, OS Mac OS X(x86_64) v10.13.6, screens 1440x900  Retina

Exception
Dart analysis server, SDK version 2.4.0, server version , FATAL error: NoSuchMethodError: The getter 'length' was called on null.
Receiver: null
Tried calling: length
#0      Object.noSuchMethod (dart:core-patch/object_patch.dart:50:5)
#1      FolderBasedDartSdk.getSdkProperty (package:analyzer/src/dart/sdk/sdk.dart:697:14)
#2      FolderBasedDartSdk.defaultSdkDirectory (package:analyzer/src/dart/sdk/sdk.dart:684:26)
#3      Driver._getSdkPath (package:analysis_server/src/server/driver.dart:758:33)
#4      Driver.start (package:analysis_server/src/server/driver.dart:394:28)
#5      main (file:///b/s/w/ir/k/src/third_party/dart/pkg/analysis_server/bin/server.dart:12:11)
<asynchronous suspension>
#6      _startIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:299:32)
#7      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:172:12)

For additional log information, please append the contents of
file:///private/var/folders/92/w1t6hptx5fq4_7nd87v8xy8w0000gn/T/report.txt.

This crash hasn't been reported since Dart 2.4.0. Please re-open if you see this crash again.

authors: srawlins wangwanchao


text:
language/label/label5_test crashes

https://dart-ci.appspot.com/log/analyzer-nnbd-linux-release/analyzer-asserts-weak-linux/2955/language/label/label5_test

https://dart-review.googlesource.com/c/sdk/+/149240


text:
Add a new allowLegacyUnsafeRenegotiation property to SecurityContext

Change
I propose that we add a new boolean allowLegacyUnsafeRenegotiation property to SecurityContext.
If set, it would allow client sockets to renegotiate TLS connections if requested to by the server (see https://github.com/dart-lang/sdk/issues/47841).
Rationale
The SecurityContext API  is already property based and implementing this as a constructor argument would be inconsistent with the rest of the API (where the only constructor argument is one that cannot be logically set after construction). Also, parameterizing all future functionality as constructor arguments does not seem scalable.
Impact
All classes that implements SecurityContext (without extends Mock or equivalent noSuchMethod implementation) will need to be updated.
There are no such classes in Flutter or at Google.
Mitigation
Users must implement the allowLegacyUnsafeRenegotiation property.

Devon has limited bandwidth so I'll ask for sign-off directly (counter to process):
@vsm, @Hixie, and @grouma - can you review and sign off for Dart, Flutter, and AngularDart respectively? Thanks!

I could not find any usages of SecurityContext in AngularDart. In fact the only usages of implements SecurityContext I could find were in the SDK.

Fine by me.

lgtm

Fixed in c286b76c2db394b72bd8ae79b32d024c2d25c52b

authors: Hixie brianquinlan grouma vsmenon


text:
The dart vm should not run a file, if it has the name of a sub-command

dart <p> will run the file <p> if it exists. Otherwise it will defer to dartdev and its command parsing
This is quite brittle - for example:
> echo "main() => print('All your base are belong to us');" > pub
> dart pub get
All your base are belong to us

This seems to be a way to override the dart commands in a local directory and cause very surprising (and potentially malicious) behavior.

See also: https://github.com/dart-lang/sdk/issues/51932

Working on a fix in https://dart-review.googlesource.com/c/sdk/+/361363

authors: lrhn sigurdm


text:
update breaking change policy

@athomas please review the updates to the breaking change policy.

See https://dart-review.googlesource.com/c/sdk/+/234104

authors: itsjustkevin kevmoo


text:
Fix any nullability and refactor typing model

Major changes:

Fixes an issue where we assume that all JSAnys should be nullable, whereas all anys should be nullable instead.
Changes typing model to go from IDLType to "raw" type, which is either an IDL declaration type or a dart:js_interop type, to a Dart type reference. This makes it easier to add generic types later as well.

Minor changes:

Reuses _Type and renames it to _RawType instead of using a record.
Removes unnecessary "isReturn" parameters as undefined can only appear in a return type per the web IDL spec.
JSVoid -> void as it's more readable.

Quite a large diff in the output but it's entirely either the void change or the any nullability change.

repo: dart-lang/web


text:
3do receiver does not work on the goldstar model

I am testing the receiver on a 3do goldstar, the led lights up but the ps4 controller does not pair while on the fz-1 it works perfectly.

If you press EN button on ESP32 after power up does it work?
You could also try to disconnect the 5v from console, and power it via usb.
If none of those work, maybe goldstar one don't have 200mA available at the front port.

Pressing the EN key solved the problem, also tested on other 3do models

Get a DS1233A-10+T&R PMIC supervisor and wire it on the EN pin, this will delay esp power up by holding EN 250ms. Also had a 1uF cap & 100uF cap between 3V3 and GND pin of ESP.
See transistor on the back of ESP, this is the PMIC.

Feel free to reopen if using PMIC do not solve it.

authors: darthcloud scp-electrocution

repo: darthcloud/BlueRetro


text:
feat: fix layout

feat: fix layout

merged


text:
Submit a very early message root index: 1674

chainId: 421614, index: 1674
https://darwinia.subscan.io/tx/0x431c74ef00a74ab0589be847826bccbd46d0352fdb906c430e0228bd30675ea8
chainId: 11155111, index: 59
https://darwinia.subscan.io/tx/0x01f1119faf8ee5bc5464d1aaf8d63e0f238b8a1912adb7b2559f1b69d83ebe0d

Submit signature expired.
https://github.com/subapidao/subapi/blob/main/src/SubAPIMultiSig.sol#L36

repo: darwinia-network/ormpipe


text:
chore: Create dashcore dir for each user in a loop

Issue being fixed or feature implemented
User dashcore directories are not consistent among the 3 users that we have on MNs.
What was done?
Adds a loop to create .dashcore directory for root, dash and ubuntu users.
How Has This Been Tested?
Tested on some testnet masternodes using dashd role.
Breaking Changes
n/a
Checklist:

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have added or updated relevant unit/integration/functional/e2e tests
[ ] I have made corresponding changes to the documentation

PR is into master so we can use this on testnet

Just wondering, why do we need three users for dash core?

Just wondering, why do we need three users for dash core?

We don't, I guess it is just for legacy reasons as the tool was being developed. We plan to tidy up and remove the dash user in the future.

authors: nmarley shumkov strophy

repo: dashevo/dash-network-deploy


text:
update with STR literature

updated here from recent lit

no you don’t need the lead up to the DOI ID. 2. Ugh no the alleles bit was rewritten into the first sentence I added and evaded capture

Get Outlook for iOShttps://aka.ms/o0ukef

From: Harriet Dashnow @.>
Sent: Friday, December 20, 2024 9:51:34 AM
To: dashnowlab/STRchive @.>
Cc: laurelhiatt @.>; Author @.>
Subject: Re: [dashnowlab/STRchive] update with STR literature (PR #133)
@hdashnow requested changes on this pull request.

In data/STRchive-loci.jsonhttps://github.com/dashnowlab/STRchive/pull/133#discussion_r1894162670:

@@ -224,9 +224,9 @@
"pathogenic_max": 68.0,
"ref_copies": 34.0,
"motif_len": 3,

"age_onset": "Typical: 20-49 @.:11436124], Range: 8 @.:15851746] - 78 @.***:19227892].",

"age_onset": "Typical: 20-49 @.:11436124], Range: 8 @.:15851746] - 83 @.***:10.17161/2tmg0f25OMIM:601068].",

Should this be formatted like this?
@.***:https://doi.org/10.17161/2tmg0f25; @omim:601068]

In data/STRchive-loci.jsonhttps://github.com/dashnowlab/STRchive/pull/133#discussion_r1894164453:

@@ -1513,7 +1513,7 @@
"mechanism": "GoF",
"mechanism_detail": "RNA gain-of-function: RNA gelation leading to misregulation of alternative splicing @.***:36169768].",
"source": [],

"details": "Intermediate alleles (35-49) associated with premutation @.:NBK1165]. 3%-8% of DM1 expansions contain variant repeats such as CCG and CGG, associated with later onset and milder phenotype @.:32851192]. In another study, interruptions of the CTG repeat with CCG, GGC, CTC or CAG motifs are estimated to occur in 3-11% of DM1 patients @.***:35741732].",

"details": "Overview of disease locus through 2024, including largest pathogenic allele of 4,000, described in Rimoldi et al review @.:39643839]. Intermediate alleles (35-49) associated with premutation @.:NBK1165]. 3%-8% of DM1 expansions contain variant repeats such as CCG and CGG, associated with later onset and milder phenotype @.:32851192]. In another study, interruptions of the CTG repeat with CCG, GGC, CTC or CAG motifs are estimated to occur in 3-11% of DM1 patients @.:35741732]. Alleles",

Was there supposed to be something after "Alleles" at the end?
—
Reply to this email directly, view it on GitHubhttps://github.com/dashnowlab/STRchive/pull/133#pullrequestreview-2517945675, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AULUPMCV2IV4ENH54BCHQBT2GRDJNAVCNFSM6AAAAABT6CSWKSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDKMJXHE2DKNRXGU.
You are receiving this because you authored the thread.Message ID: @.***>

repo: dashnowlab/STRchive


text:
merge #11640, #11599, #16112, #16127, #18635, #19249: thread safety and locking improvements

Overview
General backports from Bitcoin Core that deal with threadlocks, part of a larger effort to bring them to par with Core.
Contents
#11640, #11599, #16112, #16127, #18635, #19249
Disclosures

This is a work in progress and needs external review. Dash-specific changes have not been tested, only compilation and unit test success have been ensured.

pls see https://github.com/UdjinM6/dash/commit/ab285f172f6719e62a97ee1fdb9967cb45830465

repo: dashpay/dash

license: mit

license_source: bigquery


text:
expose fPrintToDebugLog to cmd-line as -printtodebuglog option

-printtodebuglog=0 will stop log output completely.
This should help people who run nodes 24/7 if/when we suddenly have intensive unpredicted log spam.

close & reopen for CI test trigger

@UdjinM6
So, is not in 12.1?
Debug.log bloat continue.

It is:
https://github.com/dashpay/dash/commit/93279e79447288358881d1ce269e7631bc182330

Ok, thanks! :+1:

authors: UdjinM6 akijuh schinzelh


text:
Fixed non-deterministic CSporkMessage hash function

CSporkMessage::GetHash() was including random data
in the hash due to 4 bytes of structure padding between the 32 bit
nSporkID and the following 64 bit nValue members.
This has been fixed by using CHashWriter which serializes the structure
data properly before hashing rather than relying on compiler defined behavior
such as structure alignment.  The underlying hash function is CHash256 which is
bitcoin's double SHA-256 hash.  HashX11 is not necessary here
because the hash is only used to identify distinct spork messages.

Nice, thanks!
utACK 5bb8dca

Nice find - utACK 5bb8dca

authors: UdjinM6 schinzelh tgflynn


text:
Parse ROWS as tuples in SQL kwargs

Allows us to pass tuples into SQL kwargs (such as in CREATE TABLE ... WITH (...) statements), which can be used in kwargs just as filters for read_* functions

Codecov Report

Merging #338 (09dfc7a) into main (3ac4136) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #338   +/-   ##
=======================================
  Coverage   95.76%   95.76%
=======================================
  Files          65       65
  Lines        2856     2856
  Branches      534      534
=======================================
  Hits         2735     2735
  Misses         73       73
  Partials       48       48

Impacted Files
Coverage Δ

dask_sql/utils.py
100.00% <ø> (ø)

Continue to review full report at Codecov.

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

rerun tests

rerun tests

rerun tests

authors: charlesbluca codecov-commenter

repo: dask-contrib/dask-sql


text:
Make CIs obey environment.yaml and ignoring useless steps

Fixes #539.
Fixes #324.

I'm going to merge in order to check also the docker images standalone builds.
Feel free to comment or open issues if you think I've broken something.

repo: dask/dask-jobqueue


text:
Test CI

As title

https://github.com/dask/dask-ml/pull/856 got this partway fixed.

Thanks @TomAugspurger

authors: TomAugspurger jrbourbeau

repo: dask/dask-ml


text:
Support dask arrays in keywords in map_blocks

Currently we only check *args for dask arrays, and convert anything in keyword arguments to concrete objects when they are passed into the user defined function.  We might consider also looking into the keyword arguments for dask arrays
In [1]: import dask.array as da

In [2]: def f(x):
   ...:     print(x.shape)
   ...:     return x
   ...:

In [3]: x = da.ones((10, 10), chunks=(5, 5))

In [4]: da.map_blocks(f, x, dtype=x.dtype).compute()
(5, 5)
(5, 5)
(5, 5)
(5, 5)
Out[4]:
array([[1., 1., 1., 1., 1., 1., 1., 1., 1., 1.],
       [1., 1., 1., 1., 1., 1., 1., 1., 1., 1.],
       [1., 1., 1., 1., 1., 1., 1., 1., 1., 1.],
       [1., 1., 1., 1., 1., 1., 1., 1., 1., 1.],
       [1., 1., 1., 1., 1., 1., 1., 1., 1., 1.],
       [1., 1., 1., 1., 1., 1., 1., 1., 1., 1.],
       [1., 1., 1., 1., 1., 1., 1., 1., 1., 1.],
       [1., 1., 1., 1., 1., 1., 1., 1., 1., 1.],
       [1., 1., 1., 1., 1., 1., 1., 1., 1., 1.],
       [1., 1., 1., 1., 1., 1., 1., 1., 1., 1.]])

In [5]: da.map_blocks(f, x=x, dtype=x.dtype).compute()
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-5-0ef3a9dd6003> in <module>()
----> 1 da.map_blocks(f, x=x, dtype=x.dtype).compute()

~/workspace/dask/dask/array/core.py in map_blocks(func, *args, **kwargs)
    696     numblocks = {a.name: a.numblocks for a in arrs}
    697     arginds = list(concat(argpairs))
--> 698     out_ind = tuple(range(max(a.ndim for a in arrs)))[::-1]
    699
    700     try:

ValueError: max() arg is an empty sequence

My only concern is that people might be relying on this behavior.
cc @jakirkham @stuartarchibald

Agree this would be useful. Overlaps with issue ( https://github.com/dask/dask/issues/3263 ).

This would be useful, but if not possible as there is reliance on the current behaviour, can the usage be spotted and a better error message generated?

Would add that IMHO this would be easier to implement once issue ( https://github.com/dask/dask/issues/3437 ) is fixed.

authors: jakirkham mrocklin stuartarchibald

repo: dask/dask


text:
da.unique:  TypeError: 'float' object cannot be interpreted as an integer

a=len(da.unique(da.array([1,2,2,2,2,3])))
it gives following error
TypeError: 'float' object cannot be interpreted as an integer

Hi, welcome to Dask. Please fill in all the information that the Bug Report template asks for, particularly your Dask version. Please also include a minimal, complete, verifiable example code to your post. That really helps us reproduce the issue to work out what to do. Thank you!
Extrapolating from your example, I do not get the same error, but I do get an error:
In [1]: import dask.array as da

In [2]: len(da.unique(da.array([1, 1, 1, 2, 2, 2])))
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Input In [2], in <cell line: 1>()
----> 1 len(da.unique(da.array([1, 1, 1, 2, 2, 2])))

File ~/mambaforge/envs/parquet/lib/python3.9/site-packages/dask/array/core.py:1503, in Array.__len__(self)
   1498 if np.isnan(self.chunks[0]).any():
   1499     msg = (
   1500         "Cannot call len() on object with unknown chunk size."
   1501         f"{unknown_chunk_message}"
   1502     )
-> 1503     raise ValueError(msg)
   1504 return int(sum(self.chunks[0]))

ValueError: Cannot call len() on object with unknown chunk size.

A possible solution: https://docs.dask.org/en/latest/array-chunks.html#unknown-chunks
Summary: to compute chunks sizes, use

   x.compute_chunk_sizes()  # for Dask Array `x`
   ddf.to_dask_array(lengths=True)  # for Dask DataFrame `ddf`

I'll go ahead and close this due to lack of activity, but please feel free to re-open it if needed!

authors: Nandeeshkkm7 bryanwweber pavithraes


text:
Check slicing inputs in dask.array

Previously we did not err in cases like the following:
x = da.ones(5, chunks=(3,))
x[[100]]

Now we do.
Possibly related to pydata/xarray#783
cc @shoyer @pwolfram

Besides the merge conflicts, this looks good to me.

Rebased.  Merging on passed tests

authors: jcrist mrocklin


text:
Support da.asanyarray on dask dataframes

This made operations like dask-ml pipeline.score work on dataframes (for whatever default scoring method I was using).

Thanks @jrbourbeau .  Care to press the green button?
(by the way, we almost always use "Squash and merge" except in the rare occasion where history is important and the author has taken special care to separate things into a few clean commits)

:smile:

authors: jrbourbeau mrocklin


text:
test-hdfs

test-hdfs
Closes https://github.com/dask/dask/issues/5230

Fixed I think. Just need to explicitly close the pool that we create in test_read_bytes. Thanks to whoever setup those CI scripts, it was relatively painless to debug this locally.
Merging on green.