xRoute backend update guarantees

It would be good to discuss what guarantees implementors can provide during an update of an xRoute. Specifically in Knative we've seen ingresses drop traffic when transitioning from one backend to another - even when both backends have healthy endpoints.
The situations I've seen this occur is when
1. Ingress doesn't track backend endpoints that aren't reachable via routes
You have two healthy backends A & B
When a route is updated from pointing to backend A to backend B the proxy has to page in backend B's endpoints. This unfortunately races against the route config being rolled out. Ingress drops traffic because endpoints aren't present and the route isn't pointing to backend A anymore.
2. Newly deployed healthy backends aren't safe for Routes reference
Even if an ingress solution tracks all endpoints there's a small window where traffic can be dropped when switching to a newly deployed backend C.
In Knative we have a test were we continuously probe a HTTPRoute while performing the following steps

Spin up a deployment and service
Wait for a healthy endpoint to appear (by polling the API server)
Update an HTTPRoute to point to the new backend.
Repeat 1-3 about 10x

The race here is the test observes and updates the HTTPRoute's backend faster than the ingress proxy can process/track the new endpoint.

Just to point out, while Knative is using and testing this functionality more aggressively than most implementations, every user of the Gateway API (including tools like https://flagger.app/) will be trying to perform these operations:
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: http-filter-1
spec:
  hostnames:
    - my.site.com
  rules:
      backendRefs:
        - name: my-app-blue
          port: 80

add a second backend:
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: http-filter-1
spec:
  hostnames:
    - my.site.com
  rules:
      backendRefs:
        - name: my-app-green
          port: 80

I think (1) is valid, but (2) is not, IMO. This actually doesn't even work in Kubernetes core with just basic Service routing. The Endpoint being generated is the signal to kube-proxy to start serving it; just because its there doesn't mean its immediately available to consumers.
If your client detects the endpoint and sends traffic to the Service faster than kube-proxy is programmed you will see dropped traffic.

(1) should be enforced without any status - changes to a route should be zero downtime or routes are effectively immutable, IMO.

I believe the update test in https://github.com/knative-sandbox/net-gateway-api/tree/main#getting-started should work for that.  Knative currently only tests Istio and Contour (and has some gaps for each!), but the code in question for the update test lives here:
https://github.com/knative/networking/blob/main/test/conformance/ingress/update.go
And yes, I'm especially concerned about failure mode 1 (as described in my earlier comment), because the only "workaround" is to shift load via DNS to a different cluster prior to making routing changes, which isn't really scalable.
For (2), does it seem reasonable to block the data-plane routing updates until the Service backends are resolved in the gateway api control plane?  This would be more complex, as the control plane would need to define the new backend endpoints and wait for the data plane to complete a health check before updating the routing to point to the new backend.
For newly-created routes, a Ready condition is helpful, but when we're talking about updating existing HTTPRoutes we need to smoothly transition from one valid state to a new valid state without going through a "drop some traffic" state.

For (2), does it seem reasonable to block the data-plane routing updates until the Service backends are resolved in the gateway api control plane? This would be more complex, as the control plane would need to define the new backend endpoints and wait for the data plane to complete a health check before updating the routing to point to the new backend.

In a vacuum, sort of. I think its hard to do, or at least it would be in Istio which is what i am familiar with, and at least harder than it sounds.
We don't want to block all updates, just to that specific route. So that means either the control or data plane needs to keep both copies. We also need to know when we are in the state of "waiting for backend", because we don't want to wait forever i'd imagine (or do we? even on a new route, do not apply it until all backends are healthy?). So we need to be fairly stateful. This is plausible, but may not robust - we aren't (realistically) going to become truly stateful, so if the control plane restarts during this operation we may suddenly flip to the unhealthy backend; perhaps thats an edge case we can live with.
To handle it, we also need a mechanism to know "is the backend ready" which is more robust than the k8s state and actually is based on the underlying data plane. That is possible to determine in general with Envoy, but becomes tricky in practice. Do we need all instances of the data plane to be ready, or only some of them? We may also have multiple control plane replicas, so now we need to share this state between control plane instances. What if we are a multi-cluster mesh, do we need all control planes to share with all other control planes and ensure 100% of all data plane instances across the globe have the change before we shift? Can a single envoy instances being down (in the global view) block all updates?

/assign @arkodg

@dprotaso would a conformance test for 1) be a good next step ?

/remove-lifecycle stale

/lifecycle frozen

Ive raised https://github.com/kubernetes-sigs/gateway-api/issues/2303 to solve 1. which imo is a test, implementations should strive to achieve.

boils down to - what information should someone rely on to ensure that that the network policy has been programmed into the data plane to ensure there are no traffic drops

we can't rely on querying the Kube API server, because at this point we cannot guarantee if the implementation has received and programmed this into the data plane
we can't rely on the Programmed status condition in the HTTPRoute because we cannot guarantee if the
route has been actually programmed in the data plane.
a new status condition such as Ready implemented by the controller, could be used in theory to guarantee that the routes in the data plane are ready, but this is a hard problem to solve for most implementations.

Instead of focusing of what information is needed by a client before starting to send requests, to guarantee no traffic drops, we can instead come up with a max duration within which a controller should program routes.
here is the example steps provided in the original description
1.Spin up a deployment and service
2.Wait for a healthy endpoint to appear (by polling the API server)
3.Update an HTTPRoute to point to the new backend.
4.Repeat 1-3 about 10x
A conformance test can be written to ensure that the tests waits for a duration of time between step 3. and 4. for some duration (lets say 1s), but expects no failures at step4.
hoping to hear from others reg this, at this point all conformance tests focus on correctness rather than performance, and this one would fail in under the performance bucket imo.

I'm pretty reluctant to add any performance-based conformance test before GA, I think that this one in particular is very easy to get wrong, both from the conformance and the implementation sides. I also don't know if we want to mandate zero-packet-loss backend changes - that seems like it could be a high bar for some implementations. Maybe when we do add performance-style testing, we extend the testing result YAML to include the numbers (packets lost in this case)?
Again, I don't think we can move on @arkodg's suggestion before GA, sadly, there's too many sharp edges.

Ive raised https://github.com/kubernetes-sigs/gateway-api/issues/2303 to solve 1. which imo is a test, implementations should strive to achieve.

boils down to - what information should someone rely on to ensure that that the network policy has been programmed into the data plane to ensure there are no traffic drops

we can't rely on querying the Kube API server, because at this point we cannot guarantee if the implementation has received and programmed this into the data plane
we can't rely on the Programmed status condition in the HTTPRoute because we cannot guarantee if the
route has been actually programmed in the data plane.
a new status condition such as Ready implemented by the controller, could be used in theory to guarantee that the routes in the data plane are ready, but this is a hard problem to solve for most implementations.

Instead of focusing of what information is needed by a client before starting to send requests, to guarantee no traffic drops, we can instead come up with a max duration within which a controller should program routes.
here is the example steps provided in the original description
1.Spin up a deployment and service
2.Wait for a healthy endpoint to appear (by polling the API server)
3.Update an HTTPRoute to point to the new backend.
4.Repeat 1-3 about 10x
A conformance test can be written to ensure that the tests waits for a duration of time between step 3. and 4. for some duration (lets say 1s), but expects no failures at step4.
hoping to hear from others reg this, at this point all conformance tests focus on correctness rather than performance, and this one would fail under the performance bucket imo.

Looking at the description here (and keeping in mind the distributed system and possible scale of gateway/mesh deployments), it feels like the most consumer-friendly way to represent this settling duration would be a status.stableAt date set by the controller (possibly along with a status.observedGeneration).
Obviously, the status here would not be a 100% guarantee that newly-started proxies would have all configuration before accepting traffic, but that feels like a different correctness problem.


Payment gateway availability based on customer

What I'm trying to achieve
I want to show customer personalized list of payment gateways that takes into account type of user and/or other metadata.
Describe a proposed solution
Gateways could (optionaly) implement additional method that validates user capability. We should filter availablePaymentGateways in checkout based on their response to customer validation.
Arguably, best way would be to pass dedicated private meta to gateway to avoid passing customer model around.

I'm suggesting using whole checkout when validating payment methods: in both of my previous projects I had to implement logic to block payment methods based on items in cart
Use case:
I would like to use Affirm payments only for physical products and block it when user has any digital product in cart.

Closing as payments are now handled by apps.


Add upgradesTo() method to PackageCollection

I ended up going with the generator approach instead of the view approach that we talked about the other day. It does make the generators more complicated; I'll point out where. I decided not to use the view because it seemed too heavyweight a change for a simple feature.

@jsancio @larioj updated with your suggestions!


Fix and test installation of Windows libraries

Appears that some libraries were missing from the Windows packages. So this tries to fix up the install scripts to copy them correctly. Also adds some tests to check that packages include them.

Checklist

[ ] Used a fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

If you are able to advise, @mingwandroid, that would be very helpful.

This can be closed now I believe cc @jakirkham

Indeed. Thanks @seanyen for solving this! 😄


chore(snackbars): add paparazzi tests

Changes description 🧑💻

Add paparazzi tests for Snackbars
Context 🤔

#94
Checklist ✅

[x] Make sure you are requesting to pull a topic/feature/bugfix branch. Please, don't request directly from your main!
[x] Check commits & PR names matches our requested structure. It must follow the https://www.conventionalcommits.org pattern.
[x] Check compose contract convention. It must follow conventions described here.
[x] Check your code additions will fail neither code linting checks.
[x] I have reviewed the submitted code.
[ ] I have tested on a phone device/emulator.
[ ] I have tested on a tablet device/emulator.
[ ] I have tested on a large screen device/emulator.
[ ] If it includes design changes, please ask for a review design-system-core-team-design GitHub team.

Screenshots 📸

Other info 👋

You can download the apk here :
sample-debug.apk :
https://app.bitrise.io/app/e9ae480151be4514/build/c0c14542-ba1b-4392-a97b-6bff0977beb9/artifact/b8bdbe6659ee23f7/p/33df77541aaf0f50d767572849226413

You can download the apk here :
sample-debug.apk :
https://app.bitrise.io/app/e9ae480151be4514/build/88b25c83-7d09-4e1c-85d1-32ce6ab1a748/artifact/40372c1759968e63/p/b30a3036ac968176c899f4bdd02c2a82

You can download the apk here :
sample-debug.apk :
https://app.bitrise.io/app/e9ae480151be4514/build/5890c65c-5aff-4f9f-865f-f5da04c37588/artifact/807a0a8500960a16/p/21db2dd3d2c4c565f6f75ab6fd6b7a4c


variable expansion

Does this dockerfile really work? According to docs and my test, the variable expansion at
CMD ["-b", "<IP_ADDRESS>", "-Dkeycloak.import=/opt/jboss/keycloak/${KEYCLOAK_IMPORT_REALM}"]
shouldnt work. ${KEYCLOAK_IMPORT_REALM} wont get resolved because of the array definition of CMD.

Yes, this does not work for me either. You do not have variable expansion in the CMD part, cf. https://stackoverflow.com/questions/33935807/how-to-define-a-variable-in-a-dockerfile and https://github.com/moby/moby/issues/5509.
Since I currently do not need to change the import, I use a hard-coded one. Maybe that will change later and I will write a solution for that here.

Sorry for the late reply.
I'm not sure if this image is still relevant.
In current projects I'm using the official keycloak docker image and I'm managing import/export via a mapped volume and by choosing the import/export command in the docker-compose.yml:
keycloak:
    image: jboss/keycloak:3.4.3.Final
    networks:
      test:
        aliases:
        - keycloak
    ports:
      - "8081:8081"
    environment:
      - KEYCLOAK_USER=administrator
      - KEYCLOAK_PASSWORD=test
      - POSTGRES_DATABASE=keycloak
      - POSTGRES_USER=keycloak
      - POSTGRES_PASSWORD=test
      - POSTGRES_PORT_5432_TCP_ADDR=keycloak-db
    depends_on:
      - keycloak-db
    #command: -b <IP_ADDRESS> -Djboss.http.port=8081 -Dkeycloak.migration.action=export -Dkeycloak.migration.provider=dir -Dkeycloak.migration.dir=/tmp/keycloak/test
    command: -b <IP_ADDRESS> -Djboss.http.port=8081 -Dkeycloak.migration.action=import -Dkeycloak.migration.provider=dir -Dkeycloak.migration.dir=/tmp/keycloak/test -Dkeycloak.migration.strategy=OVERWRITE_EXISTING
    volumes:
      - ./setup:/tmp/keycloak/test/

Let me know if this github project is still useful, so I will look into this issue.

you dont need to look into it as far as i am concerned. Thanks.

I am also fine with it. Thanks for the docker-compose.yml example.


How to access to Postgres root?

I would like to change some of the database variables.  How would one access the root level access to postgres?

The flynn user has superuser access. The easiest way to login as flynn is to run flynn -a postgres pg psql

That's easy :)  I thought I had hop through containers or something... I got what i needed to do.
Thanks.


181 create templates for GitHub issues

Add Issue Templates & Disable Custom Issues
I looked at our issues and categorized them into three distinct issue types: bug, enhancement (broadly defined), and new dataset. I have created templates for us to consider for each of these categories.
Changes Made

Added structured issue templates to streamline issue creation
Disabled custom issue submissions to ensure consistency
Configured issue template chooser settings

Why
This change will help standardize our issue tracking by:

Ensuring all necessary information is provided upfront
Reducing back-and-forth in issue comments
Making issues more searchable and categorizable
Maintaining consistent issue format across the project

Testing

I'm having a hard time testing these from a branch. I made a separate repo where you can test it: https://github.com/project-lux/issues-template-demo
This should not introduce breaking changes.

If we want to have blank issues accepted (might be nice for quick one-off notes), we can set the blank attribute in the config to true.


Zfh extension support

PR to add Zfh extension

{separately: I don't know why this is a 1300 line diff when there only about a dozen short differences]

...because of this change on the main branch.

this was clearly not resolved before riscof was deployed, and we are no longer using Makefile.include files
artifacts should not be in the repo, and we will be removing the entire riscv-test-stats directory from the repo, and putting them into a google docs folder ("for risc-v -members -> Workgroups  -> ACT Test Development Artifacts" or  https://drive.google.com/drive/folders/1C70-DJPSV2HxNPbHg6qL9wvVadlmAB2h) New tests that are merged should place stats files here instead of in the repo
the arch_test.h file has been extensively modified, and will undergo several more changes in the very near future including splitting off any test specific macros (e.g. TEST_FPRR_OP) into their own file.

After the new arch_test.h and test_macro.h files have been merged, if this is still relevant, pull from the latest, and try again.

I looked in a lot of detail about the changes in arch_test.h.
There have been updates to these test macros, in addition to splitting them off into a separate test_macros.h file.
I don't believe this PR changes those definitions, but it's hard to tell because there have been additions and corrections since then, but none that I can see that would affect Zfh.
the only substantial change is adding the definitions of FLREG = flh,FSREG =fsh, and FREGWIDTH =2. I'll make sure those go into the new arch_test.h.
This also redefinea SREG, LREG, and REGWIDTH to match , which is not correct; the width of integer registers does NOT change  when  the floating point extension changes.
I'm going to close this for now. It can be reopened if you find something missing, but that should not include Makefiles nor anything from the riscv-test-stats directory, which should be copied into the googledocs folder:
for riscv Members -> Workgroups -> ACT Test Development Artifacts -> PRs
(direct link https://drive.google.com/drive/folders/153nIRznXwzu7N1rWl9CesqwAXLqwHoEx)
in a new folder named PR#xx


fix(type): ships importMeta.d.ts with the package

Fixes build error in vitepress, https://github.com/vuejs/vitepress/issues/47

I have same problem in vite-plugin-vue-i18n.

@antfu :). It already packaged into dist.Maybe https://github.com/vitejs/vite/issues/416 can help you out.

@underfin Oh, Vitepress is using the older version. Thanks for the help :)


feat: interruptible CPU collector

I got
panic: http: multiple registrations for /debug/pprof/profile

goroutine 1 [running]:
net/http.(*ServeMux).Handle(0x927540, {0x6eccca, 0x14}, {0x764a00?, 0x718420})
        /home/korniltsev/.asdf/installs/golang/1.21.5/go/src/net/http/server.go:2530 +0x219

Maybe we should not register automatically the new endpoint in init function? or maybe the path should be different.
I am thinking that there may be cases when users import net/http/pprof from a transitive dependency, for example dskit. Also users may want to use  grafana/http/pprof  for cpu and net/http/pprof for heap.

panic: http: multiple registrations for /debug/pprof/profile

Yeah, this is expected, experimented with this while developing. I'm still testing/fixing it, and I will likely finish today – want to add some unit tests.

Maybe we should not register automatically the new endpoint in init function? or maybe the path should be different.

Agreed, I don't think there is a way to register it automatically in a nice way. I'm not sure about a custom path: use of this handler together with the standard one has little to no value, IMO


Add note about adding new images

I don't think it's the

I don't think it's the case. I can add new images instead without restarting the packager just fine.

Well, then maybe it's another windows only case

@sunnylqm Most likely. Since Windows doesn't use watchman. Can you mention Windows in the note?

I'd rather have us investigate why. Is there an open issue for this? Does it only fail for images or JS files as well?

AFAIK，it fails on every new images/modules under windows.

@facebook-github-bot shipit

@frantic Opened an issue for it - https://github.com/facebook/react-native/issues/6318


Add media convert preset to capture previews

Purpose
Displaying a thumbnail to display as a placeholder for the video and displaying small preview captures at each second of the video are two different things.
For thumbnails, we only sample one image in each resolution.
For previews, we sample one image per second on the whole video but in a size of  100 pixels.
Proposal

[x] Fix updating a preset in AWS media convert through the node.js SDK
[x] Improve preset names to differentiate usage: video, thumbnail, preview
[x] Add a preset for preview frame captures

@mbenadda prettier looks happy now :wink:


Hotfix

I was trying to run this command according to documentation:
$ php artisan api-key:generate --user-id=1 --level=10

And I got this error.
[ErrorException]
  Trying to get property of non-object

This pull request fix that error.

I think that will be great if you make a release of 2.1.1.

There you go @jotafurtado. Release v2.1.1 [dd5f3b3]


Large dictionaries cause the UI to become unresponsive

Godot version
4.0.1 Stable
System information
Windows 11 Vulkan API 1.3.224 - Forward+ - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce RTX 3050 Laptop GPU
Issue description
The company I work for are using Godot for a commercial software project rather than a game and as such we deal with large dictionaries (sometimes have a size in the 1000s). When hitting a breakpoint, if we hover over the variable which is storing the dictionary, it makes the Godot UI to become unresponsive. The only way to get out of it is to hard-crash the editor (using Task Manager or closing the console window, if open).
Using the Stack Variable inspector does not cause this same issue.
Steps to reproduce

Create a very large dictionary with lots of data, either creating it in code or loading it from a JSON file (the dictionary does not have to be large in file size, just have a lot of elements)
Place a breakpoint at a point in the code where the value of the variable which stores the dictionary is visible by hovering over it

Minimal reproduction project
This is the project I made to reproduce this, putting a breakpoint on the print(1). Unfortunately, this also showed another bug. Even variables which are not null show as null when hovering over them and when inspecting them in the stack. Printing them does show their value.
dictionary crash.zip

Can you confirm this on 4.0.4 or another more recent version?

Can you confirm this on 4.0.4 or another more recent version?

Hi, I have just tried on Godot 4.1.1 and it still crashes my interface. The difference between versions is that in 4.1.1 the interface does eventually close while leaving my runtime window open. On 4.0.1 it crashes the interface and nothing else happens.

And on 4.0.4?

And on 4.0.4?

Tested on 4.0.4 mono and on standard 4.0.4 and it doesn't crash the editor with the same dictionary that it crashes the others with

Even variables which are not null show as null when hovering over them and when inspecting them in the stack. Printing them does show their value.

I can reproduce this bug. Also when I double click the large-file.json, the editor freezed. I will take a look about what happened. I like dealing with performance issues.
Editor version: Godot v4.2.dev (6f90b2370) - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Ti (NVIDIA; <IP_ADDRESS>99) - 12th Gen Intel(R) Core(TM) i7-12700F (20 Threads)

Looks similar to https://github.com/godotengine/godot/issues/64569.

hovering a variable will show null in certain cases (small file works fine, only the large one caused lsp to return null)

About this problem :
The serialize function has a max size limit this：Array serialize(int max_size = 1 << 20); // 1 MiB default.
But the length of the json dictionary is 3353848, bigger than 1 << 20, so it just using a new Variant as value instead.

I think there might be two ways of fixing this:

Increase the limit a little bit
Instead of returning a nil value, return a more friendly info such as 'Value (along with type) too big for showing'

Any ideas?

hovering a variable will show null in certain cases (small file works fine, only the large one caused lsp to return null)

About this problem :
The serialize function for remote debug has a max size limit：Array serialize(int max_size = 1 << 20); // 1 MiB default.
But the length of the json dictionary is 3353848, bigger than 1 << 20, so it just using a new Variant as value instead.

I think there might be two ways of fixing this:

Increase the limit a little bit
Instead of returning a nil value, return a more friendly info such as 'Value (along with type) too big for showing'

Any ideas?

That makes a lot of sense. I think it would be more user friendly if the tool tip showed that the value is too large, rather than null. It has been the source of some confusion in our projects, especially for our non-programmers. Its unfortunate that the actual value can't be displayed

After fixing 1, check whether hover a large dictionary will cause crash

About this, when the test file is close to 1<<20 , the crash will happen. It's a vulkan related crash (crashed when create buffer), and I strongly suspect it's because the vertex for the flat stype box is too large as the image shown.

double click the large-file.json will freeze the editor

And the last piece of this problem, I find the hotspot like this:

This is the related code:
// Update height.
const int old_height = text.write[p_line].height;
const int wrap_amount = get_line_wrap_amount(p_line);
int height = font_height;
for (int i = 0; i <= wrap_amount; i++) {
    height = MAX(height, text[p_line].data_buf->get_line_size(i).y);
}
text.write[p_line].height = height;

Inside get_line_wrap_amount, it calles _shape_lines which is very time consuming just to get the line wrap amount (usually zero), I believe it can be optimized. Open a 470 kilobytes json file takes 2-3 seconds which is probably fine, but open a 20MB json file will completely freeze the editor for a long time and comsume a tons of memory, this is not good.
@Paulb23 Any thoughts?  I guess maybe at least for json file we can just ignore the get_line_wrap_amount call ? Or we check if autowrap is false then we skip this function ?

Many editors disable softwrapping when detecting a file that is too large or has a longest line that is over 16,384 characters long or so.

I dig into the code and find it's non trivial to simply add suppot for this, the problem lies in _shape_lines too slow and many places depend on it. If I get rid of  get_line_wrap_amount, get_size will call  _shape_lines too.
Have to pick up the hard way, find why _shape_lines is too slow.

cc @bruvzg

Any thoughts? I guess maybe at least for json file we can just ignore the get_line_wrap_amount call ? Or we check if autowrap is false then we skip this function ?

It probably won't make any difference, _shape will be called anyway as soon data_buf is accessed (line drawn or any measurement taken). The only reasonable thing is likely adding support for text processing in the background thread.

Still happening as of Godot 4.2 Stable Release.


Register classes with interfaces without to inherit from it

Hello again,
with v2.8.9 we used to Register classes with interfaces without to inherit from it.
I.g. :
        interface ITest { }

        class Test1 { }
        class Test2 { }

        container.Register(typeof(ITest), typeof(Test1));
        container.Register(typeof(ITest), typeof(Test2));

        var tests = container.ResolveAll<ITest>();

Due to some breaking changes in v3.1.0 it's not possible anymore in this way.
Do you have any suggestion, to make these possible again?

Hey,
I'm pretty sure that didn't work with v2.8.9 either. ResolveAll() returns IEnumerable<ITest> in that case, but Test1 and Test2 won't fit into that type.
May I ask that what is the use case behind this usage? We might figure out something to solve the root cause. :)

Oops, sorry, that was my mistake.
You are right, ResolveAll does not work.
Generic overloads of Resolve don't work either.
But that's not our usage either, I'm sorry.
This is our usage with non generic functions:
   interface ITest { }

    class Test1 { }
    class Test2 { }

    container.Register(typeof(ITest), typeof(Test1));
    var instanceTest1 = container.Resolve(typeof(ITest));

    container.Register(typeof(ITest), typeof(Test2), config => { config.ReplaceExisting(); });
    var instanceTest2 = container.Resolve(typeof(ITest));

Diesmal habe ich es zweimal getestet :-)
Mit v2.8.9 geht der Test ohne Fehler durch.
Mit v3.5.1-preview-617 schlug der Test mit folgender Ausnahme fehl:
    Exception has occurred: CLR/Stashbox.Exceptions.InvalidRegistrationException ...
    'Invalid registration with type STASHBOXTEST.UnitTest_StashboxContainer+Test1.
    Details: The type Test1 does not implement the service type ITest.'

Okay, that makes more sense, in that case just an object is returned. So just to make sure I understand your case correctly: are you using that interface only for service organization purposes? Is there a specific reason that you don't want to make your services implement it?
Using the service type in this way feels a bit unnatural to me, this was one of the reasons why I introduced this check in the first place to prevent accidental misconfigurations. Suppose anytime someone tries to resolve this service with the generic API, it'll throw an invalid cast exception.
I know it's not a misconfiguration in your case, but still, it feels unnatural. As a quick solution, I could make the runtime type checks configurable, but I'd strongly recommend considering your services' organization around interface types they actually implement.

Hi,
I'm right there with you.
For me it is also unnatural.
You don't need to change anything for that.
I will adjust my code.
I thought maybe there is a solution, which I don't see.
Thank you very much.


Add Rule For no-send-action

A rule to catch sendAction has been added, but we should also include send. So leaving this open until that happens.

@trentmwillis should the same rule include both or do we want separate rules for this? I'd be happy to complete this.

We should likely have them be separate. While they're closely related, I suppose there could be a situation where you want one but not the other (maybe during a migration). Maybe call the second one no-send?


Adds ops file to give turbulence api an external ip

this enables users to view the web interface

[#143539447]

@ekcasey i dont thnk we want to be encouraging more people to place things on public ip. how about doing a tunnel for that port and viewing it over localhost?

The turbulence UI requires authentication and we would rather avoid the overhead of setting up a tunnel to it. This is especially true because we have 5 different turbulence enabled environments.

@ekcasey i wouldnt mind chatting a bit more, may be over hangout.


API

add endpoints to:
read all cafe
read cafe by id
save cafe
delete cafe
edit cafe
all the same for dishes, but read all dishes will be for cafe_id

Send order:
List of dishes
Tabel number
Time (now by default)


Stdout reporting enhancements incl. Error cases.

except from average values, more statistics like percentiles, medians, etc.

This feature is implemented as part of 2.1.x


Using onDone/onStart with states

I am trying to use this with Vuex, but I'm not sure if it should work.
This is inside my store.js file:
Vue.use(VueScrollTo, {
  duration: 750,
  cancelable: false,
  onDone() {
    this.$store.state.noScroll = true;
  }
});

export default new Vuex.Store({
  state: {
             noScroll: false
  }

In theory it should work, right? But I am getting this error:
TypeError: Cannot read property '$store' of undefined
What am I doing wrong?

Inside the onDone callback, you don't have a this context.
If you have access to a store variable where you are registering the plugin, changing this.$store to store should work.

I'm not sure I'm following. Could you give an example of your suggested solution?

I'm not sure I'm following. Could you give an example of your suggested solution?

this.$store is only available inside vue instances, since you are registering the plugin with Vue.use in your entry file (where you create your root Vue instance), you likely have access to the store variable (since you are passing it into the root Vue instance).
In your onDone callback, replace this.$store.state.noScroll = true with store.state.noScroll = true; and it should work (just make sure the Vue.use(VueScrollTo, {... statement is after you have the store variable).

Found the solution now. Thank you for your help.
https://codepen.io/anon/pen/xmYwLq


Bug with external variables

External variables are overload in case VPP questionnaire

It's not a bug, datas has been overloaded by old data from a previous query, as the same UE id was used for both campaigns.


TypeError: unsupported operand type

Describe the bug
TypeError: unsupported operand type(s) for |: 'type' and 'type'
To Reproduce
Steps to reproduce the behavior:
from mailer import Mailer
mail = Mailer(email='sender', password='password')
mail.settings(provider=mail.MICROSOFT)
mail.send(receiver='receiver', subject='TEST', message='From Python')
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

OS: win 10
Browser chrome
Version 97.0.4692.71

Additional context
Add any other context about the problem here.

fixed, thanks

Still having the same error with version 2022.2.2

Still having the same error with version 2022.2.2

Fixed thanks for report, update to new version.
pip install -U quick-mailer

OR
pip install quick-mailer==2022.2.10


Make environment variable in bash script persist

Rather than using export SDSCHEDULE_SCRAPE=0, we could just use unset SDSCHEDULE_SCRAPE. It's cleaner; that way we don't persist anything.
Also, I thought running the script from the command line doesn't persist variables? As in exporting a variable from the script won't save it to the CL session.


Board LEDs & CC1110 Initialization

I’ve been testing the Explorer Board you kindly gifted in SF but have been having some issues using it…
I’ve tried booting Yocto / Jubi on the Edison but the trouble I have seems to be related with the Explorer Board initialization??
Whenever I boot… no leds come on only after I run the ExplorerTest.py
After that… whenever I run any mmeowlink commands, it seems that the first try gives me a:
CommsException("Could not get subg_rfspy state or version. Have you got the right port/device and radio_type?")
mmeowlink.

So the only way I can use it on my loop effectively is:
a) run ExplorerTest.py on startup
b) run whatever mmeowlink command I want to use 2 - 3 times in a row… first or second try I get
CommsException("Could not get subg_rfspy state or version. Have you got the right port/device and radio_type?")

Then on last try the command goes through…

It seems that problem went away after I changed my mmewolink to @scottleibrand's:
https://github.com/scottleibrand/mmeowlink
Will continue testing to make sure its consistent.


fixed issue for connection to iSCSI protal

fixed issue for connection to iSCSI protal when using lvm as cinder backend

Thank you for contributing to openstack/kolla-ansible!
openstack/kolla-ansible uses Gerrit for code review.
If you have never contributed to OpenStack before make sure you have read the
getting started documentation:
http://docs.openstack.org/infra/manual/developers.html#getting-started
Otherwise please visit
http://docs.openstack.org/infra/manual/developers.html#development-workflow
and follow the instructions there to upload your change to Gerrit.


BrowserWebDriverContainer with DockerComposeContainer

I might be missing something really simple, but it doesn't seem like it's possible to use a BrowserWebDriverContainer to interact with the environment produced by DockerComposeContainer.
It looks like the two environments (browser+vncrecorder and docker-compose) end up with different network config. I can't see an obvious/reliable way to configure the network of either to make sure they can talk to each other.
Is there a documented example/test for this sort of configuration?
If the browser container can't be easily added to the compose context (e.g. new DockerComposeContainer(...).withAdditional(new BrowserWebDriverContainer()) would be cool), maybe it would be enough to be able to extract the ambassador container for a given service, so it can be used via withLinkToContainer. Then of course getServiceHost might not return the right hostname though - it's probably a lot more complex than I imagine.
[On a related note it would also be cool to add some API sugar to BWDC for direct/procedural manipulation. I'm using cucumber-jvm and in that context standard junit @Rules don't work. Right now I'm working around this by extending the class and making public functions which call super.starting()/super.finished() which I can run between my test scenarios. It's really the cucumber lib's problem, but they don't seem interested in fixing it. 😞]

Hi @Zetten
It's not a configuration that I've used much myself, but it shouldn't be too hard. IIRC @outofcoffee and @haines might have used selenium and compose together, but I could be wrong.
Anyway, I've dug up an old, unpolished example which points a chrome browser container at a very large docker-compose stack, and put the relevant bits into a gist here. This configuration successfully allows the browser container to hit one of the compose containers, as long as it's exposed:
@ClassRule
    public static DockerComposeContainer compose =
            new DockerComposeContainer(new File("src/test/resources/docker-compose.yml"))
.withExposedService("edge-router", 80);

and:
driver.get("http://" + compose.getServiceHost("edge-router_1", 80) + ":" + compose.getServicePort("edge-router_1", 80) + "/");

Please be aware that I've not exhaustively tested this across all different Docker environment types; this works for me on Docker Machine on a Mac, and I'll give it a try on Docker for Mac shortly.
N.B. this example uses Weaveworks' awesome sockshop microservices demo if you're interested.
Re making the API easier to use in non-JUnit contexts: absolutely, yes, we have plans!
HTH
Richard

Hmm, the test case is almost identical in principle to what I'm trying to do, yet in my case I can't get any response via the WebDriver.
I've checked the URL being built up and it looks good: the same URL is tested via a programmatic HTTP client in the test code, and if I pause execution I can access it with curl/a native browser. So I'm pretty sure the compose environment/ambassador container is working.
If I take a look at the container recording, it shows the same URL in the address bar, but the response is ERR_CONNECTION_REFUSED.
Because the "normal" requests from the host were working I assumed it must be something specific with the BrowserWebDriverContainer. Plus in my environment (docker.sock) getServiceHost is returning localhost - I have a feeling this might a problem...
If it helps, docker inspect <browser container> shows:
        "NetworkSettings": {
            "Bridge": "",
            "SandboxID": "3c7bb405346593b819bf31c6dcf1918ae6b7c69cb64dce85260817534138c2a1",
            "HairpinMode": false,
            "LinkLocalIPv6Address": "",
            "LinkLocalIPv6PrefixLen": 0,
            "Ports": {
                "4444/tcp": [
                    {
                        "HostIp": "<IP_ADDRESS>",
                        "HostPort": "32786"
                    }
                ],
                "5900/tcp": [
                    {
                        "HostIp": "<IP_ADDRESS>",
                        "HostPort": "32785"
                    }
                ]
            },
            "SandboxKey": "/var/run/docker/netns/3c7bb4053465",
            "SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null,
            "EndpointID": "c5f86319b69508d2661e4d9886402e7d4fe92d30e1b5fa4571519a84dbc12f41",
            "Gateway": "<IP_ADDRESS>",
            "GlobalIPv6Address": "",
            "GlobalIPv6PrefixLen": 0,
            "IPAddress": "<IP_ADDRESS>",
            "IPPrefixLen": 16,
            "IPv6Gateway": "",
            "MacAddress": "02:42:ac:11:00:02",
            "Networks": {
                "bridge": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": null,
                    "NetworkID": "da1e61a442b15ace9d73379cd8275054ce6853daf473989a6ae5fda10a7cda95",
                    "EndpointID": "c5f86319b69508d2661e4d9886402e7d4fe92d30e1b5fa4571519a84dbc12f41",
                    "Gateway": "<IP_ADDRESS>",
                    "IPAddress": "<IP_ADDRESS>",
                    "IPPrefixLen": 16,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": "02:42:ac:11:00:02"
                }
            }
        }

And for <ambassador container>:
        "NetworkSettings": {
            "Bridge": "",
            "SandboxID": "70a2c4451c8f880c8d7b7a1acd6fe194e655018023c9a3b0b0dfbe6fd1b9678f",
            "HairpinMode": false,
            "LinkLocalIPv6Address": "",
            "LinkLocalIPv6PrefixLen": 0,
            "Ports": {
                "80/tcp": [
                    {
                        "HostIp": "<IP_ADDRESS>",
                        "HostPort": "32784"
                    }
                ]
            },
            "SandboxKey": "/var/run/docker/netns/70a2c4451c8f",
            "SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null,
            "EndpointID": "",
            "Gateway": "",
            "GlobalIPv6Address": "",
            "GlobalIPv6PrefixLen": 0,
            "IPAddress": "",
            "IPPrefixLen": 0,
            "IPv6Gateway": "",
            "MacAddress": "",
            "Networks": {
                "cpkf2j_default": {
                    "IPAMConfig": null,
                    "Links": [
                        "/cpkf2j_ftep-proxy_1:ftep-proxy_1"
                    ],
                    "Aliases": [
                        "1b38c76844ae"
                    ],
                    "NetworkID": "6731dff0e7946228c88a5a16df7acb313c3b9fdee03d0a6e6e682d167d0af2df",
                    "EndpointID": "fdc8f57337f88905a1b010d024f0972526656d91eeee07b37be426588f67d2a9",
                    "Gateway": "<IP_ADDRESS>",
                    "IPAddress": "<IP_ADDRESS>",
                    "IPPrefixLen": 16,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": "02:42:ac:1a:00:08"
                }
            }
        }

I've created a rather contrived example demonstrating my issue here: https://github.com/Zetten/testcontainers-selenium-compose-test
(I apologise in advance for the dirty, hacky Harness class - like I mentioned before it's just supporting our use of Cucumber-Jvm and I haven't invested a lot of time in cleaning it up.)
The compose file describes a single nginx container with an index.html file mounted in the docroot.
The okhttp3 lib test passes, but the selenium test fails. It saves the screen recording to build/recording/recording-*.flv where it can be seen that it's getting a connection refused error for http://localhost:<ambassador_port>.

As a workaround I've extracted the "docker-in-docker" host IP evaluation from DockerClientConfigUtils, rather than trusting environment.getServiceHost. This seems to work pretty well in the test project at least; I will test it in my main project sometime this week.
Essentially the workaround changes:
    private String getBaseUrl() {
        return "http://" +
                environment.getServiceHost("web_1", 80) + ":" +
                environment.getServicePort("web_1", 80);
    }

    private String getBaseUrl() {
        String ip = StringUtils.trimToEmpty(DockerClientFactory.instance().runInsideDocker(
                cmd -> cmd.withCmd("sh", "-c", "ip route|awk '/default/ { print $3 }'"),
                (client, id) -> {
                    try {
                        return client.logContainerCmd(id)
                                .withStdOut(true)
                                .exec(new LogToStringContainerCallback())
                                .toString();
                    } catch (Exception e) {
                        LOG.warn("Can't parse the default gateway IP", e);
                        return null;
                    }
                }));

        return "http://" +
                ip + ":" +
                environment.getServicePort("web_1", 80);
    }

Hi,
I had the same issue. The workaround I am using is to start DockerComposeContainer with a specific id X, and then use withNetworkMode in BrowserWebDriverContainer to point to "X_default", ie. making this latter Docker image join the same network as the one of Docker Compose. In code (Kotlin):
companion object {
    class KDockerComposeContainer(id: String, path: File) : DockerComposeContainer<KDockerComposeContainer>(id, path)

    val composeId = "gateway"

    @ClassRule
    @JvmField
    val env = KDockerComposeContainer(composeId, File("../docker-compose.yml"))
            .withLocalCompose(true)
}

@Rule
@JvmField
var browser = KBrowserWebDriverContainer()
        .withDesiredCapabilities(DesiredCapabilities.chrome())
        .withNetworkMode("${composeId}_default")

class KBrowserWebDriverContainer : BrowserWebDriverContainer<KBrowserWebDriverContainer>()

I have the same issue even without docker compose, just with BrowserWebDriverContainer: it I run a few tests, the videos of the first one are never recorded, the videos of the next ones are recorded
➜  ~ docker ps -a
CONTAINER ID        IMAGE                                    COMMAND                  CREATED              STATUS                          PORTS                                              NAMES
3e3efbbda739        richnorth/vnc-recorder:latest            "flvrec.py -o /rec..."   About a minute ago   Exited (1) About a minute ago                                                      amazing_volhard

➜  ~ docker logs 3e3efbbda739
start recording
Socket error: [Errno 111] Connection refused
stop recording
➜  ~

I think this might be worth reopening.
With 1.17.2 the networkMode work around does not work any more - I think because BrowserWebDriverContainer.configure has this logic:
            if (getNetwork() == null) {
                withNetwork(Network.SHARED);
            }

and if network is present then a specific network name in networkMode is not used.
I think it's a valid use case to want to launch the selenium container in the same network as the compose environment so that it does not have to interact with the compose environment via ports exposed to the host.


Adjust EntryNodeWriterTest to Java 11

Pull Request Test Coverage Report for Build 4735

4 of 5 (80.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.002%) to 53.692%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

bundle/src/main/java/com/adobe/acs/commons/httpcache/store/jcr/impl/writer/EntryNodeWriter.java
4
5
80.0%

Totals

Change from base Build 4720:
-0.002%

Covered Lines:
13926

Relevant Lines:
25937

💛  - Coveralls


What should our API at the command line look like?

With transformFormats in 8cec2c08f774b31dcc840acf33a83f7dd30eb0a2, we introduced a single CLI command that helps both ways, in that it transforms from native formats to ADAM Parquet and vice versa.
Looking at our current list of commands, perhaps we should extend this pattern
adam2fasta
adam2fastq
adam2vcf
allelecount
anno2adam
count_contig_kmers
count_kmers
depth
fasta2adam
flagstat
flatten
fragments2reads
listdict
mergeShards
print
reads2coverage
reads2fragments
transform
transformFeatures
vcf2adam
view
wigfix2bed

Taking it to the extreme (where all the conversion operations fit under a single transform command) is going too far; I'm looking for a nice balance.
We could also take this opportunity to make sure all the commands and command line arguments are named consistently (e.g. camelCase vs. snake_case vs. whatever-you-call-it-with-dashes).

I think this has substantial overlap with #1327; I'm going to close in favor of the other ticket, as it is more actionable. @heuermh please reopen if you disagree.


Start removing mage :tada:

This PR takes the first step to removing mage from our CI - unfortunately, to do the whole thing is still a little tricky right now.
There are several parts:

The CI uses dagger call instead of hack/make.
hack/make is removed! All CI jobs that still use it, now directly call go run.
All unnecessary mage shim functions are removed. We keep:

engine:dev, used for ./hack/dev. Eventually, this should be replaced by https://github.com/dagger/dagger/pull/7223.
engine:publish, used during github publishing. This connects the cli+engine publishing together, and ensures that the cli parts are all bumped. This is trickier to remove - we'd want to make our _hack_make.yml script an action, instead of a workflow - then, we can connect it through to other actions.

Note! This PR changes some workflows on main, which don't run in a PR - so there is a chance that these workflows might fail when merged.

Picking this up now since I have some related changes coming up and it would be best to have this merged before then.

Rebased, and also realized that we had missed bumping every runner in the last "improving release" PR - specifically the release job was still using v0.11.2.


charts: Replace hardcoded namespaces

What this PR does / why we need it:

Removes the hardcoded namespace values used within the different chart hooks.
Special notes for your reviewer:
There are some resources created in the default namespace across the pre-install-job and post-upgrade-job hooks. Should those be updated as well?

https://github.com/rancher/turtles/blob/main/charts/rancher-turtles/templates/post-upgrade-job.yaml#L54
https://github.com/rancher/turtles/blob/main/charts/rancher-turtles/templates/pre-install-job.yaml#L7
https://github.com/rancher/turtles/blob/main/charts/rancher-turtles/templates/pre-install-job.yaml#L61
https://github.com/rancher/turtles/blob/main/charts/rancher-turtles/templates/pre-install-job.yaml#L83

Checklist:

[X] squashed commits into logical changes
[ ] includes documentation
[ ] adds unit tests
[ ] adds or updates e2e tests

Thanks @atanasdinov, I agree this is a sensible thing to support. Maybe it would be great to also have some kind of test that validates that nothing breaks if a user specifies a custom namespace (just to be 100% sure), did you have the chance to test it yourself? There may be some "hidden" references to rancher-turtles-system as it's been considered "Turtles' namespace" until now, that could eventually beak something.
I think it makes sense to also create pre-install/post-upgrade jobs in the user-specified namespace. This one you're also linking https://github.com/rancher/turtles/blob/451c249449b9371dc9cc04263e14fff972c6bb16/charts/rancher-turtles/templates/pre-install-job.yaml#L7 disables the existing Rancher CAPI feature and should stay the same, though.


Fix bug 'Restart causes a resync from genesis'

Can you patch this to v7?

Can you patch this to v7?

@islishude This was never a problem with 7.*. From the commit message, this fixes a bug in ceb2e38 but that commit was never in 7.*

@islishude This was never a problem with 7.*. From the commit message, this fixes a bug in ceb2e38 but that commit was never in 7.*

when I restart the service,It reports flowing log and takes so many time,I have to delete all data and resync.
I have met this two times.
dbsync_1          | [db-sync-node.Mux:Info:95] [2021-01-29 06:06:50.74 UTC] Bearer on ConnectionId {localAddress = LocalAddress "", remoteAddress = LocalAddress "/ipc/node.socket"} event: Handshake Client end, duration 0.003558267s
dbsync_1          | [db-sync-node.Mux:Info:96] [2021-01-29 06:06:50.75 UTC] Bearer on ConnectionId {localAddress = LocalAddress "", remoteAddress = LocalAddress "/ipc/node.socket"} event: State: Mature
dbsync_1          | [db-sync-node:Info:99] [2021-01-29 06:06:50.75 UTC] Starting chainSyncClient
dbsync_1          | [db-sync-node:Info:99] [2021-01-29 06:06:50.76 UTC] Database tip is at slot 20333184, block 5271518
dbsync_1          | [db-sync-node:Info:104] [2021-01-29 06:06:50.76 UTC] Running DB thread
dbsync_1          | [db-sync-node.Subscription:Notice:31] [2021-01-29 06:06:50.77 UTC] [String "Required subscriptions started",String "SubscriptionTrace"]
dbsync_1          | [db-sync-node:Info:104] [2021-01-29 06:06:50.83 UTC] Rolling back to slot 0, hash f0f7892b5c333cffc4b3c4344de48af4cc63f55e44936196f365a9ef2244134f
dbsync_1          | [db-sync-node:Info:107] [2021-01-29 06:06:50.84 UTC] getHistoryInterpreter: acquired
^@dbsync_1          | [db-sync-node:Error:104] [2021-01-29 06:07:04.55 UTC] Rollback block count is high and therefore rollback is likely to be incredibly slow. Dropping the database and resyncing from scratch will be faster.
dbsync_1          | [db-sync-node:Info:104] [2021-01-29 06:07:32.86 UTC] Deleting slots numbered: [20333184..1]

when I restart the service,It reports flowing log and takes so many time,I have to delete all data and resync.
I have met this two times.
dbsync_1          | [db-sync-node.Mux:Info:95] [2021-01-29 06:06:50.74 UTC] Bearer on ConnectionId {localAddress = LocalAddress "", remoteAddress = LocalAddress "/ipc/node.socket"} event: Handshake Client end, duration 0.003558267s
dbsync_1          | [db-sync-node.Mux:Info:96] [2021-01-29 06:06:50.75 UTC] Bearer on ConnectionId {localAddress = LocalAddress "", remoteAddress = LocalAddress "/ipc/node.socket"} event: State: Mature
dbsync_1          | [db-sync-node:Info:99] [2021-01-29 06:06:50.75 UTC] Starting chainSyncClient
dbsync_1          | [db-sync-node:Info:99] [2021-01-29 06:06:50.76 UTC] Database tip is at slot 20333184, block 5271518
dbsync_1          | [db-sync-node:Info:104] [2021-01-29 06:06:50.76 UTC] Running DB thread
dbsync_1          | [db-sync-node.Subscription:Notice:31] [2021-01-29 06:06:50.77 UTC] [String "Required subscriptions started",String "SubscriptionTrace"]
dbsync_1          | [db-sync-node:Info:104] [2021-01-29 06:06:50.83 UTC] Rolling back to slot 0, hash f0f7892b5c333cffc4b3c4344de48af4cc63f55e44936196f365a9ef2244134f
dbsync_1          | [db-sync-node:Info:107] [2021-01-29 06:06:50.84 UTC] getHistoryInterpreter: acquired
^@dbsync_1          | [db-sync-node:Error:104] [2021-01-29 06:07:04.55 UTC] Rollback block count is high and therefore rollback is likely to be incredibly slow. Dropping the database and resyncing from scratch will be faster.
dbsync_1          | [db-sync-node:Info:104] [2021-01-29 06:07:32.86 UTC] Deleting slots numbered: [20333184..1]

That is fixed in 8.0.0 .

That is fixed in 8.0.0 .

@erikd 8.0 still delete all data when restart
dbsync_1          | /run/secrets
dbsync_1          | Generating PGPASS file
dbsync_1          | Connecting to network: mainnet
dbsync_1          | [db-sync-node:Info:4] [2021-02-02 12:36:44.69 UTC] NetworkMagic: 764824073
dbsync_1          | [db-sync-node:Info:4] [2021-02-02 12:36:44.84 UTC] Initial genesis distribution present and correct
dbsync_1          | [db-sync-node:Info:4] [2021-02-02 12:36:44.84 UTC] Total genesis supply of Ada:<PHONE_NUMBER>5.000000
dbsync_1          | [db-sync-node:Info:4] [2021-02-02 12:36:44.85 UTC] Inserting Shelley Genesis distribution
dbsync_1          | [db-sync-node:Info:4] [2021-02-02 12:36:44.86 UTC] epochPluginOnStartup: Checking
dbsync_1          | [db-sync-node:Info:4] [2021-02-02 12:36:45.36 UTC] localInitiatorNetworkApplication: connecting to node via "/node-ipc/node.socket"
dbsync_1          | [db-sync-node.Subscription:Notice:41] [2021-02-02 12:36:45.36 UTC] Identity Starting Subscription Worker, valency 1
dbsync_1          | [db-sync-node.Subscription:Notice:42] [2021-02-02 12:36:45.37 UTC] Identity Connection Attempt Start, destination LocalAddress "/node-ipc/node.socket"
dbsync_1          | [db-sync-node.Subscription:Notice:42] [2021-02-02 12:36:45.37 UTC] Identity Connection Attempt End, destination LocalAddress "/node-ipc/node.socket" outcome: ConnectSuccessLast
dbsync_1          | [db-sync-node.Handshake:Info:42] [2021-02-02 12:36:45.37 UTC] WithMuxBearer (ConnectionId {localAddress = LocalAddress "", remoteAddress = LocalAddress "/ipc/node.socket"}) Send (ClientAgency TokPropose,MsgProposeVersions (fromList [(NodeToClientV_1,TInt 764824073),(NodeToClientV_2,TInt 764824073),(NodeToClientV_3,TInt 764824073),(NodeToClientV_4,TInt 764824073),(NodeToClientV_5,TInt 764824073),(NodeToClientV_6,TInt 764824073),(NodeToClientV_7,TInt 764824073),(NodeToClientV_8,TInt 764824073)]))
dbsync_1          | [db-sync-node.Handshake:Info:42] [2021-02-02 12:36:45.37 UTC] WithMuxBearer (ConnectionId {localAddress = LocalAddress "", remoteAddress = LocalAddress "/ipc/node.socket"}) Recv (ServerAgency TokConfirm,MsgAcceptVersion NodeToClientV_8 (TInt 764824073))
dbsync_1          | [db-sync-node.Mux:Info:42] [2021-02-02 12:36:45.37 UTC] Bearer on ConnectionId {localAddress = LocalAddress "", remoteAddress = LocalAddress "/ipc/node.socket"} event: Handshake Client end, duration 0.000998513s
dbsync_1          | [db-sync-node.Mux:Info:44] [2021-02-02 12:36:45.37 UTC] Bearer on ConnectionId {localAddress = LocalAddress "", remoteAddress = LocalAddress "/ipc/node.socket"} event: State: Mature
dbsync_1          | [db-sync-node:Info:47] [2021-02-02 12:36:45.37 UTC] Starting chainSyncClient
dbsync_1          | [db-sync-node.Subscription:Notice:41] [2021-02-02 12:36:45.39 UTC] Identity Required subscriptions started
dbsync_1          | [db-sync-node:Info:47] [2021-02-02 12:36:45.40 UTC] Database tip is at slot 20702509, block 5289776
dbsync_1          | [db-sync-node:Info:51] [2021-02-02 12:36:45.40 UTC] Running DB thread
dbsync_1          | [db-sync-node:Info:54] [2021-02-02 12:36:45.46 UTC] getHistoryInterpreter: acquired
dbsync_1          | [db-sync-node:Info:51] [2021-02-02 12:36:45.46 UTC] Rolling back to slot 0, hash f0f7892b5c333cffc4b3c4344de48af4cc63f55e44936196f365a9ef2244134f
dbsync_1          | [db-sync-node:Info:51] [2021-02-02 12:37:13.49 UTC] Deleting slots numbered: [20702509..1]

Did you drop and recreate the database when you switched to version 8.0.0? That requirement is specified in the changelog.

Did you drop and recreate the database when you switched to version 8.0.0? That requirement is specified in the changelog.

yes,of course

I may have found the reason,db-sync only handles SIGINT to graceful stop,but default stop signal of docker is SIGTERM,after grace period (10s for docker),docker sends SIGKILL to db-sync.

use SIGINT not works.
dbsync_1          | [db-sync-node.Subscription:Notice:139] [2021-02-03 02:49:28.90 UTC] Identity Connection Attempt Start, destination LocalAddress "/node-ipc/node.socket"
dbsync_1          | [db-sync-node.Subscription:Error:139] [2021-02-03 02:49:28.90 UTC] Identity Connection Attempt Exception, destination LocalAddress "/node-ipc/node.socket" exception: Network.Socket.connect: <socket: 13>: does not exist (No such file or directory)
dbsync_1          | [db-sync-node.ErrorPolicy:Warning:4] [2021-02-03 02:49:28.90 UTC] IP LocalAddress "/node-ipc/node.socket" ErrorPolicySuspendPeer (Just (ConnectionExceptionTrace Network.Socket.connect: <socket: 13>: does not exist (No such file or directory))) 20s 20s
dbsync_1          | [db-sync-node.Subscription:Warning:41] [2021-02-03 02:49:28.92 UTC] Identity Failed to start all required subscriptions
dbsync_1          | [db-sync-node.Subscription:Notice:41] [2021-02-03 02:49:29.92 UTC] Identity Restarting Subscription after 1.026317663s desired valency 1 current valency 0
dbsync_1          | [db-sync-node.Subscription:Notice:41] [2021-02-03 02:49:38.91 UTC] Identity Starting Subscription Worker, valency 1
dbsync_1          | [db-sync-node.Subscription:Notice:141] [2021-02-03 02:49:38.91 UTC] Identity Connection Attempt Start, destination LocalAddress "/node-ipc/node.socket"
dbsync_1          | [db-sync-node.Subscription:Error:141] [2021-02-03 02:49:38.91 UTC] Identity Connection Attempt Exception, destination LocalAddress "/node-ipc/node.socket" exception: Network.Socket.connect: <socket: 13>: does not exist (No such file or directory)
dbsync_1          | [db-sync-node.ErrorPolicy:Warning:4] [2021-02-03 02:49:38.91 UTC] IP LocalAddress "/node-ipc/node.socket" ErrorPolicySuspendPeer (Just (ConnectionExceptionTrace Network.Socket.connect: <socket: 13>: does not exist (No such file or directory))) 20s 20s
dbsync_1          | [db-sync-node.Subscription:Warning:41] [2021-02-03 02:49:38.93 UTC] Identity Failed to start all required subscriptions
dbsync_1          | [db-sync-node.Subscription:Notice:41] [2021-02-03 02:49:39.93 UTC] Identity Restarting Subscription after 1.02649473s desired valency 1 current valency 0
dbsync_1          | [db-sync-node.Subscription:Notice:41] [2021-02-03 02:49:48.91 UTC] Identity Starting Subscription Worker, valency 1
dbsync_1          | [db-sync-node.Subscription:Notice:143] [2021-02-03 02:49:48.91 UTC] Identity Connection Attempt Start, destination LocalAddress "/node-ipc/node.socket"
dbsync_1          | [db-sync-node.Subscription:Notice:143] [2021-02-03 02:49:48.91 UTC] Identity Connection Attempt End, destination LocalAddress "/node-ipc/node.socket" outcome: ConnectSuccessLast
dbsync_1          | [db-sync-node.Handshake:Info:143] [2021-02-03 02:49:48.91 UTC] WithMuxBearer (ConnectionId {localAddress = LocalAddress "", remoteAddress = LocalAddress "/ipc/node.socket"}) Send (ClientAgency TokPropose,MsgProposeVersions (fromList [(NodeToClientV_1,TInt 764824073),(NodeToClientV_2,TInt 764824073),(NodeToClientV_3,TInt 764824073),(NodeToClientV_4,TInt 764824073),(NodeToClientV_5,TInt 764824073),(NodeToClientV_6,TInt 764824073),(NodeToClientV_7,TInt 764824073),(NodeToClientV_8,TInt 764824073)]))
dbsync_1          | [db-sync-node.Handshake:Info:143] [2021-02-03 02:49:48.91 UTC] WithMuxBearer (ConnectionId {localAddress = LocalAddress "", remoteAddress = LocalAddress "/ipc/node.socket"}) Recv (ServerAgency TokConfirm,MsgAcceptVersion NodeToClientV_8 (TInt 764824073))
dbsync_1          | [db-sync-node.Mux:Info:143] [2021-02-03 02:49:48.91 UTC] Bearer on ConnectionId {localAddress = LocalAddress "", remoteAddress = LocalAddress "/ipc/node.socket"} event: Handshake Client end, duration 0.001969764s
dbsync_1          | [db-sync-node.Mux:Info:144] [2021-02-03 02:49:48.91 UTC] Bearer on ConnectionId {localAddress = LocalAddress "", remoteAddress = LocalAddress "/ipc/node.socket"} event: State: Mature
dbsync_1          | [db-sync-node:Info:147] [2021-02-03 02:49:48.91 UTC] Starting chainSyncClient
dbsync_1          | [db-sync-node.Subscription:Notice:41] [2021-02-03 02:49:48.93 UTC] Identity Required subscriptions started
dbsync_1          | [db-sync-node:Info:147] [2021-02-03 02:49:48.95 UTC] Database tip is at slot 14823133, block 5000232
dbsync_1          | [db-sync-node:Info:151] [2021-02-03 02:49:48.95 UTC] Running DB thread
dbsync_1          | [db-sync-node:Info:151] [2021-02-03 02:49:49.18 UTC] Rolling back to slot 0, hash f0f7892b5c333cffc4b3c4344de48af4cc63f55e44936196f365a9ef2244134f
dbsync_1          | [db-sync-node:Info:154] [2021-02-03 02:49:49.18 UTC] getHistoryInterpreter: acquired
dbsync_1          | [db-sync-node:Info:151] [2021-02-03 02:50:14.27 UTC] Deleting slots numbered: [14823133..1]

@islishude Are you using the docker-compose.yml docker spec in the db-sync repo or something you have rolled yourself?

checked,I don't mount /var/lib/cdbsync

I know nothing about docker, but I do know that db-sync needs the directory pointed to by --state-dir be persistent.

that was my mistake, and it should be fixed now.


A Bug While Running Surveys That Take More Than One Minute To Complete

Hi,
I am submitting a bug issue I found while running my survey using edsl. It seems that as the number of iterations/simulations increases (and based on my experience when running the entire survey takes more than one minute), the system stops running and keeps generating this error message (always starts with "Attempt 1"):
Attempt 1 failed with exception:Task timed out after 60.0 seconds. now waiting 1.00 seconds before  retrying.Parameters: start=1.0, max=60.0, max_attempts=5.
Some basic information that can be helpful:
edsl version: 0.1.31 (just upgraded today)
OS: Windows 10
python version: 3.12.4
Below is a simple example to replicate the error:
from edsl import ScenarioList, Scenario, Model, Agent

# ### scenarios (doesn't work)
# scenario = ScenarioList([
#     Scenario({"name1": "A", "name2": "B", "name3": "C", "name4": "D",
#               "exp1": exp1, "exp2": exp2, "exp3": exp3, "exp4": exp4})
#     for exp1 in [5,8,11]
#     for exp2 in [5,8,11]
#     for exp3 in [5,8,11]
#     for exp4 in [5,8,11]
# ])
## scenarios (does work)
scenario = ScenarioList([
    Scenario({"name1": "A", "name2": "B", "name3": "C", "name4": "D",
              "exp1": exp1, "exp2": exp2, "exp3": exp3, "exp4": exp4})
    for exp1 in [5,8]
    for exp2 in [5,8]
    for exp3 in [5,8]
    for exp4 in [5,8]
])

### agents
## city of the job
cities = ["New York City", "Los Angeles"]
## job title
titles = ["Administrative Assistant", "Office Manager", "Executive Assistant"]
## agent construct
agents = [Agent(traits={"city": city, "job_post_title": title}, instruction = "You should evaluate job applicants based on all available informaton presented.",
                traits_presentation_template="""You are an HR manager in a mid-size service firm in {{city}} and are screening job applicants for your {{ job_post_title }} job position.""") for city in cities for title in titles]

for agent in agents:
    agent.agent_persona.render(primary_replacement=agent.traits)

#agents[0].agent_persona.render(primary_replacement=agents[0].traits)

### questions
from edsl.questions import QuestionCheckBox
q = QuestionCheckBox(
    question_name="pick",
    question_text="Who are the candidates you are most interested in? Below are the specific information of each candidate. Please select up to 2 candidates. Applicant 1: Name: {{name1}}, {{exp1}} years of experience in {{agent.job_post_title}}. Applicant 2: Name: {{name2}}, {{exp2}} years of experience in {{agent.job_post_title}}. Applicant 3: Name: {{name3}}, {{exp3}} years of experience in {{agent.job_post_title}}. Applicant 4: Name: {{name4}}, {{exp4}} years of experience in {{agent.job_post_title}}.",
    question_options=["Applicant 1", "Applicant 2", "Applicant 3", "Applicant 4"],
    min_selections=0,
    max_selections=2
)

### Model
model = Model('gpt-4o-2024-08-06', temperature = 0.3, max_tokens=16384)
model.set_rate_limits(rpm=1000, tpm=1000000)
#Model.available()
model

results = q.by(scenario).by(agents).by(model).run(progress_bar=True)

@rbyh can you take a look here?

Thank you for sharing!
I am not getting an error running your code, so I wonder if it is a problem with limits on your Open AI account? Do you want to try running it using remote inference?
Here is a notebook where I run your code, and then run a slightly modified version of it:
https://www.expectedparrot.com/content/b57e89ba-ac38-4af8-a5a2-4cce4a4b9406
I also posted the results of each version to the Coop so you can download them:
Original: https://www.expectedparrot.com/content/39cce9ea-4a8b-47ee-ab54-315b0e26dcbc
Revised: https://www.expectedparrot.com/content/2567fe9d-6851-45a7-b42f-5fc10b8a528b
(These URLs are unlisted, so you can share the links with anyone but they won't appear in Coop search results.)
You'll see that I also printed all the results in tables in the notebook, and that I included the "comment" field in case useful for debugging answers now or in the future if you change the questions and scenarios.
Please let us know if checking your Open AI account helps here -- happy to continue debugging.

(The notebook is long, so the Coop page might take a few seconds to load.)

Thanks so much for investigating it timely and sharing the notebook!
Sorry if there is a confusion: In my shared code above, the first chunk of Scenario syntax that I commented out is the part causing the issue. As you may see, the difference between that scenario list with the one you ran in the notebook is some additional exp variations (i.e., more simulations). When we add the an additional value, 11, in the the simulation, it would theoretically take more one one minute to finish the whole survey. In my experience, that error never occurs when the total run time is below one minute. Would you like to try to run it with the scenario that I currently commented out and see if the error could be reproduced?
Additionally, thanks for your suggestions on the OpenAI limits. But I suspect if it is really the cause, as I am in the tier-4 limit, which should be quite capable for this job.
Thank you so much again. Looking forward to your additional insights!

No problem! I just reran it adding back in 11 to both versions without any problems. Let me know if this works for you? Updated notebook page will take some time to load.

I filtered the output that is printed in a table to speed up page loading, but the full results are available at Coop.

Thank you so much!
I was able to download the notebook and retrieve your results!
Unfortunately, I was not able to run your code on my machine. Could you please help me debug this further? This would be tremendously helpful for my (and potentially others) future use.
Just some more information on my setup: I did pip install with a completely new Miniconda environment and put my API key .env file in the same directory as the conda environment and my Jupyter notebook. I also just updated the software yesterday. In that .env file, I only have my OpenAI API key entered (on tier-4 usage limit). Would it be helpful to provide any additional information? Thanks so much again for your help!

No thank you! Appreciate you working on this with us. It's odd that it's timing out. When the job failed to run, did it open an HTML page when that's a report? If you could attach that html, it would be very helpful in debugging.

Thanks!!
Unfortunately, I do not see any HTML file/page after running this code. Not sure if this is because there is no error message while running it: the attempt 1 failed message is not an error, and the system keeps generating this message if I do not interrupt it. (the most I tried is 10 minutes before interrupting the job). Would there be a way to generate the HTML file or any alternative ways to help the debugging?

Would this be helpful?
notebook (1).zip

Thanks!
Do you have any issues running other simpler questions?

I'd like to avoid asking you to keep running to get the entire exception message block if possible.

Thanks! Indeed, I stopped at around 10 minutes at most, and these (in this notebook) are the error messages I received.
So far, that is the only problem I encountered. I was even able to run the code with exp1 and exp2 having value 11. But when I have the 11 with all four exp variables, this type of error always occurs. I was mentioning the one-minute cutoff also because of this: running the code with two 11 values is the longest successful attempt I had, and it takes around 50 seconds.
Please let me know if it would be helpful to provide any additional information. Thanks again for your quick and involved investigations!

Hello,
Just wanted to circle back and see if the issue is solved. Please let me know if I can assist in any way. Thanks again!

The "time out" error indicates an issue with the rate limits on your Open AI account. It is not a problem with the survey code or scenarios; we are not having issues running the code. Are you able to further investigate your account?

Hello, Thanks for your reply!
After more investigations, I found this is not an API rate limit issue. One justification is that the problem arises when the number of simulations is 486. However, I was able to run three rounds of simulations (each has 256) separately but immediately after the previous one finished. These three successful attempts take 22 seconds in total, and they make 768 OpenAI API calls. To my knowledge, the shortest level of all OpenAI's API rate limits is minute.
I also found another potentially related issue: I tried your revised code and was able to wait for the system to finish reporting all timeout messages before finally producing an error. That took just over 2 minutes this time. As you can see, the error message is about the agents, but I was able to run my agents setup. Further, if I change the agents setup to the code below and still with 256 simulations, there is no error.
agents = [Agent(traits={"city": city, "job_post_title": title}, instruction = "You should evaluate job applicants based on all available informaton presented. The goal is to select the candidates of the best fit for the position and your firm culture",
                traits_presentation_template="""You are an HR manager in a mid-size service firm in {{city}} and are screening job applicants for your {{ job_post_title }} job position.""") for city in cities for title in titles]

for agent in agents:
    agent.agent_persona.render(primary_replacement=agent.traits)

I am attaching the notebook with the errors I produced. Please let me know if I could assist with more information. Again, thank you so much for your help!
edsl_bug_report_querries.zip

Thanks for sharing this!
I think you are referring to this line at the very end of the exceptions message, which is actually a bug in the generation of the exceptions report that should be rendered for your timeout errors:

The issue is that the exceptions report needs the agent info that you're piping in your question text in order to finish rendering. This is helpful that you found this bug and we're working on fixing it! (Tracking it here: https://github.com/expectedparrot/edsl/issues/910)
However, it unfortunately does not relate to your exception, which is still apparently just the timeout issue. The fact that you can run smaller batches in a row is I think consistent with a rate limit being imposed when you try to run too much at once.
Are you able to run my revised version of your code that creates a scenario for job_post_title in the question text instead of piping the agent trait (job_post_title instead of agent.job_post_title)? That should avoid the bug mentioned above and generate a full report.
Do you have a Coop account? I'd be happy to add credits for you to run everything using remote inference!

Specifying the TPM as you do manages the calls as if those are the limits, but you still want to check your actual limits with Open AI, as well as your token limits, which could also be the issue.
We'll also let you know as soon as we fix the bug so that we can get the full report with your original code.
Thanks for your patience!!

Thanks for your feedback!
Indeed, I tried your revised version, but it reports the same time-out error. So, I think it would be great to check it on the Coop. My Coop username is the same as my GH one. Thank you so much for readily adding some credits for me! A quick estimate says it would take 972 credits, which is indeed a lot if I want to run something even more ambitious!
coop.remote_inference_cost(q.by(scenarios).by(agents).by(model))

Regarding the limit I set in my notebook:
model.set_rate_limits(rpm=1000, tpm=1000000)

This is indeed still under my OpenAI API rate limit granted (the picture below shows my current OpenAI rate limit). Given that the error code has just over 500 simulations, I am still trying to understand if there could be other related issues besides the API rate limit. Any thoughts would be helpful. Thanks!

Just a follow-up: I also tried this limit, which is still valid under my OpenAI account, but the code still does not work and generates the same timeout error (on my local machine):
model = Model('gpt-4o-2024-08-06', temperature = 0.3, max_tokens=1000000)
model.set_rate_limits(rpm=10000, tpm=2000000)

Thanks! I am running it remotely myself and will follow up.
I have added credits to your Coop account as well.

Here are the results that I was able to run using remote inference:
https://www.expectedparrot.com/content/3fe2be4e-ec72-4f1d-86a8-882021ec0649

Thank you for your updates!
I have received the credit and will try it myself soon. Thanks again for this!
I also have some more updates from my further investigations that might be helpful. Essentially, I tried two alternative ways that work (or "work", will elaborate below) on my local machine.

The one that works:
As you may recall, I was able to run things smaller than 486 simulations (biggest was 256) locally. Following that logic, I designed for loops to iterate through most variables (e.g., job title, location). However, that was very inefficient computationally: one iteration has 64 simulations, and I have 24 iterations/loops (so in total, I was able to run 64*24 simulation, much bigger than 256). The whole process took about 10 minutes to finish. However, if I only run one iteration directly using the EDSL function run(), it only takes about 4 seconds.

Therefore, I am wondering, for people like me who has some weird local issues while running bigger simulations, or new API users suffering from rate limits a lot, would it be possible to introduce a way to run just a chunk of a question simulations by scenario or agent. For instance, I am not sure if it would be feasible to add something like:
results = q.by(scenarios.filter("exp1<=11")).by(agents.filter("city == New York City")).by(model).run()

which is similar to the way we can filter the results now:
results.filter("exp1 == 11 and exp2 == 11 and exp3 == 11 and exp4 == 11")

This could then be a great balance between efficiency and running big surveys successfully

The one that "works":
I likely found a related bug. I investigated that 486 simulation case and found I was able to run that one "successfully" and very quickly: it took around 30 seconds to run, and it generates values for all intended fields. The only syntax difference is that I added debug=True in the run() function:

result = q.by(scenarios).by(agents).by(model).run(debug=True)

However, the results are weird. First, the answers given seem to be random guesses and are very different from the one produced with loops (or without loop using just .run(). for smaller samples). Second, which makes it sound more like random guesses, I was not charged by OpenAI at all by running this one. The loop attempts (and all other direct runs with smaller samples) did charge me properly. Third, the answer comments generated are always "Debug Comment." According to the documentation, debug=True would only display debug messages, but it seems like it is doing more than that.

Please let me know if I can provide more information. Thanks!!

Thanks for all this helpful feedback!!

Yes, thanks for the suggestion! You can also try running the survey with subsets of the scenarios and then combine the results. Here is an example: https://www.expectedparrot.com/content/52bf0c66-3a5b-415b-b242-79793a13c7ea

The parameter debug=True should not be used. Its function is simulating results for debugging purposes. It doesn't do anything that would help you here.


Add support for always using latest

Add the use-latest argument to the action, which when set to true, will check the latest release for cargo-deny and download it if the current version in the container is not the same.
Might be considered to close #19

don't think this is a good idea, even as an option as we can and will introduce breakages in future cargo-deny versions and any users using this will just all the sudden get build failures or new warnings even though they are using cargo-deny-action@v1.
but let's discuss alternatives in #19


Replace FileDownloader with OkDownload seamlessly

Codecov Report

Merging #127 into master will decrease coverage by 83.3%.
The diff coverage is 0%.

@@            Coverage Diff            @@
##           master   #127       +/-   ##
=========================================
- Coverage    83.3%     0%   -83.31%
=========================================
  Files          63     31       -32
  Lines        3756    929     -2827
  Branches      609     75      -534
=========================================
- Hits         3129      0     -3129
- Misses        361    929      +568
+ Partials      266      0      -266

Impacted Files
Coverage Δ

...iulishuo/filedownloader/model/ConnectionModel.java
0% <0%> (ø)

...iulishuo/filedownloader/CompatListenerAdapter.java
0% <0%> (ø)

...liulishuo/filedownloader/FileDownloadListener.java
0% <0%> (ø)

...r/notification/FileDownloadNotificationHelper.java
0% <0%> (ø)

.../exception/FileDownloadNetworkPolicyException.java
0% <0%> (ø)

...liulishuo/filedownloader/CompatListenerAssist.java
0% <0%> (ø)

...liulishuo/filedownloader/FileDownloadQueueSet.java
0% <0%> (ø)

...o/filedownloader/util/FileDownloadSerialQueue.java
0% <0%> (ø)

.../liulishuo/filedownloader/FileDownloadMonitor.java
0% <0%> (ø)

.../liulishuo/filedownloader/status/StatusAssist.java
0% <0%> (ø)

... and 113 more

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 9127d49...56474d6. Read the comment docs.

@std829 Yes, you need to include it separately in the gradle.
com.liulishuo.okdownload:filedownloader:1.0.4

@rantianhua thanks I'll try that! I think at the time I tried that but it wasn't recognising version 1.0.4 for filedownloader


Support right-to-left layouts (not only the text direction inside the editor)

I recognized that in the editor code some things are layouted with "left" and "right" properties, (e.g. padding-left when there is padding-right with similar value used).
We should try to avoid these, to be able to support right-to-left layouts easily.
In a right-to-left layout e.g. a sidebar would appear at the other side than in a left-to-right layout.
Maybe the following articles could be helpful:
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_logical_properties_and_values/Basic_concepts_of_logical_properties_and_values
I don't have many more details about this. I came across it when setting up components and layouts for Platform.Bible, where we

try to omit Tailwind classes with directional values and replace them with logical ones
have created a small vite test app with a button that toggles text direction to be able to easily test components on their RTL awareness. Maybe something similar could be built into the scripture-editor codesandbox

@Sebastian-ubs thanks for this. The editor is not claiming RTL support yet. RTL support is on the roadmap for this quarter so this issue will be useful for moving that forward this quarter.


replacements cannot specify a version requirement

My project's Cargo.toml file
[package]
name = "sample"
version = "0.1.1"

[dependencies]
regex = "0.2.1"

[target.'cfg(target_os="android")'.dependencies]
jni = "0.3.1"

[replace]
"error-chain:0.5.0" = { default-features = false }

[lib]
name = "sample"
crate-type = ["staticlib", "cdylib"]

When I try to compile it, I get the following warnings:
warning: dependency (error-chain) specified without providing a local path, Git repository, or version to use. This will be considered an error in future versions

So, as suggested, I added version field to my replace.
[replace]
"error-chain:0.5.0" = { version = "0.5", default-features = false }

Now, I get an error
error: failed to parse manifest at `/Users/marek/projects/sample/cargo/Cargo.toml`

Caused by:
  replacements cannot specify a version requirement, but found one for `https://github.com/rust-lang/crates.io-index#error-chain:0.5.0`

So, either the first warning that I got was misleading, cause it suggested to use version property (via "or version to use"), or replacing version is broken

Ah yes the intention of [replace] is to switch sources of a crate, not for overriding turning off default features. In that sense I believe what you're trying to do here is unsupported.
In any case though the error message definitely could be better!


Missing trailing line separator when serializing TodoTxt

Only in version 1.4.0

Fixed in version 1.4.1


TTL longer than 7 days for anonymous user

Hi,
i tried to set TTL_OPTIONS with values larger 7 days but these are not shown in the dropdown.
we have disabled authentication
is there a way to update the anonymous plan?
Regards,
Fabian

The TTL limit for users is defined within their plan yeah. Specifically this setting for anonymous users:
https://github.com/onetimesecret/onetimesecret/blob/e43fe043b1943b0830b5f332747a9ecbe92fe51f/lib/onetime/plan.rb#L57
That value determines the absolute maximum expiration and is used by both the UI to limit the options shown and the backend to enforce the limit (for example via the API). If you're running via docker image this info won't help you though unless you'd want to build your own after making the code change.
It would make more sense I think for us to remove the per-plan limitation (which goes back to the beginning of the codebase) and treat that instead as a default. And then use the TTL_OPTIONS -- specifically the max value defined in it -- as the max limit.
Would that work in your case?

Hi delano,
we use docker, but to change plan.rb and build our own container is not an option for us atm. Your suggestion would work for us.

Great, I'll add this to the backlog and get this into an upcoming release.


ENYO-3626: enyo-dev: prepare 1.0.1 release with transpiling executed pre-publish

Alternative PR to: https://github.com/enyojs/enyo-dev/pull/46 with larger-scale changes that preserve ES6 source code but breaks direct npm installing from git url.

Updates version to 1.0.1
Removes babel-register at runtime
Move source from lib to src
ES6 source transpiles to lib at prepublish via npm run build
gitignore includes lib, npmignore includes src
Convert src/util-extra.js from ES6 to ES5 to ensure bin/upgrade.js still works correctly at install-time

Enyo-DCO-1.1-Signed-off-by: Jason Robitaille<EMAIL_ADDRESS>

👍 Removes babel-register at runtime looks good choice improving launching speed.

closing out as the jira associated with this is closed.


[3.x] Add warning when calling is_action_just_pressed() from _input()

Calling is_action_just_pressed() and is_action_just_released() from _input() is liable to cause duplicate detection bugs in user code.
Helps address #97526 .
Helps address #80158 .
Notes

This warning prompts users to query event.is_action_pressed() (and released) instead of the just_pressed() methods from within _input().
This prevents the possibility of is_action_just_pressed() reporting multiple trues when multiple calls to _input() occur within the same frame or physics tick.
This may fire on some existing projects (in a non-spamming fashion) but likely is showing a bug that users didn't know existed in their project.
The guard is simple single threaded, as the parsing is always done from main thread, so should be no need for mutex.
Also applicable in 4.x (will need separate PR in case differences there).

I figured it was pretty small to add in like a lock guard, and as you say it prevents nasty bugs from later early returns by other contributors who might not notice a lock. I think we've been gradually moving most manual locking to using lock guards for this reason.

Thanks!


feat: log rotation

This Pr adds log rotation as the default log driver does not include it.
This is nice when your server goes into a crash loop and creates lots of logs in the process.
The values are set very high so that under normal circumstances you should not be affected by the rotation, it is meant more as a backstop in case somethnig goes very wrong
further reference: https://docs.docker.com/config/containers/logging/configure/

Hey @Gornoka
Thanks for the contribution, i very much like the idea, i even have this already implemented in my own setup. Im not sure if this still applies, because i did it way back from the old days of docker 19.03 and before, but dont we need a config file that sets the general log-driver to json with auto-log-rotate, or was this just to enable it be default for all? Im not sure anymore and my old bookmarks links arent existing anymore, so i cant research this up again.

Hey @Gornoka Thanks for the contribution, i very much like the idea, i even have this already implemented in my own setup. Im not sure if this still applies, because i did it way back from the old days of docker 19.03 and before, but dont we need a config file that sets the general log-driver to json with auto-log-rotate, or was this just to enable it be default for all? Im not sure anymore and my old bookmarks links arent existing anymore, so i cant research this up again.

IIRC the global config option only applies if there is no config specified in the individual compose file. Therefore we would not have to alter the global logging config.
This is the relevant article for global logging settings and the hint to use the local logger instead of the json logger: https://docs.docker.com/config/containers/logging/configure/

Thanks for the contribution, but next time please do a PR against develop.

sorry my old fork did not have that branch yet


New version: MUMPS_seq_jll v500.500.102+0

Autogenerated JLL package registration

Registering JLL package MUMPS_seq_jll.jl
Repository: https://github.com/JuliaBinaryWrappers/MUMPS_seq_jll.jl
Version: v500.500.102+0
Commit: 65f88231cb3cfb2b8e1d5eb228b26333332bb702
Revision on Yggdrasil: https://github.com/JuliaPackaging/Yggdrasil/commit/f6cab3f2dbb293c9a1ed531f8f997011d0069222
Created by: @amontoison

@staticfloat As an expert of LBT, do you have an idea of what is the problem with it here?

The issue is that MUMPS_seq_jll v500.500.102 requires Julia v1.9+, but AutoMerge here is running with Julia v1.8.5, so it doesn't match the right LBT version.  @DilumAluthge should there be some kind of notice here from AutoMerge that it's trying to install an incompatible version?

It's probably for the same reason that a PR for a new version of PROPACK_jll was never opened here. :thinking:

No. that's a totally separate issue; that's a problem with PROPACK's jll that I don't fully understand.

should there be some kind of notice here from AutoMerge that it's trying to install an incompatible version?

PkgEval has a nifty feature where they parse the logs and try to figure out the reason for a failure. So we could e.g. parse the output from the "Pkg.add" guideline, and categorize it as e.g.

"Julia version incompatible with latest stable Julia release"
"Other unsatisfiable requirements"
... [other categories] ...
"Other"

Shouldn't we just detect that there's no overlap between the declared compat bounds on Julia and the currently-running Julia?

Oh yeah that's easier

@DilumAluthge
Is it possible to manually merge this PR with #80576 and #80622.
The issue is related to LBT for the three PRs.

@amontoison @staticfloat Looks like there are merge conflicts here. Probably we should close this PR and then trigger Yggdrasil/@jlbuild to open a new PR.

We can close this PR.
#84583 fixed this issue.


feat(metrics): add url_rewrite and file_type fields to metrics sent to NR

Description
This PR adds the following fields to metrics sent to NR by the Edge Function that runs whenever a JSON Schema file is downloaded:

url_rewrite: The URL of final destination, where the JSON Schema file is served from. I.e. https://raw.githubusercontent.com/asyncapi/spec-json-schemas/master/definitions/2.3.0/asyncapi.json
file_type: Can be either schema or definition, depending on what is being downloaded.

This helps creating better dashboards by faceting by this new data.

@derberg @fmvilas would you mind 👀 this and approve if 👍 ? Thanks!

/rtm


Create a table component

component should be pure , i.e no logic is maintained here , component takes props and displays UI.
accepts two props data and columns
columns is for headers
data is array of Objects where key is the header and value is value to given for that header.
support only plain text values as of now, ignore images and capsules.

Example
https://www.figma.com/file/oAZEkXsqPBzzsAimeaRTB7/Tap?node-id=252%3A2

Add support for custom components like images, links

Ability to add list is done.
remaining todos
Other components like image , links
filter, sorting


This extension uses an older model, instead of ChatGP's model

model: "text-davinci-002-render",
https://github.com/shobrook/stackoverflow.gg/blob/master/src/background.js#L144
That's not ChatGPT's model.
Adding the "ChatGPT" label on this extension is false advertising.
Not that it could be accessing ChatGPT, as that has no API yet...

Are you sure about that? Load up ChatGPT in your browsers developer tools and look at the model names that are represented in the JSON payloads.
For non-Plus (unpaid) accounts, they are using text-davinci-002-render, and for the Plus (paid) accounts, they offer text-davinci-002-render-paid (default) and text-davinci-002-render-sha (optional alpha model optimized for speed).

There are some additional nuances, but the raw model for default ChatGPT is text-davinci-002-render.
A few resources that helped me understand the nuances:

As of February 14th, the default model for ChatGPT Plus subscribers is now text-davinci-002-render-sha (previously Turbo) and text-davinci-002-render has been renamed to Legacy.


S2A handshaker client, part 2

This PR is a follow-up to #21. It contains the implementation of the methods of the s2a_handshaker_client that are responsible for calling the S2A handshaker service.

This PR is ready for review, once PR #21 is merged. The implementation and the tests are nearly identical to the ALTS counterparts, so it should be pretty easy to review.

This PR is ready for review!

Sorry for the delay Matt.
My major concern is I am not convinced about the correctness of some changes in this PR without seeing more comprehensive tests:
1: Apolcyn@ made a series of changes to ALTS code to make it resistant against a large number of concurrent connection requests (https://github.com/grpc/grpc/pull/20722, https://github.com/grpc/grpc/pull/21189, https://github.com/grpc/grpc/pull/20929). In this PR, I noticed a similar but a little different changes are made (e.g., I did not see the use of connection queues) so not sure if the changes indeed work without doing more integration tests (similar to alts_concurrent_connectivity_test.cc). Basically, we did not verify any interaction to the handshake server.
2: Do you think it is necessary to do some code refactoring between ALTS and S2A? If the long term plan is to move the S2A code out of gRPC repo, it may not be necessary though.

Thanks for the comments @yihuazhang! I really appreciate them. I've addressed them all in the most recent commit, or responded to them directly.
Below, I will respond to your 2 comments above. (Some of this is repetition from our offline discussion.)

As we discussed offline, our team has agreed that the S2A service will be responsible for capping the number of concurrent connection requests. As a consequence, the global queue is not necessary. (There is an email chain with apolcyn@, on which you are cc-ed, that verifies what portions of code will be removed from ALTS along with the global queue. I've removed them in the S2A client already.)

As for the additional tests, I propose the following: when two more PR's are merged (this one and one other yet to be posted), there will be a complete TSI handshaker and handshaker client implementation. Once this is done, I will post a PR that contains the following additional tests:

The S2A version of the fake handshaker service, with a cap on the number of concurrent connection requests.
The S2A version of the tests in alts_tsi_handshaker_test.cc (i.e. the ones that use the fake handshaker service to mock a handshake).
The S2A version of the alts_concurrent_connectivity_test.cc.

How does that plan look to you?

What code refactoring are you referring to? Once the S2A client is ultimately merged somewhere, I will do some reorganization of the ALTS code, namely putting some stuff in a shared library under src/core/tsi. Is this what you are referring to?

In terms of the long term plan, if we decide to move the S2A client out of gRPC, there will also be refactoring to avoid the use of gRPC-internal API's.

The plan SGTM. Regarding refactoring since it seems S2A will not be placed in OSS gRPC repo, let's do not do any refactoring regarding code sharing between ALTS and S2A.

Per our offline discussion, we will create an S2A-dedicated copy of the gsec_aead_crypter, to avoid any refactoring of the ALTS code.
Granted the plan, is this PR good to go? Or did you want to take another look at it?

Thanks for the changes Matt. My major concern is that since we do not want to place the code inside gRPC repo (either a short or long term), I think the comments in the code should not or at least minimize its reference to ALTS. Please add more comments to some of the API's (MaybeCompleteTsiNext) to make it easier to understand in future. You can find some conversations I had with Alex in https://github.com/grpc/grpc/pull/20929/files about it.

Thanks for the comments @yihuazhang! I've responded to them all. In particular, I've removed all references to ALTS and added more comments (e.g. to the MaybeCompleteTsiNext API).

Thanks for all the comments @yihuazhang! I've implemented the changes we discussed in the most recent commit.

Thanks for the review @yihuazhang!
Squashing and merging now.