Lazy loading of entities when running a query

I just want to scroll all entities of a specific kind in a lazy way. I have tried to add a limit but as intended I have only the number of specified results and not the entire dataset.
StructuredQuery<Entity> query = Query.entityQueryBuilder()
    .kind("user")
    .limit(100)
    .build();

QueryResults<Entity> results = datastore.run(query);

How to do it ? Did you plan to add a fetchSize() parameter ?
Without limit() I have a DatastoreException: Server returned an error INTERNAL 500

Hi @clardeur, thanks for reporting this issue.  Query results are already sent in batches, but it looks like the amount of data per batch is still causing you errors.  gcloud-java doesn't have control over the batch size; that's decided by Google Cloud Datastore.  Instead, gcloud-java could return you a cursor.  The reason QueryResults.cursorAfter() isn't already exposed is that it isn't supported for GqlQuery.  That support depends on Datastore v1beta3.
/cc @aozarov @mziccard: does this look like a viable solution: we could expose a cursor for StructuredQuery as a stopgap measure until cursorAfter becomes available.  With this change, users can do something like this:
StructuredQuery<Entity> query = Query.entityQueryBuilder()
    .kind("user")
    .limit(100)
    .build();
QueryResults<Entity> results = datastore.run(query);
while (results.cursorAfter() != null) {
  // do whatever you need to do with the current collection of results
  query = query.toBuilder().startCursor(results.cursorAfter()).build();
  results = datastore.run(query); // now results points to the next 100 results
}

@clardeur if you need a quick fix while this issue is being resolved, you could try setting offset in subsequent queries (instead of limit).  However, you can only set an offset of up to 1000 entities, and the results will be slow.

This behavior stems from a Google Cloud Datastore issue, which can be tracked here.
I've edited my comment above to mention that instead of introducing a new cursor, we will set cursorAfter to work around this issue.  Note that cursorAfter will be null until all the entities from the current QueryResults have been consumed.  I'm starting work on this issue now.

@ajkannan Thanks for your quick reply and the workaround.
I understand that the batch size is a restriction from Google Cloud Datastore and you don't have the control on it but I think that as an end-user of the gcloud-java client, I don't want to add some boilerplate code to iterate over queries, even if it should be possible for keeping a fine-grained control.
What do you think about it ? Could you expose on the API a ScrollQuery with a querySize() parameter that would use the limit() and `cursorAfter() internally ?

@clardeur Thanks for the reply. I think you are right, what we do elsewhere in gcloud-java is to also provide an iterateAll method that returns an iterator over the whole query result avoiding you to explicitly deal with multiple requests. That way you should be able to do something like:
StructuredQuery<Entity> query = Query.entityQueryBuilder()
    .kind("user")
    .limit(100)
    .build();
QueryResults<Entity> results = datastore.run(query);
Iterator<Entity> iterator = results.iterateAll();
while (iterator.hasNext()) {
  // do something with the entity iterator.next()
}

How do you see this?
@ajkannan do you think this could be feasible?

@mziccard the iterateAll() is what I need, like this I could build a Java 8 Stream on it. :+1:

@clardeur thank you for your input.
@mziccard, I think this case is different from the other gcloud-java list operations we have so far. Here are some differences:

limit != fetchSize - though they sound and feel similar (and indeed one could achieve the other's goal) they are not exactly the same. limit is an SQL construct that suggests no more results after that limit are necessary whereas fetchSize/chunkSize is a batching optimization.

Datastore supports a row/entity-level cursor (in concept, this does not work in v1beta2 but will work in the upcoming version) where as the other services only support page level cursor. Therefore the Datastore QueryResults is actually already an iterator that is equal to iterateAll, where "All" means all values constrained by the query, with an ability to stop at any point and use the cursor (once available) to resume.

The reason QueryResults is an iterator (rather than, lets say, a List) is because when a result is too big it is actually returned in chunks/batches, and gcloud-java gets new batches as needed. Currently, the decision of what is returned in one chunk/batch is the Datastore's and depends on both results size and fetch time. Unfortunately, the Datastore has a bug, GoogleCloudPlatform/google-cloud-datastore#85, where the service fails to detect that it should stop accumulating data when batch is too big for it to handle. This bug is known to be fixed in the upcoming version of the Datastore.

I do think a user-level batch size, which the server can use to further constrain its own chunking logic,
would be nice. I suggested it to the Datastore team but I am not sure if they will implement it.
Even without having a user-configurable batch size, I would expect this not to be an issue after Datastore fixes their bug. Datastore chunking will probably be sufficient in all cases (except maybe for clients that are very memory constraint).
@ajkannan's suggestion above is merely a workaround to avoid the Datastore bug until its fixed and without changing the API.
Indeed, gcloud-java could manipulate the query's limit (if given by the user or not) to make sure that we never ask for more than X results at a time (where X is is the user-configured batch size).  This would provide a library level chunking. Even in this case, there is no need for an additional iterateAll; the current iterator could do that.  However, using the current underlying Datastore API, we will not be able implement the same approach for GQL. I asked the Datastore team for advice about that as well.
For now, I suggest that we continue with #549, as it could be used as a workaround, does not effect the API and won't stop us from making any future changes if we choose too.
@clardeur Yes, once we move to Java 8 we will likely provide a Stream option instead as an alternative to plain Iterators. By then it is also possible that Datastore (as well as other services) will migrate to gRPC and provide streaming service calls.

Laving it open at least until the underlying issue is fixed.

I have tried the workaround and I get an error with the cursor.
java.lang.IllegalArgumentException: content is not a valid UTF-8
	at com.google.common.base.Preconditions.checkArgument(Preconditions.java:122)
	at com.google.gcloud.datastore.Cursor.<init>(Cursor.java:47)
	at com.google.gcloud.datastore.QueryResultsImpl.cursorAfter(QueryResultsImpl.java:104)

Thanks clardeur@
Yes, it seems that in this case the content of the cursor bytes is not a valid UTF-8.
We will remove this restriction and work with the Datastore team to make sure we could
still create a url-safe string value for it.

@aozarov ok I hope that this problem will be solved soon by the Datastore team or with this workaround because since the migration to the gcloud-java library this is a blocking point for us.
Thanks for your envolvement.

Hi @clardeur, we added a fix for the issue (#578).  Do you need us to a new release version on Maven for this change?

@ajkannan yes if it works, thanks.

Sure thing, I will make a release today.  Before I do this I want to resolve one more issue related to Datastore queries (#585).  Thanks for your patience!

Update: version 0.1.3 is now pushed and includes a fix for the IllegalArgumentException issue.

@ajkannan tested and LGTM ;)
You can closed it if you want.

gcloud-java-datastore version 0.1.7 now uses v1beta3 which fixes the original problem.  This work around should no longer be needed, so I'll close this issue.

Hi , I want to get the total count of entities in a kind in google cloud datastore. When the entities are 5 Million the following code doesnt return the count.
private static Datastore datastore;
datastore = DatastoreOptions.getDefaultInstance().getService();
Query query = Query.newKeyQueryBuilder().setKind(kind).build();
int count = Iterators.size(datastore.run(query)); //count has the entities count
Could you please share insights/alternative?


2023-12-10 to 2023-12-13 CWMS-Data-API Down

It appears that CWMS API has been down for the last few days.  Is this something that will be resolved soon?
SWAGGER says failed to load API definition and when I try it query it says HTTP Status 404  - Not Found.

We use this operationally as a backup at TVA (mainly due to the many LDM issues), so would love to have it working again.

We're working on it.
The good news is i think I know what's wrong and have a fix staged.
The bad news is we're having a slight infrastructure problem and we can't properly investigate until it's fixed which we're waiting on now.

Oh, and thank you for opening an issue. In the future would you think to come here and see, perhaps a pinned issue, to know what the current status is?
Or would it mailing list users can subscribe to make more sense to you?

Need to reset a password. Should be done within the next 20 - 30 minutes or so.

And it's back up.

Okay, this time I think it's back up.
Sorry about the confusion, I think I tested the wrong URL (one of our internal test sites that was working) and didn't notice the lack of recovery. I've restarted the service and it appears, for now to be picking everything up correctly.
Also our new, future primary, instance is available at https://cwms.sec.usace.army.mil/cwms-data.
While we are planning to have the existing URL point there eventual, or redirect, that is a permanent location and should be be saved for backup.

NOTE: the cwms.sec is downish again, there was a slight config error that I'm waiting to see if the correction gets automatically picked up.

I see it is working now, thank you!  We will save that other address as a backup.

FYI . I get 403 forbidden when trying to go to https://cwms.sec.usace.army.mil/cwms-data

Update on the cwms.sec address:

Might fault, that hasn't been made public yet and that one won't be
Our tentative plan is to make "water.sec.usace.army.mil" available but we're both working out some kinks can't make any changes to that system during the holidays anyways.


Remove child process property and stop() method from Machine

Removing as not required. One could always kill a process from outside of the lib.
Also killing should be discouraged and shutdown() should be preferred.

LGTM otherwise but could you add a one line in the commit+PR description about the reason?

Oh, I didn't realize this was against firec project. Not enough caffeine. :) Also now that we've a rationale here, I can reply to it:

Removing as not required. One could always kill a process from outside of the lib.

Yeah but that's not convenient.

Also killing should be discouraged and shutdown() should be preferred.

Of course but you can't possibly rely on shutdown to work as it requires guest OS cooperation.
The official Go SDK also provides this method btw. So I don't think this change is good.


Branding Config: Text color shown as white when not configured

Top Menu -> Global Settings -> Branding
Bug:
If the text color is not selected, it shows white in the color box but the color of the text would be black. Text box color should match the color of the text.`
i.e. The default text color is black (light mode) and white (dark mode) (see css vars) - we're always showing white when this has not been configured, rather than picking up the color from the theme css var.

PASS Verified in 2.6-head Commit ID cd3c9d7

In light mode (white background), go to global settings > branding
select 'show banner in Header, show banner in footer, and show consent banner on login screen'
in light mode, the text color is set to black
switch to dark mode
repeat step 2
in dark mode, the text color is set to white
switch to auto
repeat step 2
in auto, light mode is on due to 12:00 pm, and text color is set to black


Cant get Module to compile

First Error

So i Commented out both google() entries from the Build.Gradle
Then i get the following

And then I commented out the dependency and got the following

I Assume i'm doing something horribly wrong here.
Being a complete noob I'd love to have some idea what ?! :)

Im getting that error as well!
Tried couple of solution including yours, its not working.

This is the android/build.gradle file that I'm using in my own project with this lib:
// Top-level build file where you can add configuration options common to all sub-projects/modules.

buildscript {
    repositories {
        jcenter()
        google()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:3.1.2'

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
        classpath 'com.google.gms:google-services:3.2.1'
    }
}

allprojects {
    repositories {
        // Add jitpack repository (added by react-native-spinkit)
        mavenLocal()
        google()
        maven { url "https://jitpack.io" }
        jcenter()
        maven {
            // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
            url "$rootDir/../node_modules/react-native/android"
        }
    }
}

ext {
    compileSdkVersion = 26
    minSdkVersion = 16
    targetSdkVersion = 26
    buildToolsVersion = "27.0.3"
    supportLibVersion = "27.1.0"
    googlePlayServicesVersion = "15.0.1"
    firebaseVersion = "15.0.2"
    gradle3EXPERIMENTAL = "yes"
    androidMapsUtilsVersion="0.5+"
}

Without seeing your android/build.gradle file it's a bit difficult to parse exactly why you'd be having this problem.

I think maven { url "https://jitpack.io" } is the one thats causing the build to fail. Im gonna check it out when I get the chance and let u guys know!
Thanks!

I tried to copy to your build but it didnt work. I tried copying the maven{url "https://jitpack.io"} and It still didnt work.
My build :
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
    repositories {
        jcenter()
        google()
        maven {
                url "https://maven.google.com"
            }
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:3.1.2'

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
        classpath 'com.google.gms:google-services:3.2.1'
    }
}

allprojects {
    repositories {
        mavenLocal()
                google()
        jcenter()
        maven {
                url "$rootDir/../node_modules/react-native/android"
            }
            maven {
                url "https://maven.google.com"
            }
        maven { url "https://jitpack.io" }
    }
}

ext {
    compileSdkVersion = 26
    minSdkVersion = 16
    targetSdkVersion = 26
    buildToolsVersion = "27.0.3"
    supportLibVersion = "27.1.0"
    googlePlayServicesVersion = "15.0.1"
    firebaseVersion = "15.0.2"
    gradle3EXPERIMENTAL = "yes"
    androidMapsUtilsVersion="0.5+"
}

@TareqAbughosh, what's the exact error you're getting?

@eddieowens I had the same error the OP had. I fixed it  and its working great now then I had way more errors that I can't even remember... But they were dependencies errors. Just 1 question though.. Can I use this in the background? or at least register it as a service?(if yes, do u have any package that  does that? or at least a page where it explains how to do it?)
Heres my android/build.gradle file (I've more than just this package..)
`// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
repositories {
jcenter()
google()
}
dependencies {
classpath 'com.android.tools.build:gradle:3.1.4'
    // NOTE: Do not place your application dependencies here; they belong
    // in the individual module build.gradle files
}

}
allprojects {
repositories {
mavenLocal()
jcenter()
maven { url "https://jitpack.io" }
maven {url "maven.google.com"}
    maven {
        // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
        url "$rootDir/../node_modules/react-native/android"
    }
     google()
}

}
ext {
googlePlayServicesVersion = "+" // default: "+"
firebaseVersion = "+" // default: "+"
// Other settings
compileSdkVersion = 26 // default: 23
targetSdkVersion = 26 // default: 23
supportLibVersion = "26.0.2" // default: 23.1.1

}
subprojects {
project.configurations.all {
resolutionStrategy.eachDependency { details ->
if (details.requested.group == 'com.android.support'
&& !details.requested.name.contains('multidex') ) {
details.useVersion "27.1.0"
}
}
}
}`
Thanks a lot for the help and for this package!

@TareqAbughosh that's great! Yes this library works in the background as long as you follow the README but there are some problems with Android being inconsistent and I can't figure out why. I have a question posted here to hopefully get some help. If you have any suggestions as to why this may happen I'd love to hear them or if you can upvote my question to increase its visibility that'd be great. iOS has no problems though and works as expected.


Income mountains don't show but data is there somehow?

https://tools-dev.gapminderdev.org/tools/mountain

Gini data is not available from ws (measure name "inequality_index_gini")
it is likely that no such data existed in GW because we produced it specifically for vizabi tools. Maybe need to import that data from SG (where it is called just "gini")

There is GINI data but it's way less rich than in SG:
https://docs.google.com/spreadsheets/u/1/d/1Iztdl7Ddaz77K3HheGpkvQ1o_ui_L1s-sze_ZpTM0F0/pub
https://github.com/semio/ddf--gapminder_world/blob/master/output/ddf--datapoints--inequality_index_gini--by--geo--time.csv
Could that be reason why it's not showing, @angieskazka ?

Mountain chart data can't exist for regions because their shapes are combined from data.
So: move gini data from SG to GW, that should do the trick, can be under a different id (gini)

GW data is only for 1978 to 2010 and very sparse. Let's replace it with SG data

Yes, for sure, I'm just wondering why there's no income mountain at all now? There ís data, it's just sparse?


FR: Add capability to generate (and deploy) DANE records

Hi!
Provided you want to maintain DANE RFC6698 records, that is a task that is due every time an ACME certificate is renewed, which brings me to the conclusion that this functionality would be well placed alongside an ACME client implementation.
Functionality would be relatively simple and similar to DaneBot.
Is this a feature you would consider to implement?

Hello,
There is currently 2 ways to maintain such records using ACMEd:

Setting kp_reuse = true in the certificate's configuration so the private key is reused and the record doesn't change.
Using hooks to update the record when the certificate is renewed.

Obviously, the second option is quite tricky because of DNS propagation. Going this way, I think it's better to use a dedicated software to handle it instead of integrating it directly into ACMEd. This dedicated software would be made aware of a new certificate either by a hook or inotify and then manage the update of the DNS record and deployment of the certificate.

Thanks for the quick response.

I think it's better to use a dedicated software to handle it instead of integrating it directly into ACMEd.

What would be the advantage of implementing that functionality in a separate program?

acmed is modular software, that provides the ability to define hooks for such things. Using this modular approach makes acmed maintainable and light weight, while still being flexible enough to support stuff like setting dane records using a hook.
Why should this be included in acmed instead of being handled by a hook?

I like modular software as much as the next guy. It's a great design pattern.
In my mind a modular approach is best applied when the individual modules are useful on their own.
Right now I do not see a use case for a piece of software that updates DANE records outside of the context of certificate renewal.
Since - provided my train of thought is correct - that updater would only be used in conjunction with an ACME client anyways, I would couple both functionalities.
Besides, ACMEd already supports dns-01 challenges and therefore dynamic DNS updates, right? The DANE updater needs the same functionality and hence would need to duplicate code.

acmed uses hooks for the dns challenge as well, it doesn't implement solving this challenge on it's own.

Right now I do not see a use case for a piece of software that updates DANE records outside of the context of certificate renewal.

Same thing for tls-alpn-01 challenge validation. ACMEd doesn't do it by itself, it requires a dedicated software, for example tacd. Because it shares some common functions with ACMEd, tacd is developed within the ACMEd repository, but it still remains a different software.

Besides, ACMEd already supports dns-01 challenges and therefore dynamic DNS updates, right? The DANE updater needs the same functionality and hence would need to duplicate code.

Not on its own, it triggers hooks and those hooks a responsible for the challenge resolution. Same thing for http-01 challenge, it still hooks, although ACMEd ships some pre-defined hooks that can be used.

Thanks for the clarification, I wasn't aware of those details.
Maybe I should rephrase my request then...
Would it make sense for you guys to implement a DANE record updater under the same umbrella as ACMd and tacd that can be hooked from ACMEd?

No, it wouldn't. Such software already exists, it's DaneBot, and hooking it into acmed is just writing a small shell script.

No, it wouldn't.

Alright.
I am aware of DaneBot. It's good software. From a functionality standpoint it does virtually everything I desire.
There is one little challenge that I couldn't wrap my head around yet though.
If you have n domains for which you fetch TLS certificates via ACME, but only n-m domains do DANE, then you must run your cert deployment scripts from your ACME client for a subset of domains and from DaneBot for the second subset of domains, which feels weird and is inconsistent.
Maybe one should make DaneBot no-op capable so that call flow is unified for all certificates.
This is definitely a question far outside the scope of this feature request, which I am hereby closing.


iter: panic in iter.Pull is not recovered

Go version
devel go1.23-a3a584e4ab Wed May 29 13:52:34 2024 +0000
Output of go env in your module/workspace:
n/a since this was tested on the playground (gotip)

What did you do?
Run this on the playground
package main

import (
	"fmt"
	"iter"
	"runtime"
)

func main() {
	fmt.Println(runtime.Version())
	defer func() {
		if err := recover(); err != nil {
			fmt.Println(err)
		}
	}()
	next, _ := iter.Pull[int](func(yield func(int) bool) {
		yield(1)
		panic("!")
	})
	fmt.Println(next())
	fmt.Println(next())
}

https://go.dev/play/p/_BjecTfmPE8?v=gotip
What did you see happen?
The panic is not caught at recover()
devel go1.23-a3a584e4ab Wed May 29 13:52:34 2024 +0000
1 true
panic: !

goroutine 4 [running]:
main.main.func2(0x0?)
	/tmp/sandbox4071758638/prog.go:18 +0x2e
iter.Pull[...].func1()
	/usr/local/go-faketime/src/iter/iter.go:75 +0x10b
created by iter.Pull[...] in goroutine 1
	/usr/local/go-faketime/src/iter/iter.go:59 +0x119

What did you expect to see?
The panic is caught at recover()

cc @golang/compiler

iter.Pull isn't explicitly defined as running on another goroutine, but in practice that is what it's doing, leading to the behavior you see here.
We've gone back and forth on whether it should be documented in terms of goroutine+channel semantics (that is, iter.Pull is defined as having the semantics of running the iterator on another goroutine, with next and stop communicating with it via channel), but decided to leave it more ambiguous for now since it accepts more possible implementations, including the current one (though goroutine+channel semantics are a valid implementation of iter.Pull).
I think maybe what does have to be documented is that panics do not propagate through an iter.Pull iterator. I think this must be true of any implementation (and AFAICT, it is true of all the implementations we've thought of so far), because the abstraction here is something like a coroutine, and it's not clear to me that panics should unwind through coroutine boundaries.
CC @dr2chase @aclements

iter.Pull isn't explicitly defined as running on another goroutine, but in practice that is what it's doing, leading to the behavior you see here.

IIUC, the actual implementation is a coroutine rather than a goroutine. If the semantics is the same as goroutine, I was wondering why a coroutine is used instead of a goroutine. Is this for performance? If so, now we have issues around LockOSThread with iter.Pull (#67499), isn't this a kind of early optimization? Or, might the semantics be changed in the future?

IIUC, the actual implementation is a coroutine rather than a regular goroutine.

It's really a fast, direct switch between goroutines that doesn't go through the scheduler. This is functionally similar to a coroutine, hence why it's called coroswitch in the implementation.

If the semantics is the same as goroutine, I was wondering why a coroutine is used instead of a regular goroutine.

The semantics are explicitly not the same as a goroutine. The semantics are a little less well-defined than that at the moment.
Also, even if we formalized the notion of coroutines in the language, I'm not sure I agree that a panic should be able to cross coroutine boundaries.

Is this for performance? If so, now we have issues around Cgo with iter.Pull (https://github.com/golang/go/issues/67499), isn't this a kind of early optimization? Or, might the semantics be changed in the future?

Yes, it's for performance. The direct switch is very, very cheap compared to implementing the same thing with channels. I get what you're saying about the optimization possibly happening too early (this was discussed at length), but the performance of iter.Pull was considered too important. The issues around cgo will hopefully not be permanent, but they're also a big part of why the semantics are not defined as goroutines.

Are there many languages where an exception in a coroutine isn't propagated?

An exception in a coroutine is caught in Ruby and JavaScript:

Ruby
https://try.ruby-lang.org/playground/#code=def+foo
++Fiber.new+do
++++raise+'error!'
++end
end

begin
++f+%3D+foo()
++f.resume
rescue+%3D>+e
++puts+e
end
&engine=cruby-3.2.0

JavaScript
https://jsfiddle.net/zwc0rfay/1/

Oh, that's interesting... At least in JS and Ruby it makes sense that exceptions would propagate through. On the caller side it just looks like calling a function, especially with the syntax.
I think what's tricky about Go is that it's already possible for functions to do more complicated things with a closure (like sending it to another goroutine) inside of a function call, and this is a somewhat normal thing to do.
That being said, I do think you changed my mind about:

Also, even if we formalized the notion of coroutines in the language, I'm not sure I agree that a panic should be able to cross coroutine boundaries.

I think there's a good argument to be made about that.
However, for iter.Pull specifically, it was a soft goal of ours that a possible implementation of iter.Pull would be using just plain goroutines and channels as part of the semantics. That goal does seem to require panics not to propagate.

A goroutine implementation could capture the panic and send it to the other side to be re-panic'd when next/close get invoked. https://go.dev/play/p/ltXl_x_CPvm

@jimmyfrasche That's true, that you can re-panic, but what I meant by propagation is that the original panic stack follows (for example, if the panic is uncaught, you lose the context by re-panicking). But maybe that doesn't matter? The JS example at least doesn't seem to provide any context on an uncaught exception (though that alone isn't a reason to replicate the behavior).
Honestly, I don't know in this case. I think I'd personally still lean toward the panic not propagating just because that seems more consistent within the language. Is there any existing API that runs a function on another goroutine and possibly re-panics like this? Coroutines don't currently exist in the language, so it would be a little weird to say iter.Pull behaves like coroutines in other languages.

After discussing offline with @aclements, I think I'm convinced that we should propagate panics. We can start out by just re-panicking: the user-visible behavior is the most important part for this release cycle.
Here's the information that changed how I was leaning.
Although the primary example that came to mind (exec.Command) doesn't propagate panics from the goroutines it starts, there are a few examples of where, going forward or already today, we do propagate panics.

sync.OnceFunc explicitly propagates panics from its callback, and does so even if the sync.OnceFunc is accessed multiple times (it won't surprisingly succeed on future calls). Although it doesn't create a goroutine, it is an API that takes a function an executes it on behalf of the caller.
#53757 is an accepted proposal to propagate panics for golang.org/x/sync/errgroup through Wait.

Furthermore, we wanted to leave the door open to a compiler-driven CPS transform as a valid implementation of an iter.Pull call. That implementation, going against the goroutine implementation, actually does suggest propagating panics.
And this is a situation of "if we can, we should," and we definitely "can," since the implementation controls the creation of the iter.Pull. While std is currently a bit inconsistent about forwarding panics, my general sense is that the project wants to move toward propagating them.
I will send a CL later to forward panics.

I've retitled this issue to focus on the API question rather than the implementation. The core API question is what should happen if the sequence function passed to iter.Pull panics. Regardless of the mechanics of iter.Pull, we have two options: passing it through to the caller of iter.Pull, or crashing the program. Whether its implemented with goroutines+channels, coroutines, or CPS transform doesn't matter, since any of those implementations can support either semantics (though obviously which is more "natural" varies).
I'm also leaning in favor of passing the panic through. I worry about making changes like this so late in the release, but I think this will also be a simple change. I think once @mknyszek has prepared a CL, we'll have to assess its risk and weigh requesting a freeze exception.
Passing the panic through is consistent with the APIs @mknyszek pointed out above. I think it's also more consistent with where we landed on panic handling of for-range loops. Supposing you have a Zip implementation that uses iter.Pull for one of the two iterators, consider:
for x := range Zip(a, b) { ... }

It seems unfortunate that a panic in a passes through and runs defers on the stack (which may recover the panic), but a panic in b immediately crashes the program. If we instead pass panics through iter.Pull, then a panic in either will behave roughly the same.

I believe I intended panics to forward: https://research.swtch.com/coro#panic.

I have an implementation that propagates panics, and also converts a runtime.Goexit in the iterator into a panic originating from next and/or stop. Regarding runtime.Goexit, are those semantics we want? I picked that because it was convenient, but I'm not actually sure if there's anything better.
Also, the implementation is pretty simple, so I think it would be OK to land during the freeze, especially since nobody is using iter.Pull yet. (That is, the risk is low.) https://go.dev/cl/589136 and https://go.dev/cl/589137 are the CLs.

I'm requesting a freeze exception for this issue. See my previous comment for a rationale.
CC @golang/release

Thanks!

https://go.dev/cl/589136

Woudn't stack trace info be continuous?

converts a runtime.Goexit in the iterator into a panic originating from next and/or stop. Regarding runtime.Goexit, are those semantics we want?

My inclination would be to turn Goexit from the iterator into a Goexit on the caller. That's sort of "maximum" transparency to the implementation mechanism and most symmetric in my zip example.

Woudn't stack trace info be continuous?

I'm not positive I understand your question, but with that implementation it's true that the stack trace from seq will be lost, and the stack trace will terminate a closure in Pull. Addressing that would require substantially more runtime mechanism, but I also think that's okay to do in a later release.
(Just recording my thoughts on this: I think we'd do this by having the panic unwinder know that it needs to hop goroutines when it leaves the Pull goroutine, and leave the Pull goroutine around until the panic ends. After that hop, any defers would have to run on the "parent" goroutine, and traceback from the defer would have to understand to jump to the Pull goroutine once it got out of the defers, and then back over to the parent goroutine when it reaches the end of the Pull goroutine. I believe this can be arbitrarily nested. This all sounds pretty complicated, but I think it may not be too bad if we have a mechanism for marking the frames that have these special goroutine jumps.)

Yeah that's what I wanted to know, thanks

I updated the changes to propagate runtime.Goexit instead of converting it into a panic.

Here is a summary of the semantics we plan to set for iter.Pull before release:

If stop is called before next ever is, then the iterator passed to iter.Pull is guaranteed to never execute.
If the iterator passed to iter.Pull panics, then that panic propagates once through to whoever is waiting on that iterator's latest iteration (a next or stop call). Future calls to next return the zero value and false. Future calls to stop do nothing.
If the iterator passed to iter.Pull calls runtime.Goexit, then that runtime.Goexit propagates once through to whoever is waiting on that iterator's latest iteration (a next or stop call). This effectively destroys the entire chain of goroutines waiting on nested calls to iter.Pull. Future calls to next return the zero value and false. Future calls to stop do nothing.

These are the semantics I have implemented in CL 590075, CL 589137, and CL 589136 respectively.
Note: a stop may observe a panic or runtime.Goexit because the iterator needs a chance to clean up when yield returns false. It may panic during that clean up.

We reviewed this in a meeting, and agreed to approve its "freeze exception" bit. Thanks for letting us know.

Discussed in proposal review. We decided that since forwarding panics was intended to be part of the behavior of iter.Pull, this is really just an implementation oversight. Taking out of the proposal process.


Modified smali related paths based apktool change

apktool seems to unpack the apk files to different paths.  Admittedly I don't understand the inner workings of whats happening, but I noticed the unpacked apk had smali files at a different path than what was expected by the sign-android script.
My apktool version (in case its relevant):
Apktool v2.5.0 - a tool for reengineering Android apk files
with smali v2.4.0 and baksmali v2.4.0

I also shifted mv $SRC $DEST down a few lines as this seemed to be done too early for the sed modifications to apply.

Hi @enahum - I tested the original version of the script with Apktool v2.4.1 and I wasn't able to make it work for Android.
I tested the changes I'm proposing in this PR with both v2.4.1 and v2.5.0 and was able to successfully install and run Mattermost.

Hi @enahum - I tested the original version of the script with Apktool v2.4.1 and I wasn't able to make it work for Android.
I tested the changes I'm proposing in this PR with both v2.4.1 and v2.5.0 and was able to successfully install and run Mattermost.

@enahum  anyone else from engineering need to review?  Or could @justinegeffen / @cwarnermm be the 2nd reviewer?

@enahum  anyone else from engineering need to review?  Or could @justinegeffen / @cwarnermm be the 2nd reviewer?

This is good to merge, no need for a second review of any kind

This is good to merge, no need for a second review of any kind


Update CMIP6_CV for CanESM5/CanESM5-CanOE

The Canadian Centre for Climate Modeling and Analysis (CCCma) recently updated the description for CanESM5 and added a new variant of the model called CanESM5-CanOE. These changes were incorporated via https://github.com/WCRP-CMIP/CMIP6_CVs/commit/623dc6f6b361a431f9aa9963075a79da68af1f4a and https://github.com/WCRP-CMIP/CMIP6_CVs/commit/cc3372563956c496a04090f680a8f9fedcf2ab6d.
At your earliest convenience please update https://github.com/PCMDI/cmip6-cmor-tables/blob/master/Tables/CMIP6_CV.json accordingly.
Thanks!

I just noticed that it looks like that file gets updated via a cronjob. I'll close this issue once the file is updated.


[routing-manager] fix DiscoveredPrefixTable entry leak

This commit fixes the bug of DiscoveredPrefixTable that entries might be leaked and never reclaimed by FreeEntry.

@simonlingoogle , the scan-build check is failing:
[320/574] Building CXX object src/core/CMakeFiles/openthread-mtd.dir/border_router/routing_manager.cpp.o
/home/runner/work/openthread/openthread/src/core/border_router/routing_manager.cpp:1876:5: warning: Assigned value is garbage or undefined
    Entry *next = mNext;
    ^~~~~~~~~~~   ~~~~~
1 warning generated.

Can you help address?

@simonlingoogle , the scan-build check is failing:
[320/574] Building CXX object src/core/CMakeFiles/openthread-mtd.dir/border_router/routing_manager.cpp.o
/home/runner/work/openthread/openthread/src/core/border_router/routing_manager.cpp:1876:5: warning: Assigned value is garbage or undefined
    Entry *next = mNext;
    ^~~~~~~~~~~   ~~~~~
1 warning generated.

Can you help address?

It may be better to just remove the Clear() calls in the InitFrom() methods (to avoid overwriting the mNext`).
I think this will avoid this issue as well.

Added PR https://github.com/openthread/openthread/pull/7945 which removes the Clear() calls, also updates the unit test to cover it. (so we can merge this fast). Thanks again for finding this.

@simonlingoogle , thanks for identifying this issue!
Superseded by #7945.


[epoch change][codemod] rename ValidatorChangeProof to EpochChangeProof

Motivation
With on-chain config, epoch can change not only when validator set
changes, renaming better reflects it.
Have you read the Contributing Guidelines on pull requests?
Y
Test Plan
Existing tests.
Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/libra/website, and link to your PR here.)

:umbrella: The latest upstream changes (presumably b9d0b8a70083e0db0d0424ecb75c10254d9eeaa2) made this pull request unmergeable. Please resolve the merge conflicts.

yeah, I can't do this without IDE help

@bors-libra r=davidiw

:pushpin: Commit 6ac682d has been approved by davidiw

:hourglass: Testing commit 6ac682da3cb9cbdfcf044587553ec04d6aecbc24 with merge 513f2731ed5fe9d636a35ecef5d31227633b0275...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: davidiw
Pushing 513f2731ed5fe9d636a35ecef5d31227633b0275 to master...


Nullable int comparison

This query works without EF Plus:
 int? siteId = null;
 var result = _dbContext.Sites.Where(s => siteId == s.SiteId).ToList();

if I add this line (from QueryInterceptorFilterExtensions):
   this.Filter<ISoftDeletable>(q => q.Where(a => !a.IsDeleted));
then it does not work anymore, because the generated SQL is something like 'siteId = NULL' instead of 'siteId IS NULL'
As a workaround I can use
var result = _dbContext.Sites.Where(m => siteId == null ? m.SiteId == null : siteId == m.SiteId).ToList();
which is nasty.

Hello @huer12 ,
Thank you for reporting,
We will try to look at it next week.
Best Regards,
Jonathan

Hi Jonathan
Did you already find some time to look at it?
Regards,
Roman

Hello @huer12 ,
Sorry for the delay and thank you for the remember. I have fixed this issue today.
The problem was because the right DbQueryCommandTree constructors to use was not part of the EF 6.0.0 but added later.
The fix will be available for next Monday.
Best Regards,
Jonathan

Hello @huer12 ,
The v1.6.20 has been released.
The issue should be fixed,
Best Regards,
Jonathan

Thanks a lot, I verified it and it works.


envoyproxy instance svc update error after gateway restart

Description:

What issue is being seen?
after gateway restart, gateway will update the exist envoy proxy instance, so there will encounter an error, seem like https://github.com/envoyproxy/gateway/blob/main/internal/infrastructure/kubernetes/infra.go#L74 miss add the original info to new svc.

Repro steps:

apply an gateway cr and envoyproxy cr, check an envoy proxy instance whether created in envoy-gateway-system, then restart the gateway.

Environment:

the main branch code;
k8s server: v1.19.8

Logs:

2023-04-23T11:00:59.473+0800    ERROR   runner/runner.go:68     failed to create new infra      {"runner": "infrastructure", "error": "failed to update service envoy-gateway-system/envoy-default-eg-64656661: Service "envoy-default-eg-64656661" is invalid: spec.clusterIP: Invalid value: "": field is immutable"}
github.com/envoyproxy/gateway/internal/infrastructure/runner.(*Runner).subscribeToProxyInfraIR.func1
gateway/internal/infrastructure/runner/runner.go:68
gateway/internal/message.HandleSubscription[...]
gateway/internal/message/watchutil.go:28
github.com/envoyproxy/gateway/internal/infrastructure/runner.(*Runner).subscribeToProxyInfraIR
gateway/internal/infrastructure/runner/runner.go:57

this if always be false due to svc.spec.ClusterIP/svc.spec.CheckNodePort/svc.spec.*.nodePort always different.

cc @arkodg , this seems a issue from the begining.


Duplicate position identifier in sw-users-permissions-user-detail

In src/Administration/Resources/app/administration/src/module/sw-users-permissions/page/sw-users-permissions-user-detail/sw-users-permissions-user-detail.html.twig
There are two position identifiers which is have the same value {{sw-users-permissions-user-detail}} but position id should be unique

[public] Shopware automated response: This issue is linked to the internal issue: NEXT-38642
[created from NEXT-38642, comment 499530]


Update MD file on new branch 2017-20-10_09-11-33

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestCon.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Automated cherry pick of #2159: elb bugfix

Cherry pick of #2159 on release/2.11.
#2159: elb bugfix

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.11@2984e57). Click here to learn what that means.
The diff coverage is 0%.

@@              Coverage Diff               @@
##             release/2.11   #2160   +/-   ##
==============================================
  Coverage                ?    7.1%
==============================================
  Files                   ?     451
  Lines                   ?   70824
  Branches                ?       0
==============================================
  Hits                    ?    5029
  Misses                  ?   65383
  Partials                ?     412

Flag
Coverage Δ

#aFlag
7.1% <0%> (?)

Impacted Files
Coverage Δ

pkg/multicloud/aws/disk.go
0% <0%> (ø)

...g/compute/models/loadbalancercachedcertificates.go
3.93% <0%> (ø)

pkg/multicloud/aws/storagecache.go
0% <0%> (ø)

pkg/multicloud/aws/aws.go
0% <0%> (ø)

pkg/compute/models/loadbalancercertificates.go
4.63% <0%> (ø)

pkg/multicloud/aws/utils.go
0% <0%> (ø)

pkg/compute/models/loadbalanceracls.go
3.91% <0%> (ø)

pkg/compute/models/purge.go
0% <0%> (ø)

pkg/multicloud/aws/region.go
0% <0%> (ø)

pkg/compute/models/loadbalancercachedacls.go
2.79% <0%> (ø)

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 2984e57...384cbe0. Read the comment docs.

/approve
/lgtm


Context Propagation

I'm creating this issue to provide initial insight into the Context propagation design.
OT Tracers with custom propagation
One of the important questions has been what kind of custom propagation is done by Tracers. I reviewed DataDog. This is a simplified list of their extra needs:

Need to provide events around Span operations (events after a Span has been activated or after it has been closed, for example).
Need to do extra checks in order to either close or not the Span upon Scope being closed (similarly to how we do it for the ref-counting ScopeManager in opentracing-util). This checks are done on the actual Span underneath and its internal features.
Stores a list of extra Context objects, which can be queried besides the TLS storage.
Uses an actual Deque for storing the Scope objects (opposed to how this is done in OC/OT).

Tracers with bridges to OT
I reviewed Brave-Opentracing and found out it uses its very own context propagation layer. This one in turn is similar to the OC one, including the storage of the propagation layer exposed as a SPI component, in case the users wants to override it.
I quote the original feedback from Elastic, which also offers OT support as a bridge layer:

They have an existing context propagation mechanism in place, which doesn’t implement the OT interfaces, and hence bridges are built. This propagation mechanism is leveraged for their auto instrumentation mode too, and it co-exists with the manual mode (“mix and match mode” is called).

If Scope objects are created by an in-place propagation mechanism, they would be detached from the ones the auto agent creates.

Implementation wise, they use thread-local data, but they don’t use an implicit stack of Scope objects, but an explicit one (it keeps all the previously active Scope objects).

@carlosalberto Thanks for the review.  I'd like to clarify something...
I don't think the added complexity of what we have currently implemented is needed and we should stick to a simple thread local based context.
I originally implemented it the way you described to support using a custom context with frameworks that have a static context like Ratpack. The idea being a thread local context would be used unless on a particular thread managed by a different context.
In practice, Ratpack seems to be the only framework I've come across where this is useful and I think the complexity in the core should be instead shifted to complexity in the instrumentation.
That said, I appreciate you considering our needs and asking for feedback.  Happy to answer further questions.

I'd like to add... I think it would be valuable to add one thing to the OT scope api and that is a listener... something that can be used for things like MDC support.

We're talking about in-process propagation only here, correct? Maybe change the title accordingly.

@yurishkuro IIRC Bogdan doesn't like the term "in-process" ;)

@tylerbenson You mean an event listener layer?

Yeah. A way to receive callbacks when a span and scope starts and stops.

For reference, we are currently discussing this item in https://docs.google.com/document/d/1B9TDx1-ynlpD2IzYVUjIqN-ImV1Uu9_mfw0fT37rJyo/edit?usp=sharing ;)


Update for Chart js 2.0

Update for Chart js 2.0

Hi, are you still planning to update to Chart.js 2.X? Thank you!


PyPI / pip installation

I find this extension very useful, but it seems there isn't a PyPI (pip) installation at the moment? Would be great to have that for ease of use.

Oh yes. Actually I never released things on PyPI so I don't really know how to do it. Unfortunately, I don't have much time until next year due to my PhD thesis so I won't be able to make a release for that soon.
I will try to find some time for that but I cannot guarantee anything :(

Haha, I am also doing a PhD. I think I will be able to help you with this, as I have released projects on PyPI before. Are you happy for me to submit a PR with the changes at some point soon?

I would be happy but I don't know whether I'll have time to look at it!

It’s pretty easy actually.
Step 0: create a pypi account, set up 2FA, …
Then:

create an GitHub environment for this project called pypi

create .github/workflows/ci-cd.yml:
jobs:
  pypi-publish:
    name: Upload release to PyPI
    runs-on: ubuntu-latest
    environment:
      name: pypi
      url: https://pypi.org/p/<your-pypi-project-name>
    permissions:
      id-token: write  # IMPORTANT: this permission is mandatory for trusted publishing
    steps:
    # retrieve your distributions here

    - name: Publish package distributions to PyPI
      uses: pypa/gh-action-pypi-publish@release/v1

fill out a single form

create a release on GitHub

repeat step 1-4 for each project, and step 5 for each release


Xcode 11.2 and RealmSwift Primary key property issue

!!! MANDATORY TO FILL OUT !!!
I get the Primary Key for a particular RealmObject not found when I run my project using XCode11.2. Tried all the steps whatever mentioned in issue (6163)
Goals

Expected Results
Should not crash the app for Primary key property.
Actual Results
*** Terminating app due to uncaught exception 'RLMException', reason: 'Primary key property 'email' does not exist on object 'UserManagementModel''
Steps to Reproduce

Create a realm object class with a property defined
Create some method to save objects
Retrieve object stored in the realm(Retrieving the object before saving into Realm. Expected result should return an empty list but getting a crash.)

Code Sample
    class UserManagementModel: Object {
          dynamic  var email: String = ""
          dynamic  var index: Int = 0
          dynamic  var userId: String = ""
          dynamic  var syncStatus: Bool = false
          dynamic  var isDeleted: Bool = false

    override class func primaryKey() -> String? {
        return "email"
    }
}

//Save.
   func saveUserList(userObject: UserManagementModel) {
        realmObject.beginWrite()
    realmObject.add(userObject, update: .modified)
        do {
            try realmObject.commitWrite()
        }catch{
            print(error)
        }
    }
// Reterive
func getUserList()->[UserManagementModel] {
        let predicate = NSPredicate(format:"syncStatus == %@",NSNumber(value: false) )
        let userList = realmObject.objects(UserManagementModel.self).filter(predicate).toArray(UserManagementModel.self)
        return userList
    }

Realm framework version: Realm 4.0.0
Xcode version:  11.2 (11B52)
iOS/OSX version: IOS 12.4 / 10.15.1

@Channu2 Because you forgot to add @objcMembers or @objc to your model properties.
dynamic properties in Realm object should be declared as @objc.
To change your code like the following, it fixes the error.
@objcMembers
class UserManagementModel: Object {
          dynamic  var email: String = ""
          dynamic  var index: Int = 0
          dynamic  var userId: String = ""
          dynamic  var syncStatus: Bool = false
          dynamic  var isDeleted: Bool = false

    override class func primaryKey() -> String? {
        return "email"
    }
}

See also https://realm.io/docs/swift/latest/#property-attributes

@Channu2 Because you forgot to add @objcMembers or @objc to your model properties.
dynamic properties in Realm object should be declared as @objc.
To change your code like the following, it fixes the error.
@objcMembers
class UserManagementModel: Object {
      dynamic  var email: String = ""
      dynamic  var index: Int = 0
      dynamic  var userId: String = ""
      dynamic  var syncStatus: Bool = false
      dynamic  var isDeleted: Bool = false

    override class func primaryKey() -> String? {
        return "email"
    }
}

See also https://realm.io/docs/swift/latest/#property-attributes

@Channu2 Because you forgot to add @objcMembers or @objc to your model properties.
dynamic properties in Realm object should be declared as @objc.
To change your code like the following, it fixes the error.
@objcMembers
class UserManagementModel: Object {
      dynamic  var email: String = ""
      dynamic  var index: Int = 0
      dynamic  var userId: String = ""
      dynamic  var syncStatus: Bool = false
      dynamic  var isDeleted: Bool = false

    override class func primaryKey() -> String? {
        return "email"
    }
}

See also https://realm.io/docs/swift/latest/#property-attributes

@Channu2 Because you forgot to add @objcMembers or @objc to your model properties.
dynamic properties in Realm object should be declared as @objc.
To change your code like the following, it fixes the error.
@objcMembers
class UserManagementModel: Object {
      dynamic  var email: String = ""
      dynamic  var index: Int = 0
      dynamic  var userId: String = ""
      dynamic  var syncStatus: Bool = false
      dynamic  var isDeleted: Bool = false

    override class func primaryKey() -> String? {
        return "email"
    }
}

See also https://realm.io/docs/swift/latest/#property-attributes

@Channu2 Because you forgot to add @objcMembers or @objc to your model properties.
dynamic properties in Realm object should be declared as @objc.
To change your code like the following, it fixes the error.
@objcMembers
class UserManagementModel: Object {
      dynamic  var email: String = ""
      dynamic  var index: Int = 0
      dynamic  var userId: String = ""
      dynamic  var syncStatus: Bool = false
      dynamic  var isDeleted: Bool = false

    override class func primaryKey() -> String? {
        return "email"
    }
}

See also https://realm.io/docs/swift/latest/#property-attributes

@kishikawakatsumi Thank you for your response i tried with adding @objcMembers or @objc to properties got same issue


Changing SQL Connection Reference (virtual connector) leads to 403 Forbidden error

If you create a SQL-based virtual table with the virtual table provider and use, for example, SQL Server authentication for the connection, and then change the connection on the connection reference to Azure AD Integrated, the virtual table connector no longer returns data. The underlying error is "The remote server returned an error: (403) Forbidden.". (Note that I specified an Azure AD account that has full rights in the Azure SQL database.)
The documentation should indicate whether changing the connection for a virtual table created with the virtual table provider is supported and, if so, provide the steps to get it to work.

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

ID: 5490be6b-9f4c-6425-d232-e89e542e40dd
Version Independent ID: 5490be6b-9f4c-6425-d232-e89e542e40dd
Content: Create virtual tables using virtual connectors (Microsoft Dataverse) - Power Apps
Content Source: powerapps-docs/maker/data-platform/create-virtual-tables-using-connectors.md
Service: powerapps
Sub-service: dataverse-maker
GitHub Login: @NHelgren
Microsoft Alias: nhelgren

Thanks for your comment, @tdutch1. This issue has been assigned to the doc author for review.


docs: clarify required

At first I thought I needed to specify the names my webpack build had generated in cssUrls, but if webpackExtractedCss is true you should definitely not do that, since those css files will be loaded twice

Is the webpack plugin working well for you? That's the main thing I'm wanting feedback for


Tests should not rely on filesystem-writability

The current tests assume that the filesystem in which the tests themselves live is writable by the test-running user.
Some locations that I have identified are:

https://github.com/kivy/kivy/blob/3052803ad3cbdc5505c14d6bc2034e387e2f2e2c/kivy/tests/common.py#L48
https://github.com/kivy/kivy/blob/3052803ad3cbdc5505c14d6bc2034e387e2f2e2c/kivy/tests/common.py#L179

I am currently running into problems with this in the context of https://github.com/kivy/kivy/issues/5367
However, the problem is more general. A quite common scenario that's made impossible by the assumption is the one where Kivy is installed globally by root, but a non-privileged user attempts to run the tests.
Perhaps we can rely on a tmpdir instead?

Try again after merging #5368 please. That PR contains a change that disables anything related to creating files or html or whatever other file-only output by default.

I haven't actually tried again after merging, but a quick visual scan of the code would seem to indicate that the mentioned pull request is not a fix. In particular, AFAIU, the creation of the directory will still be attempted because it's part of the general "run" mechanism, even when no files are actually written to that that directory:
https://github.com/kivy/kivy/blob/6bd932908ee6fe9024bba0741c4c4ddba67a20c2/kivy/tests/common.py#L48


Android Phone looses internet connectivity when using scrcpy on Ubuntu

When I connect my phone on ubuntu, it looses the internet connection. The phone is still connected to the wifi network, but it is no longer able to connect to the internet. This happens as soon as I connect the USB cable, and it's fixed as soon as I unplug it. It only happens if scrcpy is running.
Also, this problem didn't occur when I used scrcpy on Windows, only when using it on Ubuntu. I built scrcpy using the instructions provided on the build guide.
Phone: Samsung Galaxy J3 (2016)
Phone OS: Android 5.1.1
Laptop OS1: Windows 10
Laptop OS2: Ubuntu 18.04.1 LTS

Temporary solution use scrcpy via wifi using "adb connect "

When I connect my phone on ubuntu, it looses the internet connection.

Wifi or ethernet? Over USB?

When I connect my phone on ubuntu, it looses the internet connection.

Wifi or ethernet? Over USB?

When I connect the phone through a USB cable, the phone looses its internet connection (wifi), even though it still remains connected to the wifi network.

This is happening to me on macOS. My device is a OPT3 running Android 9.0.

Does it still happen?


Fabric 2.x chaincode lifecycle update

Changelog

Updated version changes and chaincode lifecycle for fabric 2.x
Added new chart for chaincode approve
Updated Fabric Binaries

Reviewed by
@lakshyakumar @jagpreetsinghsasan
Linked issue
#966 #963

Creating a new pr for this issue as some checks were not signed


Preserve and use the user locale

This issue is imported from pivotal - Originaly created at Oct 23, 2019 by Michiel Kodde
Story
As a user, I want to keep my locale preference so that I can verify my identity in my own locale
Description
See other GSSP implementations
Tasks
Cover this in functional tests if possible.
Estimate
4-6h

Doesn't this come right from the identity? (bstrooband - Oct 24, 2019)

A GSSP cannot access the identity (it can't talk to the MW). A GSSP uses a stepup specific locale cookie set by the gateway.
All GSSPs need this, so it makes sense to share the solution. How is this currently handled in the Tiqr and WebAuthn GSSPs? (Pieter van der Meulen - Nov 13, 2019)

I thought this story was needed in order to send a locale to ADFS but that doesn't seem necessary.
There is indeed logic related to locales in the stepup-bundle and in webauthn, so indeed it seems a shared solution could be used.
Thanks for the heads up! (bstrooband - Nov 13, 2019)

This indeed is already implemented in the GSSP as we are using the example project.
What I still did was to add test coverage regarding this feature. (Michiel Kodde - Dec 19, 2019)


object storage: load private key: failed to parse PEM block containing the key

What happened:
Excute the following script:
edis-cli flushall
mc rb myminio/test-bucket --force
set -e
./juicefs-0.17.1 format redis://localhost/1 test-volume --block-size 4741 --compress lz4 --shards 1 --storage minio --capacity 379 --inodes 300411705 --encrypt-rsa-key my-priv-key.pem --bucket http://localhost:9000/test-bucket --access-key minioadmin --secret-key minioadmin --debug
./juicefs-1.1.0-dev config redis://localhost/1 --trash-days 3484 --capacity 168 --inodes 1048752 --min-client-version 1.0.0-rc1 --max-client-version 1.2.0 --bucket http://localhost:9000/test-bucket2 --access-key juicedata --secret-key 12345678 --encrypt-secret --force --debug
./juicefs-1.1.0-dev config redis://localhost/1 --bucket http://localhost:9000/test-bucket --debug
./juicefs-0.17.1 fsck redis://localhost/1 --debug

will get the following output:
chengdeMacBook-Pro:scripts chengzhou$ ./test6.sh
OK
Removed `myminio/test-bucket` successfully.
2022/09/10 16:56:18.698330 juicefs[80328] <INFO>: Meta address: redis://localhost/1
2022/09/10 16:56:18.702274 juicefs[80328] <WARNING>: AOF is not enabled, you may lose data if Redis is not shutdown properly.
2022/09/10 16:56:18.702407 juicefs[80328] <INFO>: Ping redis: 97.13µs
2022/09/10 16:56:18.702974 juicefs[80328] <DEBUG>: Creating minio storage at endpoint http://localhost:9000/test-bucket
2022/09/10 16:56:18.703329 juicefs[80328] <INFO>: Data use minio://localhost:9000/test-bucket/test-volume/(encrypted)
2022/09/10 16:56:18.844519 juicefs[80328] <INFO>: Volume is formatted as {Name:test-volume UUID:a420b588-95a6-42d1-8ed4-b1edbb054fba Storage:minio Bucket:http://localhost:9000/test-bucket AccessKey:minioadmin SecretKey:removed BlockSize:4096 Compression:lz4 Shards:1 Partitions:0 Capacity:406948151296 Inodes:300411705 EncryptKey:removed}
2022/09/10 16:56:19.036577 juicefs[80329] <INFO>: Meta address: redis://localhost/1 [interface.go:402]
2022/09/10 16:56:19.043646 juicefs[80329] <WARNING>: AOF is not enabled, you may lose data if Redis is not shutdown properly. [info.go:83]
2022/09/10 16:56:19.044118 juicefs[80329] <INFO>: Ping redis: 74.035µs [redis.go:2878]
access-key: minioadmin -> juicedata
    bucket: http://localhost:9000/test-bucket -> http://localhost:9000/test-bucket2
  capacity: 379 GiB -> 168 GiB
    inodes: 300411705 -> 1048752
max-client-version:  -> 1.2.0
min-client-version:  -> 1.0.0-rc1
secret-key: updated
trash-days: 0 -> 3484
2022/09/10 16:56:19.120040 juicefs[80333] <INFO>: Meta address: redis://localhost/1 [interface.go:402]
2022/09/10 16:56:19.126608 juicefs[80333] <WARNING>: AOF is not enabled, you may lose data if Redis is not shutdown properly. [info.go:83]
2022/09/10 16:56:19.126832 juicefs[80333] <INFO>: Ping redis: 143.326µs [redis.go:2878]
2022/09/10 16:56:19.127139 juicefs[80333] <DEBUG>: Creating minio storage at endpoint http://localhost:9000/test-bucket [object_storage.go:154]
    bucket: http://localhost:9000/test-bucket2 -> http://localhost:9000/test-bucket
2022/09/10 16:56:19.264499 juicefs[80337] <INFO>: Meta address: redis://localhost/1
2022/09/10 16:56:19.268426 juicefs[80337] <WARNING>: AOF is not enabled, you may lose data if Redis is not shutdown properly.
2022/09/10 16:56:19.268589 juicefs[80337] <INFO>: Ping redis: 125.722µs
2022/09/10 16:56:19.268857 juicefs[80337] <DEBUG>: Creating minio storage at endpoint http://localhost:9000/test-bucket
2022/09/10 16:56:19.269243 juicefs[80337] <FATAL>: object storage: load private key: failed to parse PEM block containing the key
chengdeMacBook-Pro:scripts chengzhou$ ./juicefs-1.1.0-dev version
juicefs version 1.1.0-dev+2022-09-09.575a46ab

What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?
Environment:

JuiceFS version (use juicefs --version) or Hadoop Java SDK version:
Cloud provider or hardware configuration running JuiceFS:
OS (e.g cat /etc/os-release):
Kernel (e.g. uname -a):
Object storage (cloud provider and region, or self maintained):
Metadata engine info (version, cloud provider managed or self maintained):
Network connectivity (JuiceFS to metadata engine, JuiceFS to object storage):
Others:

The encrypt-rsa-key is encrypted, which is not supported in juicefs-0.17.1.
Use juicefs-1.1.0-dev fsck should be fine.


Interested in pseudo code of decoder

Great work you have done here, I wanted to see how you handled the distance computation for the two vertexes connected to the same edge (whether you computed distance for one edge or on both edge) but the paper didn't emphasize a lot on the implementation of the decoder, code looks rather complicated and wonder if there is some decoder pseudocode to look at?

Great work you have done here, I wanted to see how you handled the distance computation for the two vertexes connected to the same edge (whether you computed distance for one edge or on both edge) but the paper didn't emphasize a lot on the implementation of the decoder, code looks rather complicated and wonder if there is some decoder pseudocode to look at?

For your first half of the question, the answer is that we only compute the distance for one edge. In this case, even when one edge is missing, we can still connect the two vertices.
Indeed, the implementation of the decoder is complicated. I will write down the pseudocode and some detailed explanations and post them by the end of this week.

for step1(b) it feels more like it is using either one of  a-->b or b<--c to find b but not both as the values get overrided here https://github.com/songtaohe/Sat2Graph/blob/7579cfcaf173db3f3c94ceb0b2f8d40878a2a204/model/decoder.py#L546
thanks for all the explanations! especially on step 2

for step1(b) it feels more like it is using either one of a-->b or b<--c to find b but not both as the values get overrided here
https://github.com/songtaohe/Sat2Graph/blob/7579cfcaf173db3f3c94ceb0b2f8d40878a2a204/model/decoder.py#L546
thanks for all the explanations! especially on step 2

Yeah, you are right. In step1(b), I should write 'In this case, we use the edges a-->b OR b<--c to recover b'.


[UI: Pages] Create landing page for searching / filtering packs

Summary
Add a page that provides interactive view of all o11y packs. This likely entails creating several components for searching/filtering data sourced via the fake API data.
The view should:

be searchable by pack name
be sortable by: number of installs (aka, popularity), name, rating
be filterable by: category (ex., visualizations, alerts, dashboards, etc), tag(?)
provide layout options for:

grid view: img thumbnail, name, description, rating, category, no. of installs
list view: name, rating, no. installs

A file in src/pages likely makes most sense.
Components
Components we'll likely need for this:

searching JSON (new)
search input (theme)
form controls (maybe theme, maybe new)
grid / list views (new)
icons (shadow theme icon w/feather)
cards (surface from theme)

Acceptance criteria

[ ] As a user I can quickly find a pack by name
[ ] As a user I can quickly see a list of packs by main category (ex, dashboards, visualizations, alerts, etc)
[ ] As a user I can quickly see the highest rated / most installed packs for a given main category
[ ] URL uses observability-pack-library somewhere in it
[ ] Page elements are responsive on smaller screens

Helpful links

Sites with similar elements/interactivity:
Opensource: Explore projects page
opensource uses js-search to search its JSON
docs: attribute-dictionary.js
Similar components:

for pack cards: Opensource project cards / featured projects

Screenshots
Mock

Let's split this up:

Mobile layout: 5pt
Grid and list view: 5pt (can be de-prioritized if needed)
Filtering, sorting, searching could all be separate tickets: 8pt


cigien: Watch votrecollierphoto.fr

cigien requests the watch of the watch_keyword votrecollierphoto\.fr. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

votrecollierphoto\.fr has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Spevacus in Charcoal HQ


[docs-infra][PoC] Move API pages to TS

This PR is more a proof of concept. Each aspect could be divided in different PR to simplify the review. And For now this is not backward compatible.
Here are the different modifications
Typing PropsSection
This section is the most used, since it renders:

component props
hooks parameters
hooks returned values
MUI X interfaces

but was still in JS with poor Proptypes mostly because the typing was a bit complex.
I move it to TS thanks to the second point
Having a typing contract with @mui-internals/api-docs-builder
The API pages display the data from autogenerated JSON files. However, we have no relation between the components props and other scripts generating those JSON files.
When we did the migration of the script and the reorganization of API pages, we got some trouble due to forgotten edge cases.
In this PR:

the translations and metadata formats types are defined in packages/api-docs-builder/types/ApiBuilder.types.ts (for example ComponentApiContent for component metadata)
the defined type is enforced in the script before saving the JSON with for exampleconst pageContent: ComponentApiContent = { ... }
await writePrettifiedFile(pageContent, 'filename.json')

the typing is reused to type docs components

This makes the docs dependent on @mui-internals/api-docs-builder
Make API Sections more independent from scripts results
For now, the API Sections relied on the JSON file structure. It expected to get the component metadata, the translation, and the component name. Then all the formatting was done inside the section.
In this PR, I define the props typing of the sections as a definition of what will be rendered. And add helpers that map JSON file content to the expected props.
 <PropertiesSection
-    properties={parameters}
-    propertiesDescriptions={parametersDescriptions}
-    componentName={hookName}
-    hooksParameters
+    properties={hookApiProcessor({ // Or propsApiProcessor, or interfaceApiProcessor depending on the section to display.
+      kind: 'parameters',
+      hookName,
+      properties: parameters,
+      translations: parametersDescriptions,
+    })}
    level="h3"
    title="api-docs.parameters"
    titleHash={`${hookNameKebabCase}-parameters`}
/>

Having a typing contract

top-notch. I think the strategy makes a lot of sense. add types => refactor => extract. Similar approach can be done between the pages and the output of the markdown generator.

Make API Sections more independent from scripts results

I'd love for those {{...}} interpolations to some day be moved to MDX. In that sense, it would be helpful if we can alredy make them look more like rendering a component. Not necessarily in terms of JSX syntax, but in terms of how properties are defined
{{"component": "./SomeComponent", "prop1": "foo", "prop2": 123}}

Is spiritually equivalent to

import SomeComponent from "./SomeComponent"

// ...

<SomeComponent prop1='foo' prop2={123} />

I'd love for those {{...}} interpolations to some day be moved to MDX. In that sense, it would be helpful if we can already make them look more like rendering a component. Not necessarily in terms of JSX syntax, but in terms of how properties are defined

@Janpot Not sure to understand your point on this one.
The API pages are not markdown rendered

The API pages are not markdown rendered

Ah yes ofcourse.
Long term we could perhaps think about making the constituents composable in markdown pages? e.g. due to complexity in the types we're at the moment writing some tables by hand in Toolpad that look a lot like these property tables.


[BUG] Error while importing ConnectKitButton

Describe the bug
Error while importing ConnectKitButton.
When i import ConnectKitButton in react with import { ConnectKitButton } from 'connectkit';
I get the following error.
`Failed to compile.
./node_modules/framer-motion/dist/es/components/AnimatePresence/index.mjs
Can't import the named export 'Children' from non EcmaScript module (only default export is available)
`
To reproduce
im getting the error with both v0.0.1 and 0.0.2 of connectkit
"react": "^18.0.1",
"wagmi": "^0.6.7",
Expected behavior
No error when things are imported
Screenshots
If applicable, add screenshots to help explain your problem.
Environment details
MacOS, firefox
If applicable, let us know which OS, browser, browser version etc you're using.
Additional context
Add any other context about the problem here.

Hey @vinayakathavale,
It looks like some build environments (like create-react-app) might have some trouble mixing ES modules (framer-motion) and CJS modules.
If your tsconfig.json file is using "target": "es5" a quick fix that might work is to update to "target": "es6", but ymmv.
Thanks for raising our attention on this, we'll look into a fix so this doesn't occur in future releases and will keep this issue open until we have a built-in fix for this.

Hey @vinayakathavale, just following up on this. Did the above resolve your issue?

This issue is temporarily closed due to lack of information. Please provide a minimal reproducible example and reopen this issue.

hi @lochie
I'm havign same issue ( using "connectkit": "^1.0.0", ). I've tried also to add "target": "es6" but with no success

If this can be of any help, I've solved by upgrading to "react-scripts": "5.0.1", (previously was 4.x.x)


V3: Improving styling to match Home Assistant

With the addition of packaged workspace building of multiple versions (#53) as a prerequisite for revising the ESPHome device pages to look more like Home Assistant (#49), this pull request is rebase of that work to a new v3 version.

The HA styling revision that was previously a modification of v2 has been forked over to a new v3 package
The original v2 has been restored to its former state that is out in the world currently
Removed the vfallback work for now and did some small clean up and verification/adjustment for deployment

Take v3 out for a spin:
web_server:
  port: 80
  js_url: https://deploy-preview-54--esphome-webserver.netlify.app/v3/www.js

This pull request supersedes the original pull request #49:

This PR is a styling upgrade to match the styling of HomeAssistant entities card.

icons using the standard HA iconset via on demand and thus with a graceful degradation (no icon shown if WAN is down)
group by entity_categories
instead of table use div and grid/flex layouts
added uptime based on ping value
color picker for rgb lights
Tag column hidden on web view
update icon to use the

Icons and entity_categories functionally needs matching PR in esphome/web_server component - though the two still work in the previous way without the other.
Not sure about coding standards, or formatting in this repo. Please comment and help me with a pointer if styling changes are needed.
Related discord discussion - https://discord.com/channels/429907082951524364/1177062706340171807

Closes #49

From which version will it be available as v3 in an esphome release?


Fix typo in docs

This PR fixes a minor grammatical error and a minor typo in the docs in src/lib.rs the diff is tiny and should be easy to check for correctness.

purpose -> purposes
then -> them

Coverage increased (+0.5%) to 86.786% when pulling 9f3e532c803174cf136ef0b3b2f90bf29ee1ede3 on JoshOrndorff:joshy-doc-fix into 851706460a9311f7bbae8e9b7ee497c7188df0a3 on Geal:master.

thanks


Can't set multiple PATH entries in the same configuration

Due to the way the xEnvironment and Environment DSC Resources are implemented, it seems to be impossible to set multiple PATH entries within the same configuration. Because the Name field must always equal Path, it's impossible to set two PATH entries. That seems like a really common task that people would want to accomplish within the same configuration.
Perhaps when Path = $true, the Name field should be ignored for the purposes of determining which environment variable is being set, since Path = $true already provides that information.
Or perhaps the PATH environment variable functionality should be in a completely separate resource.
Here's an example of an attempt to set two PATH entries, but this will not work:
Configuration Example
{
    Import-DscResource -ModuleName xPSDesiredStateConfiguration # or PSDesiredStateConfiguration
    Environment Example1
    {
        Name   = "Path"
        Ensure = "Present"
        Path   = $true
        Value  = "C:\test123"
    }
    Environment Example2
    {
        Name   = "Path"
        Ensure = "Present"
        Path   = $true
        Value  = "C:\test456"
    }
}

Similar issue on PSDesiredStateConfiguration

The resource is built to handle your scenario like this.
If either path in Value exist already it will not be added twice.
    Environment AddTwoPaths
    {
        Name   = "Path"
        Ensure = "Present"
        Path   = $true
        Value  = "C:\test123;C:\test456"
    }

To remove multiple paths.
    Environment RemoveTwoPaths
    {
        Name   = "Path"
        Ensure = "Absent"
        Path   = $true
        Value  = "C:\test123;C:\test456"
    }

I label this issue as documentation and help wanted so that an example can be created and documentation updated for this.

What’s so bad about the way this is implemented is that it completely lacks any ability to assign path values in more than one partial configuration, and then apply multiple partial configurations to targets.
Two partial configurations that will be making changes to path values can’t be used together, even if their path values are completely unrelated to each other.
It’s a resolvable problem, unfortunately I can’t release my custom resource as it’s enterprise code, but it took me less than a day to write. It’s somewhat similar to this resource, although that one has some issues that made me decide to use my own.
I don’t think this is a documentation issue. I still think it’s a design flaw that can be fixed relatively quickly if there’s a will to do so. The only reason I can think to not change the design would be that careless users could accidentally set paths that cancel each other out (setting the same path entry twice to be both absent and present, for example). For my team we accepted that risk in the assumption that we can use our heads and not do that.

I opened issue #415 for my previous comment.
I'm seeing the potential to having a new resource to handle that scenario. I have relabel this as 'resource proposal' so that someone in the community can propose a schema.mof for such a resource.
The Ensure parameter might be able to of type qualifier Key to mitigate so that a configuration can't both remove and add.

I realize now that I didn’t mention the problems encountered with partial configurations when I originally opened this issue, so really I ended up talking about two separate issues. My apologies, thanks for opening the separate issue for the docs.


Terraform 0.11.13 image is wrong

docker run --entrypoint "/bin/terraform" jmccann/drone-terraform:5.2-0.11.13 --version

would output:
Terraform v0.11.11

Your version of Terraform is out of date! The latest version
is 0.11.13. You can update by downloading from www.terraform.io/downloads.html

Checking into this

@carlosbaraza I believe this should be better now.  Please verify and re-open if not.  Thanks for bringing it to my attention!

@jmccann it works! Thank you for the prompt fix!


Error running command sfdx.force.source.retrieve.component: data.forEach is not a function

I'm receiving the following message when trying to retrieve all metadata (Apex Classes) on my project...
Error running command sfdx.force.source.retrieve.component: data.forEach is not a function. This is likely caused by the extension that contributes sfdx.force.source.retrieve.component.
I have uninstalled and reinstalled everything (Visual Code Studio, Salesforce CLI, Salesforce Extensions for VCS, etc).
I can't find the cause and haven't been able to identify any possible solution or debug path in any of the usual places (i.e. SF Dev guidance documents, github, salesforce stackexchange).
I did find a recent reference to the same issue here: https://salesforce.stackexchange.com/questions/323687/error-running-command-sfdx-force-source-retrieve-component-data-foreach-is-not
Any insight or help would greatly be appreciated.
Thanks
Visual Code Studio
Version: 1.50.1 (user setup)
Commit: d2e414d9e4239a252d1ab117bd7067f125afd80a
Date: 2020-10-13T15:06:15.712Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19041
SFDX Plugins
@oclif/plugin-autocomplete 0.2.0
salesforcedx 50.1.1
├─ templates 50.1.0
├─ @salesforce/sfdx-plugin-lwc-test 0.1.7
├─ apex 0.1.1
├─ salesforce-alm 50.1.1
└─ custom-metadata 1.0.10

Can you please:

copy/paste the output of sfdx plugins --core
state the exact command you're running with all parameters.
run the command appending --dev-debug and copy/paste the stack trace of the error

@oclif/plugin-autocomplete 0.2.0
@oclif/plugin-commands 1.3.0 (core)
@oclif/plugin-help 3.2.0 (core)
@oclif/plugin-not-found 1.2.4 (core)
@oclif/plugin-plugins 1.9.1 (core)
@oclif/plugin-update 1.3.10 (core)
@oclif/plugin-warn-if-update-available 1.7.0 (core)
@oclif/plugin-which 1.0.3 (core)
@salesforce/analytics 0.22.0
@salesforce/sfdx-trust 3.4.3 (core)
alias 1.1.2 (core)
analytics 1.12.1 (core)
config 1.1.9 (core)
generator 1.1.3 (core)
salesforcedx 50.1.1
├─ templates 50.1.0
├─ salesforce-alm 50.1.1
├─ @salesforce/sfdx-plugin-lwc-test 0.1.7
├─ apex 0.1.1
└─ custom-metadata 1.0.10
sfdx-cli 7.76.1 (core)
I'm using Org Browser via the SF Extension pack and the left hand menu item by selecting the pull icon (Retrieve Source from Org).  https://developer.salesforce.com/tools/vscode/en/user-guide/org-browser/

I haven't figured out how to run a debug log on this specific embedded command (despite attempting).

[2020-10-19 20:57:58.415] [renderer1] [warning] UNRESPONSIVE extension host, 'salesforce.salesforcedx-vscode-core' took 92% of 5610.658ms, saved PROFILE here: 'c:\Users\timma\AppData\Local\Temp\exthost-bfad10.cpuprofile' [{"id":"gc","total":17489,"percentage":0},{"id":"program","total":78,"percentage":0},{"id":"salesforce.salesforcedx-vscode-core","total":5146921,"percentage":92},{"id":"salesforce.salesforcedx-vscode-lightning","total":441766,"percentage":8},{"id":"self","total":4199,"percentage":0}]
[2020-10-19 20:58:07.331] [renderer1] [error] Unable to find sandbox configuration (dw.{json,js})
[2020-10-19 20:58:07.412] [renderer1] [warning] UNRESPONSIVE extension host, 'salesforce.salesforcedx-vscode-lwc' took 87% of 2482.11ms, saved PROFILE here: 'c:\Users\timma\AppData\Local\Temp\exthost-f6ac2e.cpuprofile' [{"id":"program","total":1151,"percentage":0},{"id":"salesforce.salesforcedx-vscode-core","total":273,"percentage":0},{"id":"salesforce.salesforcedx-vscode-lwc","total":2149570,"percentage":87},{"id":"salesforce.salesforcedx-vscode-visualforce","total":310251,"percentage":12},{"id":"self","total":11709,"percentage":0},{"id":"vscode.git","total":8951,"percentage":0}]
[2020-10-19 20:58:09.280] [renderer1] [error] Unable to find sandbox configuration (dw.{json,js})
[2020-10-19 21:04:26.657] [renderer1] [error] Unable to find sandbox configuration (dw.{json,js})

Hey guys. I have the same issue here when I want to retrieve all of the components of a given type (for ex. all triggers, all aura components..). But when retrieving one by one there is no problem. Maybe this data.forEach function is not supported.

I am also seeing this issue when going to the org browser and retrieving all components for a type

The fix for this is going out tomorrow on release v50.2.0 of the Salesforce extensions for VSCode.
Thanks for opening this issue, I'm closing it as a duplicate of issue https://github.com/forcedotcom/salesforcedx-vscode/issues/2634

Thanks!

Was the 50.2.0 release pushed out automatically?

When will this be released? Really need this fix.

This week's release was delayed a bit because of some QA tasks. We released it earlier today to the VSCode marketplace under version 50.2.0 of the Salesforce extensions for VSCode.

Thanks! Things are running smoothly again.

@lcampos Started receiving a similar error last week.  More context here
Error running command sfdx.force.source.retrieve.component: undefined. This is likely caused by the extension that contributes sfdx.force.source.retrieve.component.


Fixes Postgres Restore Bug

Fixes  a bug where a Postgres dump file with a line longer than 64K could not be read by the scanner in the Postgres restore plugin.
The plugin now returns non-0 codes on errors related to reading the file in.
Fixed an off-by-one error in the debug logs when it says how many lines were in the dump file that was restored.

Carry on


Add Belgium holidays

Add Belgium holidays

Coverage increased (+0.01%) to 98.992% when pulling a4e7056114b883648e1b3507fa9e1c37332a48ac on fb22:patch-2 into 70c819a06ee1cfec54ebec98592d22406c872c2a on ryanss:master.

Coverage increased (+0.01%) to 98.992% when pulling a4e7056114b883648e1b3507fa9e1c37332a48ac on fb22:patch-2 into 70c819a06ee1cfec54ebec98592d22406c872c2a on ryanss:master.


Spawn tasks for peers in the sync manager

Nice work!
I think as a next step we can add a pair of bounded channels between the peer loop in the backend and the peer loop in the sync manager (separate for each connected peer) and start sending sync messages directly.
The peers won't be able to push too many messages and overload sync manager, and the sync manager won't be able to push too many messages before they are sent over the network.
We will need to think about potential deadlocks with this design, but this should probably solve most of our problems with unbounded channels in p2p.


fix: order history does not display order content

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Awesome work, cant wait for more! ;)


Add VersionStamp to CoreFX and core-setup builds.

This will make produced versions only use "-rc1" suffixes instead of "-rc1-buildnumber", which matches up with the official RC1 release.

@dotnet-bot test this please

Does this mean you have to run this sequence of commands to get a build?
./build.sh /p:ArchiveDownloadedPackages=true /p:VersionStamp=rc1
./build-source-tarball.sh ../tarball --skip-build
cd ../tarball
./build.sh /p:VersionStamp=rc1

(Calling build separately from build-source-tarball because there's no way to pass in params to the inner build command.)
I'm not a fan of how complicated this got without defaults.

Yes, that's correct.  I can add a default for this.

Yeah I just commented in the other PR as well I'm fine with having defaults as properties that could be overridden.


[camera] Make it possible to simultaneously access to front and rear cameras.

I want to access both front and rear cameras at the same time and use both previews on the same view to take a picture or record a video like BeReal App.

Hi @ykaito21, I see a similar issue requesting this feature in #51928.
Kindly follow up there for updates.
Closing from here as duplicate.
Thank you


fix(types): make parameters non-nullable for Playwright options

Description

Currently, when selecting Playwright as the provider, type completion for the options parameter of the click method from @vitest/browser/context's userEvent is not working. This is because when fetching the types for Playwright's options, the possibility of undefined is not eliminated, resulting in a missing interface type. Therefore, I have wrapped it with NonNullable to remove the potential for undefined, which fixes the issue so that type completion now works.

before

after

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
[ ] Ideally, include a test that fails without this PR but passes with it.
[x] Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

[x] Run the tests with pnpm test:ci.

Documentation

[ ] If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

[x] Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

@hi-ogawa Thank you for your reply!
I have a question: what are the settings of the tsconfig.json you added? I suspect that the noUncheckedIndexedAccess option might be the cause.

Oh, that's a good point. I didn't even have strict: true :sweat_smile:  After adding that I get the error like screenshot1.
I'm adding dts test in https://github.com/vitest-dev/vitest/pull/6995 with skipLibCheck: false and that shows an error too now. We'll merge your PR first. Thanks for the contribution!


Built-in debugger malfunctions when url parameters are present

When using flask, with debug enabled, and attempting to debug a page with any URL parameter present, the debugger will malfunction and throw the error: "Error: Could not verify PIN.  Network error?" it also does not print the debugger pin into the console, unless upon startup
To replicate this, make a simple Flask test app that throws an error like so:
from flask import Flask

app = Flask(__name__)
@app.route("/")
def hello_world():
    raise
    return "
Hello, World!
"

if __name__ == "__main__":

Now, navigate to localhost:5000. After which the debug terminal will appear and work as intended. This is what appears in the console:
<IP_ADDRESS> - - [26/Jun/2024 12:37:39] "GET /?__debugger__=yes&cmd=resource&f=debugger.js HTTP/1.1" 304 -
<IP_ADDRESS> - - [26/Jun/2024 12:37:39] "GET /?__debugger__=yes&cmd=resource&f=style.css HTTP/1.1" 304 -
<IP_ADDRESS> - - [26/Jun/2024 12:37:39] "GET /?__debugger__=yes&cmd=resource&f=console.png HTTP/1.1" 304 -
 * To enable the debugger you need to enter the security pin:
 * Debugger pin code: xxx-xxx-xxx
<IP_ADDRESS> - - [26/Jun/2024 12:37:41] "GET /?__debugger__=yes&cmd=printpin&s=3WfWFdnDEWFY1zvWLTW3 HTTP/1.1" 200 -

Do not insert the debugger pin, instead navigate to localhost:5000?test=test (any url parameter will cause this). The debug console will appear, upon clicking the terminal button, to cause the PIN prompt, the prompt will appear; however, the error will appear a second time in the terminal, and no PIN will appear.
<IP_ADDRESS> - - [26/Jun/2024 12:40:42] "GET /?__debugger__=yes&cmd=resource&f=style.css HTTP/1.1" 304 -
<IP_ADDRESS> - - [26/Jun/2024 12:40:42] "GET /?__debugger__=yes&cmd=resource&f=debugger.js HTTP/1.1" 304 -
<IP_ADDRESS> - - [26/Jun/2024 12:40:42] "GET /?__debugger__=yes&cmd=resource&f=console.png HTTP/1.1" 304 -
<IP_ADDRESS> - - [26/Jun/2024 12:40:51] "GET /?test=test?__debugger__=yes&cmd=printpin&s=LjqOQxjdwXsrbGPWHvJB HTTP/1.1" 500 -
Traceback (most recent call last):
...

Naturally, the debugger ping should exist anyway. I think the issue is that ?__debugger__... is inserted instead of &__debugger__... in circumstances where URL parameters are already present. I cannot verify as I'm not certain where this should live. It's possible this is a Werkzeug problem. Feel free to tell me, and I'll reopen over there.
Environment:

Python version: 3.11
Flask version: 3.0.3
FWIW this still happened in 2.3.3

I am running into this with the same situation, trying to debug an application where there's already parameters in the query string.

Happy to review a PR. Presumably it's an issue in the JavaScript where it's constructing the URLs.