Listener isolation or cascading behavior

When talking about Listener acceptance and merging behavior as part of #2288, we discovered that there was a particularly important part of the spec that we had not clarified enough, and that this has created a behavior variance between implementations.
I (@youngnick) summarized this as follows:

That concept is important because, for better or for worse, it has always been intended that the traffic-matching between Listeners and Routes is a two stage process. First you match a Listener, then you look for matching routes. In the case that there's a wildcard hostname, it was definitely not intended that a request could match both (for example, the cafe.example.com and *.example.com Listeners.) That is, having different values at all for hostname has been intended to make the Listeners distinct and unmergeable. We certainly have not done enough to explain that this is the intention, and I'm sorry for that.

That is, it was the original intention in the spec that, if there is a precise hostname match in one Listener, and a wildcard match in another, that traffic that matches the precise hostname will arrive only at Routes bound to that Listener.
Another way to put this is that if a precise hostname match is present, then a wildcard match should never also match that precise hostname.
Because we were not clear about this in the spec originally, many implementations have implemented their rules such that requests that match a precise hostname may, if there are no matching Routes for the request, match Routes attached to the wildcard hostname.
To use an example, here is a Gateway that @pleshakov supplied in #2288.
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: gateway
spec:
  gatewayClassName: nginx
  listeners:
  - name: example
    port: 80
    protocol: HTTP
    hostname: "*.example.com"
  - name: cafe-http
    port: 80
    protocol: HTTP
    hostname: "cafe.example.com"

And here are some Routes that illustrate the config that may result in cascading behavior. I've left out hostnames on the HTTPRoutes so that only the Listener hostname is relevant.
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: coffee
spec:
  parentRefs:
  - name: gateway
    sectionName: cafe-http
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    backendRefs:
    - name: backend
      port: 3000
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: tea
spec:
  parentRefs:
  - name: gateway
    sectionName: example
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /tea
    backendRefs:
    - name: backend
      port: 3000

In this example, cafe.example.com has one HTTPRoute attached, /coffee, and *.example.com has one HTTPRoute attached, /tea.
The original intent of the spec is that the only valid request using cafe.example.com is http://cafe.example.com/coffee. Any request that does not match the set of Routes attached to the cafe-http Listener should be 404ed.
However, many implementations allow the request to cascade between Listeners, which means that request to either http://cafe.example.com/coffee or http://cafe.example.com/tea will succeed.
This issue is to discuss how to proceed here.
My personal preference is to tighten up the language here, and make the originally-implied behavior explicit and compulsory, with conformance tests to back it up. I'm aware that this will be painful for a number of implementations, but I really think that this is better in the long run. This is a very subtle difference that will be very difficult to explain to end users, and I think that it will significantly decrease portability to have this be optional in an extended feature.

This is a very subtle difference that will be very difficult to explain to end users, and I think that it will significantly decrease portability to have this be optional in an extended feature.

I agree that this is subtle, and fairly difficult to explain to users.

My personal preference is to tighten up the language here, and make the originally-implied behavior explicit and compulsory, with conformance tests to back it up. I'm aware that this will be painful for a number of implementations, but I really think that this is better in the long run.

While I can see the sense in it, it remains unclear to me if this would be "better in the long run". If we have a number of implementations that are responsible for building this API, that have been working on conformance and generally just about ready for GA and last minute we make this change: the implications could be similar to a sudden, just-before-release backwards incompatible change and could significantly impact the trust we depend on from our community for our project to succeed.
It seems clear to me that we will need to discuss the options available to us at length, verify just how impactful this is (or isn't) for implementations, and find the best balance (and in some kind of hurry, with GA looming).
I think anyone with a stake in this should chime in with their thoughts and considerations, as we need to hear it all.

Met with @shaneutt and @youngnick this morning, and we agreed on the following approach here:

Add a new GatewayListenerIsolation Extended feature (and conformance tests) that will describe the ideal state that we'll want everyone to work towards supporting
Some new features like Client Certification validation (https://github.com/kubernetes-sigs/gateway-api/pull/2273) are likely going to require support for Listener Isolation
We don’t want to leave anyone behind, but want to encourage everyone to work towards support for Listener Isolation so that we can graduate this to a Core feature in the future

The example in the description makes a lot of sense. As well as the proposed solution.
However, there is an edgier edge case that I find a bit troubling -- it is the case when hostnames are defined in both listeners and HTTPRoute. I also found that implementations (I tried 4) didn't enforce listener isolation for this case.
I'd like to double check how to handle that case below. Hopefully, we can also define it in a conformance test.
The example below iteratively builds upon a simple Gateway.
(1)
Gateway:

listener-1 with empty hostname with HTTPRoute (hostname and one path) a.b.example.com/listener-1 that references the listener in its parent ref.

Expectation:
curl http://a.b.example.com/listener-1 -> 200

Now let's add another listener to the Gateway:
(2)
Gateway:

listener-1 empty hostname with HTTPRoute a.b.example.com/listener-1 that references the listener in its parent ref.
listener-2 hostname=*.example.com

Must listener-2 now prevent routing requests to listener-1?
curl http://a.b.example.com/listener-1 -> ?

Now let's attach an HTTPRoute to listener 2:
(3)
Gateway:

listener-1 with empty hostname with HTTPRoute a.b.example.com/listener-1 that references the listener in its parent ref.
listener-2 hostname=*.example.com with HTTPRoute a.b.example.com/listener-2 that references the listener in its parent ref.

I believe listener isolation rules must work like below here:
curl http://a.b.example.com/listener-1 -> 404
curl http://a.b.example.com/listener-2 -> 200

Now let's attach another listener:
(4)
Gateway:

listener-1 with empty hostname with HTTPRoute a.b.example.com/listener-1 that references the listener in its parent ref.
listener-2 hostname=*.example.com with HTTPRoute a.b.example.com/listener-2 that references the listener in its parent ref.
listener-3 hostname=*.b.example.com

Must listener-3 now prevent routing requests to both listener-1 and listener-2?
curl http://a.b.example.com/listener-1 -> ?
curl http://a.b.example.com/listener-2 -> ?

Now let's attach an HTTPRoute to listener-3:
(5)
Gateway:

listener-1 with empty hostname with HTTPRoute a.b.example.com/listener-1 that references the listener in its pararent ref.
listener-2 hostname=*.example.com with HTTPRoute a.b.example.com/listener-2 that references the listener in its pararent ref.
listener-3 hostname=*.b.example.com with HTTPRoute a.b.example.com/listener-3 that references the listener in its pararent ref.

I believe listener isolation rules must work like below here:
curl http://a.b.example.com/listener-1 -> 404
curl http://a.b.example.com/listener-2 -> 404
curl http://a.b.example.com/listener-3 -> 200

Final Thoughts

I ran this example on a few implementations (4 in total) and I didn't see the isolation in most of them (see https://github.com/kubernetes-sigs/gateway-api/pull/2288#discussion_r1330776179)
In my view, the fact that the hostname field in a listener can include another listener (*.example.com includes *.a.example.com) makes isolation harder to implement.
It might also be confusing for users - because a new more specific listener in a Gateway can suddenly lead to 404 for HTTPRoutes attached to a less specific listener.

/assign

@pleshakov thanks for the detailed write-up.
Again, we obviously haven't explained this well enough, but the intent of the hostname field in HTTPRoute is for that to be a determinant of which Listener a HTTPRoute can attach to - that hostname is really only relevant for routing in the event that the Listener hostname field is empty or wildcard.
One thing that's implied but not explicit in the hostname docs is that the * in a hostname is greedy:
	// Hostnames that are prefixed with a wildcard label (`*.`) are interpreted
	// as a suffix match. That means that a match for `*.example.com` would match
	// both `test.example.com`, and `foo.test.example.com`, but not `example.com`.

We haven't specifically said what to do when there are overlapping wildcards - but in either case, the idea is that only one of the wildcards can be matched if a hostname matches both.
We need to tighten this up as well, and have two options, either "most dots to the right of the wildcard wins" (that is, that a more specific wildcard beats a less-specific one), or that less specific wildcard wins ("least dots to the right of the wildcard wins"). I probably prefer the first, personally, which makes your deductions correct.
I don't think it's too big a deal that implementations don't do this yet - as we've never been precise or had conformance tests for this use case which is, as you say, pretty edgy.
I'm already working on another round of language updates to the Listener docs, I will include this in my todo list.
Comments on if we should have more specific (my preferred option) or less specific wildcards win welcomed.
I should also note that the significant security implications for TLS routing of cascading Listeners do mean that it's very unlikely that we will revisit the decision to move towards requiring isolated Listeners long-term, regardless of these edge-case issues.

With #2465 merged, we've addressed the most critical portion of this. Leaving this issue open to track any additional follow ups like conformance tests, but it is no longer a release blocker.

I'd like to volunteer to write a conformance test for this.
@robscott based on your last comments, sounds like no new issue is needed to be created. Would it be possible to reassign this one to me?

That's great, thanks @pleshakov!
/assign @pleshakov

One thing we may want to do as part of this effort is add to the changes from https://github.com/kubernetes-sigs/gateway-api/pull/2465 and add some documentation on the Route hostname spec so users are aware of the fact that all of the requested hostnames in a route may not actually match up with the Listener they are attached to (due to isolation) and may not result in actual routing rules, per the points made here: https://github.com/kubernetes-sigs/gateway-api/issues/2416#issuecomment-1736803034
particularly: the intent of the hostname field in HTTPRoute is for that to be a determinant of which Listener a HTTPRoute can attach to - that hostname is really only relevant for routing in the event that the Listener hostname field is empty or wildcard.

Is this issue completed now that the conformance tests pass/

I think we can probably close this out - we still don't have coverage for HTTPS listener isolation, but that's tracked in https://github.com/kubernetes-sigs/gateway-api/issues/2803.


Day 432

Good morning! Here's your coding interview problem for today.
This problem was asked by Google.
Design a system to crawl and copy all of Wikipedia using a distributed network of machines.
More specifically, suppose your server has access to a set of client machines. Your client machines can execute code you have written to access Wikipedia pages, download and parse their data, and write the results to a database.
Some questions you may want to consider as part of your solution are:
How will you reach as many pages as possible?
How can you keep track of pages that have already been visited?
How will you deal with your client machines being blacklisted?
How can you update your database when Wikipedia pages are added or updated?

Identical to Day 354: https://github.com/vaskoz/dailycodingproblem-go/issues/703


error when applying patch is some edge case

Issue
We randomly discovered an edge case where the following sequence trigger an error:
$ kubectl apply -f manifest-v1.txt
cronjob.batch/test-cron created

$ kubectl apply -f manifest-v2.txt
cronjob.batch/test-cron configured

$ kubectl apply -f manifest-v1.txt
warning: error calculating patch from openapi spec: The order in patch list:
[map[name:b] map[name:b] map[name:c]]
 doesn't match $setElementOrder list:
[map[name:b] map[name:c] map[name:b]]
...

Note: manifest-v1.txt and manifest-v2.txt are both legal objects. In manifest-v1.txt, the .spec.jobTemplate.spec.template.spec.imagePullSecrets contains dupes but this is considered as valid by kubernetes.
Environment
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.0", GitCommit:"e8462b5b5dc2584fdcd18e6bcfe9f1e4d970a529", GitTreeState:"clean", BuildDate:"2019-06-19T16:40:16Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.9", GitCommit:"e09f5c40b55c91f681a46ee17f9bc447eeacee57", GitTreeState:"clean", BuildDate:"2019-05-27T15:58:45Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}

How to reproduce
kubectl apply -f manifest-v1.txt
kubectl apply -f manifest-v2.txt
kubectl apply -f manifest-v1.txt

manifest-v1.txt
manifest-v2.txt

/sig cli
/area kubectl
/kind bug
/priority P2
Please note that the version support window is violated in this example (client version 1.15 -> server 1.12), but we'll mark this as a bug anyways. Kubernetes guarantees a +/- 1 version skew. So with the 1.12 server, only kubectl versions 1.11, 1.12, and 1.13 are guaranteed to work. Please reproduce this problem with a supported kubectl version.

Thanks @seans3! We initially discover the issue using v1.12 but opened the issue with v1.15 as I tested it afterward.
I've updated the issue report.

This is happening because the strategicpatch code used by client side apply can't correctly create a patch containing a slice of maps with duplicate merge key values.
The error messaging could be improved though to make this less confusing. However with the push to move apply to the server I'm uncertain of how receptive sig-apimachinery would be to changes to strategicpatch which are intended to support improvement to client side apply in kubectl.
@seans thoughts?

contains dupes but this is considered as valid by kubernetes.

I would say is a validation bug and duplicate imagePullSecrets should not be permitted. That said this is a core/v1 type we're talking about so fixing that would probably not be worth the level of effort. 😄

/cc @apelisse
/cc @jennybuckley
Who have context on apply/openapi, and who are working on server-side apply


Question regarding reporting on instruction-address-misaligned exceptions

Volume I (User-Level ISA) states the following regarding the “instruction-address-misaligned exception”:
https://github.com/riscv/riscv-isa-manual/blob/2713791c03c8943656dc6f71a39c5dd0916f5260/src/rv32.tex#L153-L158
I am specifically interested in the interpretation of the following sentence from this paragraph:

This exception is reported on the branch or jump instruction, not on the target instruction.

What does “reported on” mean in this context?
This requirement was added with commit db0b5ca0c2269ea494a2e9cf442b14d3039b4ce4, unfortunately without further explanation (CC: @kasanovic).

Taking Volume II (Privileged Architecture) into account: Does this mean that mtval should be set to the address of the branch or jump instruction? Because if so, this is somewhat contradictory to the following statement from the privileged architecture:
https://github.com/riscv/riscv-isa-manual/blob/b6480da0db0c428a8ab29b65cae693041cd3e874/src/machine.tex#L2213-L2216
P.S.: Volume I uses the spelling “instruction-address” and „instruction-address-misaligned exception” while Volume II uses “instruction address” as well as “instruction address misaligned exception” which is a minor inconsistency.

"reported on" means that the value recorded in epc is the address of the branch or jump, rather than the address of the target.


Testing travis.

Codecov Report

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

@@           Coverage Diff           @@
##           master      #71   +/-   ##
=======================================
  Coverage   77.12%   77.12%
=======================================
  Files          45       45
  Lines        2619     2619
=======================================
  Hits         2020     2020
  Misses        599      599

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 7461fd7...6ee4802. Read the comment docs.


Fix spaceship launcher client login for push certificate

🔑
Checklist

[ ] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[ x] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary.

Motivation and Context

I found what I believe is a bug when using Spaceship::Launcher and trying to create push certificates for an app. What I've found is that the call to launcher.certificate.development_push.create! would throw a RuntimeError.
After inspecting the code I realized this is because the Spaceship::Certificate.create! method is  checking for the app in the portal, to do this it calls out to the Spaceship::App portal client. Because this method does not pass the client along, and the default Spaceship::Portal.client is nil because I'm using Spaceship::Launcher, I receive a RuntimeError telling me to log in. This would only affect Push Certificates as they require the app to exist.

Related Github Issue
I didn't find any open issues and am going to forego opening one myself as I believe the fix is pretty small (and more descriptive of the issue)

How I tested my changes
I tested my changes by patching my local fastlane gem with the fix. Unfortunately, I tried to add a spec in launcher_spec to describe what I was seeing but I'm running into some issues with WebMock. Rspec will fail for this PR currently and am looking for help to resolve this testing issue.
What I believe is happening is the Spaceship::Client#request method is encoding the body (headers, params) of POST requests. This doesn't seem to match the stubbed request bodies. I'm unsure why this doesn't affect any other POST request specs.
Description

I've added a call to with_client to the create! method. This passes along the client object from the Spaceship::Portal::Certificate.
Another approach I tried was to set the Spaceship::Portal.client inside the Spaceship::Launcher initializer, but this is incorrect because it'd break the ability to have two spaceships running side by side.

I signed it!

Oh, tests are failing, can you fix them? Thanks 👍

Hey @KrauseFx, I was having trouble with properly mocking the certificate signing request. I have it written to check to make sure an error is not thrown when using the Portal stubbed certificate signing request, but it seems there is a difference in how WebMock and the Spaceship::Client.request encodes the HTTP body. I believe this is causing the mismatch described in the failing spec (its the test I've added).
expected no Exception, got #<WebMock::NetConnectNotAllowedError: Real HTTP connections are disabled. Unregistered request: POST ...esources/controllers/login_cntrl.js")

I was wondering if anyone on the fastlane team could suggest the proper mechanism to stub out the certificate request? I'll keep reading through to see if other specs are doing this better than my current approach.
Thanks for the approval!

Nevermind! There's a good example in the portal/certificate_spec that I somehow overlooked in my initial attempt.

LGTM


circle-ci auto integration

我 p r 我 自 己

circle-ci these days is becoming more modern and functional, I like it @ice1000


[bug] minor dark-mode issue in the playground.

the strictness drop-down menu doesn't change color according to dark mode.
screenshot for reference-

It requires some css styling. https://stackoverflow.com/questions/10185762/how-to-customize-a-select-element-through-css-to-achieve-this-dark-style
Contribution is welcome!


feat(material-experimental/menubar): add material menubar skeleton and dev-app

Add the material-experimental/menubar component skeletons and the accompanying dev app
and its configuration.

New rule: Skeleton PRs only 😆


Duniverse: Avoid failure when ocaml_compilers field is invalid

This should fix the issue encountered in https://github.com/realworldocaml/book/pull/3302 if it happens again in the future.
cc @avsm
Unknown errors are slightly tricky, should we put an error message web-ui per-commit pages to let the users know what happened, if that's even possible? @talex5

LGTM; I'm modifying duniverse to work with both x.y versions (which defaults to the latest patch version) and x.y.z (for a specific one). So this check is good.

Unit-tests are failing.

@kit-ty-kate : is this PR still needed? If so, it should be rebased. If not, let's close it.

Please re-open if this is still needed.


Show keybindings in refactor menu

Repo

Create a keybinding for extract constant:

	{
		"key": "shift+ctrl+e",
		"command": "editor.action.refactor",
		"args": {
			"kind": "refactor.extract.constant",
			"preferred": true
		}
	}

Open a js file:
const a = 1 + 2;

Select 1 + 2 and click on lightbulb

Feature Request
Show the keybinding (shift+ctrl+e) for the extract to constant refactoring the lightbulb menu

For verifying this:

Make sure that the most specific keybinding is shown if multiple could be used
Also check that source actions (like organize imports) have keybindings shown in the source menu


HTTP API

At the moment, concat exposes an HTTP api from the mcnode for pinging other nodes, publishing statements and retrieving statements from the local index.
Is this repo the right place to develop an API client?  Ideally it would target both the js and go implementations.  We could also spin that off into a separate "front end" repo, and keep this one focused on the p2p interactions.

Let's keep the js code together for now


fix: update readme

Update links in README.md

I did PR to main but if needed we can merge first into dev.

I've merged xavi's Pr. closing this one


Database migrations are broken in dev

Problem Description
New migrations on https://bookkeeper-blue-dev.herokuapp.com are not applied automatically, since migration cannot be applied. When trying to apply it, we get the following output:
VERSION=20221122114920 bin/rails db:migrate:up
I, [2022-12-13T17:10:05.027493 #8]  INFO -- : Migrating to ChangeHolderInItemToReferenceToUser<PHONE_NUMBER>4920)
==<PHONE_NUMBER>4920 ChangeHolderInItemToReferenceToUser: migrating ==============
-- remove_column(:items, :holder, :string)
   -> 0.0019s
-- add_reference(:items, :user, {:null=>true, :foreign_key=>true})
rails aborted!
StandardError: An error has occurred, this and all later migrations canceled:

PG::DuplicateObject: ERROR:  constraint "fk_rails_d4b6334db2" for relation "items" already exists
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:48:in `exec'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:48:in `block (2 levels) in execute'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/share_lock.rb:187:in `yield_shares'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/dependencies/interlock.rb:41:in `permit_concurrent_loads'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:47:in `block in execute'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract_adapter.rb:765:in `block in log'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/notifications/instrumenter.rb:24:in `instrument'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract_adapter.rb:756:in `log'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:46:in `execute'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/schema_statements.rb:1093:in `add_foreign_key'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/schema_definitions.rb:790:in `foreign_key'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/schema_definitions.rb:184:in `add_to'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/schema_statements.rb:989:in `add_reference'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:932:in `block in method_missing'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:900:in `block in say_with_time'
/app/vendor/ruby-2.7.4/lib/ruby/2.7.0/benchmark.rb:293:in `measure'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:900:in `say_with_time'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:921:in `method_missing'
/app/db/migrate/20221122114920_change_holder_in_item_to_reference_to_user.rb:4:in `change'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:870:in `exec_migration'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:854:in `block (2 levels) in migrate'
/app/vendor/ruby-2.7.4/lib/ruby/2.7.0/benchmark.rb:293:in `measure'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:853:in `block in migrate'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/connection_pool.rb:215:in `with_connection'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:852:in `migrate'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1046:in `migrate'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1360:in `block in execute_migration_in_transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/transaction.rb:319:in `block in within_new_transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/transaction.rb:317:in `within_new_transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/database_statements.rb:316:in `transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/transactions.rb:209:in `transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1411:in `ddl_transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1359:in `execute_migration_in_transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1321:in `run_without_lock'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1274:in `block in run'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1432:in `block in with_advisory_lock'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/connection_pool.rb:215:in `with_connection'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1447:in `with_advisory_lock_connection'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1428:in `with_advisory_lock'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1274:in `run'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1131:in `run'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/railties/databases.rake:195:in `block (3 levels) in <main>'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:281:in `block in execute'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:281:in `each'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:281:in `execute'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:219:in `block in invoke_with_call_chain'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:199:in `synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:199:in `invoke_with_call_chain'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:188:in `invoke'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:160:in `invoke_task'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:116:in `block (2 levels) in top_level'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:116:in `each'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:116:in `block in top_level'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:125:in `run_with_threads'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:110:in `top_level'
/app/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4/lib/rails/commands/rake/rake_command.rb:24:in `block (2 levels) in perform'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:186:in `standard_exception_handling'
/app/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4/lib/rails/commands/rake/rake_command.rb:24:in `block in perform'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/rake_module.rb:59:in `with_application'
/app/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4/lib/rails/commands/rake/rake_command.rb:18:in `perform'
/app/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4/lib/rails/command.rb:51:in `invoke'
/app/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4/lib/rails/commands.rb:18:in `<main>'
/app/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/app/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'

Caused by:
ActiveRecord::StatementInvalid: PG::DuplicateObject: ERROR:  constraint "fk_rails_d4b6334db2" for relation "items" already exists
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:48:in `exec'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:48:in `block (2 levels) in execute'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/share_lock.rb:187:in `yield_shares'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/dependencies/interlock.rb:41:in `permit_concurrent_loads'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:47:in `block in execute'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract_adapter.rb:765:in `block in log'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/notifications/instrumenter.rb:24:in `instrument'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract_adapter.rb:756:in `log'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:46:in `execute'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/schema_statements.rb:1093:in `add_foreign_key'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/schema_definitions.rb:790:in `foreign_key'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/schema_definitions.rb:184:in `add_to'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/schema_statements.rb:989:in `add_reference'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:932:in `block in method_missing'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:900:in `block in say_with_time'
/app/vendor/ruby-2.7.4/lib/ruby/2.7.0/benchmark.rb:293:in `measure'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:900:in `say_with_time'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:921:in `method_missing'
/app/db/migrate/20221122114920_change_holder_in_item_to_reference_to_user.rb:4:in `change'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:870:in `exec_migration'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:854:in `block (2 levels) in migrate'
/app/vendor/ruby-2.7.4/lib/ruby/2.7.0/benchmark.rb:293:in `measure'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:853:in `block in migrate'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/connection_pool.rb:215:in `with_connection'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:852:in `migrate'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1046:in `migrate'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1360:in `block in execute_migration_in_transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/transaction.rb:319:in `block in within_new_transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/transaction.rb:317:in `within_new_transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/database_statements.rb:316:in `transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/transactions.rb:209:in `transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1411:in `ddl_transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1359:in `execute_migration_in_transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1321:in `run_without_lock'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1274:in `block in run'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1432:in `block in with_advisory_lock'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/connection_pool.rb:215:in `with_connection'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1447:in `with_advisory_lock_connection'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1428:in `with_advisory_lock'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1274:in `run'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1131:in `run'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/railties/databases.rake:195:in `block (3 levels) in <main>'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:281:in `block in execute'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:281:in `each'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:281:in `execute'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:219:in `block in invoke_with_call_chain'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:199:in `synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:199:in `invoke_with_call_chain'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:188:in `invoke'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:160:in `invoke_task'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:116:in `block (2 levels) in top_level'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:116:in `each'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:116:in `block in top_level'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:125:in `run_with_threads'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:110:in `top_level'
/app/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4/lib/rails/commands/rake/rake_command.rb:24:in `block (2 levels) in perform'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:186:in `standard_exception_handling'
/app/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4/lib/rails/commands/rake/rake_command.rb:24:in `block in perform'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/rake_module.rb:59:in `with_application'
/app/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4/lib/rails/commands/rake/rake_command.rb:18:in `perform'
/app/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4/lib/rails/command.rb:51:in `invoke'
/app/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4/lib/rails/commands.rb:18:in `<main>'
/app/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/app/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'

Caused by:
PG::DuplicateObject: ERROR:  constraint "fk_rails_d4b6334db2" for relation "items" already exists
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:48:in `exec'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:48:in `block (2 levels) in execute'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/share_lock.rb:187:in `yield_shares'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/dependencies/interlock.rb:41:in `permit_concurrent_loads'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:47:in `block in execute'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract_adapter.rb:765:in `block in log'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/notifications/instrumenter.rb:24:in `instrument'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract_adapter.rb:756:in `log'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:46:in `execute'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/schema_statements.rb:1093:in `add_foreign_key'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/schema_definitions.rb:790:in `foreign_key'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/schema_definitions.rb:184:in `add_to'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/schema_statements.rb:989:in `add_reference'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:932:in `block in method_missing'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:900:in `block in say_with_time'
/app/vendor/ruby-2.7.4/lib/ruby/2.7.0/benchmark.rb:293:in `measure'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:900:in `say_with_time'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:921:in `method_missing'
/app/db/migrate/20221122114920_change_holder_in_item_to_reference_to_user.rb:4:in `change'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:870:in `exec_migration'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:854:in `block (2 levels) in migrate'
/app/vendor/ruby-2.7.4/lib/ruby/2.7.0/benchmark.rb:293:in `measure'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:853:in `block in migrate'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/connection_pool.rb:215:in `with_connection'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:852:in `migrate'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1046:in `migrate'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1360:in `block in execute_migration_in_transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/transaction.rb:319:in `block in within_new_transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.4/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/transaction.rb:317:in `within_new_transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/database_statements.rb:316:in `transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/transactions.rb:209:in `transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1411:in `ddl_transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1359:in `execute_migration_in_transaction'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1321:in `run_without_lock'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1274:in `block in run'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1432:in `block in with_advisory_lock'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/connection_adapters/abstract/connection_pool.rb:215:in `with_connection'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1447:in `with_advisory_lock_connection'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1428:in `with_advisory_lock'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1274:in `run'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/migration.rb:1131:in `run'
/app/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.4/lib/active_record/railties/databases.rake:195:in `block (3 levels) in <main>'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:281:in `block in execute'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:281:in `each'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:281:in `execute'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:219:in `block in invoke_with_call_chain'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:199:in `synchronize'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:199:in `invoke_with_call_chain'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/task.rb:188:in `invoke'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:160:in `invoke_task'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:116:in `block (2 levels) in top_level'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:116:in `each'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:116:in `block in top_level'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:125:in `run_with_threads'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:110:in `top_level'
/app/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4/lib/rails/commands/rake/rake_command.rb:24:in `block (2 levels) in perform'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/application.rb:186:in `standard_exception_handling'
/app/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4/lib/rails/commands/rake/rake_command.rb:24:in `block in perform'
/app/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/rake_module.rb:59:in `with_application'
/app/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4/lib/rails/commands/rake/rake_command.rb:18:in `perform'
/app/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4/lib/rails/command.rb:51:in `invoke'
/app/vendor/bundle/ruby/2.7.0/gems/railties-7.0.4/lib/rails/commands.rb:18:in `<main>'
/app/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/app/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
Tasks: TOP => db:migrate:up

Therefore, new features cannot be added to the dev platform without applying migrations manually. The same issue might occur on main.

Please make sure that the customer can always try out the newest dev version of the product in order to be able to make decisions based on the newest possible iteration.


Always uses dev environment config after eject

Bug Report or Feature Request (mark with an x)

[x] bug report
[ ] feature request

Versions.
node: 6.9.5
os: win32 x64
@angular/common: 2.4.9
@angular/compiler: 2.4.9
@angular/core: 2.4.9
@angular/forms: 2.4.9
@angular/http: 2.4.9
@angular/platform-browser: 2.4.9
@angular/platform-browser-dynamic: 2.4.9
@angular/router: 3.4.9
@angular/cli: 1.0.0-rc.2
@angular/compiler-cli: 2.4.9

Windows 7
Repro steps.

Generate new app
Edit environment.ts with a new property with a unique string value

uniqueProp: "my-dev-prop"

[Not really necessary since it's already included in main.ts] Import the environment config in any .ts file, for example in app.module.ts

import {environment} from '../environments/environment';

run ng eject --prod --e prod
run npm run build
run a search through files in dist/ looking for unique value specified in step 2

Desired functionality.
To have production environment configuration used when building.
(or given above mentioned repro steps to not find the specified string value)
Mention any other details that might be useful.
I'm running the commands from Git Bash.

@sodper I believe the arguments you are using are incorrect, try using:
ng eject -e prod
or
ng eject --environment prod
it worked for me.

I just tried the repro steps with both ng eject -e prod and ng eject --environment prod and I still get the same results. Are you running the same versions as I am?

Dupe of https://github.com/angular/angular-cli/issues/4907

@filipesilva I don't agree with you that this is a duplicate of #4907. The issue I'm having is that the webpack config generated by ng eject --environment=prod doesn't use the environment.prod.ts, even though it's declared in the AOT plugin like so:
hostReplacementPaths: {
  'environments/environment.ts': 'environments/environment.prod.ts'
}

Have you tried to reproduce the issue with the above stated repro steps?

Apologies, I misunderstood. Reopening.

My cli version is rc2. The only difference is that I'm on a mac.

I am facing the same problem. Is there a workaround?

Same issue here. Seems that the AoT Plugin is broken. Or do we miss something in the Webpack configuration?

Error is in WebpackCompilerHost used by AoT Plugin. While replacing 'environments\environment.ts' with 'environments\environment.prod.ts' in writeFile, file path is normalizing to Windows-style by utilite path, e. g. 'environments\environment.ts' transforms to something like 'C:\git\test-app\src\environments\environment.ts'. But later, when compiler is looking for environment file, it is looking for unix-style path, e. g. 'C:/git/test-app/src/environments/environment.ts'. File paths does not match and compiler uses original environment file instead of replacement.

@TheLegion thanks :) any workaround?

Hi @harouny
The workaround i am using is two part, one for dev and one for build, but they work side by side.
first in the webpack config under resolve i add an alias for enviroment like:
resolve: {   extensions: ['.ts', '.js', '.scss'],   alias: {     environment: helpers.environment(options.ENV),   } }
helpers.environment(options.ENV) just returns the path to my enviroment file eg ./src/environments/dev/index.ts
then in the tsconfig.json i update the paths node like:
"paths": {       "environment": [         "./environments"       ]     }
lastly i have updated the imports to be: import { environment } from 'environment';
rather then:  import {environment} from '../environments/environment';
i have changed the file name from environment.ts to index.ts for simplisity,
hope this makes sense

any news?

@carl09 what is helpers.?

@kotmatpockuh A sample content of helpers can be found here.

eject functionality is no longer available in the latest version (6.0+).  For custom webpack configurations the following unofficial add-on is a suggested solution: https://github.com/manfredsteyer/ngx-build-plus


stitch threshold not working

When running cellpose in a Colab notebook, and specifying stitch_threshold > 0 and do_3D = False, I get this warning:
/usr/local/lib/python3.7/dist-packages/torch/nn/functional.py:3826: UserWarning: Default grid_sample and affine_grid behavior has changed to align_corners=False since 1.3.0. Please specify align_corners=True if the old behavior is desired. See the documentation of grid_sample for details

"Default grid_sample and affine_grid behavior has changed "

This is just a warning from pytorch, I don't believe it has any effect on the cellpose algorithm.

yep, thanks @kevinjohncutler it's a warning which should go away in future versions


[DOCS] Document prompt_formatting_fn properly or remove from the codebase

Which page or section is this issue related to?
The use of the argument prompt_formatting_fn of the LLM is not well documented. If it's still has a fit we should document it properly and add some examples, otherwise we could remove it.
What are you documenting, or what change are you making in the documentation?

Indeed I think all these questions will arise whenever we decide to go ahead with the configuration based runs, as some args may not be used or some others may be missing.
But yes, we should carefully review those and keep only what's used / usable.


[Concurrency] Fix swift_taskGroup_initializeWithFlags availability

Description: The new runtime function swift_taskGroup_initializeWithFlags introduced to support discarding task group initialization has wrong availability. It must have availability equal to when it was introduced, but had the "general" concurrency one. Its availability must be 5.9. If we don't do this, then code like this:
if #available(iOS 17.0, *) {
    await withDiscardingTaskGroup {
        $0.addTask {
            try? await Task.sleep(for: .seconds(1))
        }
    }
}

can crash when compiled against iOS 16 target, since it'd attempt to strong refer to the symbol, but it's missing, yielding a Symbol not found: _swift_taskGroup_initializeWithFlags
Risk: Low
Review by: @rjmccall  @mikeash
Testing: CI testing
Radar: rdar://112469076

@swift-ci please smoke test


TypeError: Cannot read property 'graphs' of undefined.

This seems to be related to the code block around line 291 in angular-nvd3.js, where the comment is talking about doing something for compatibility with an older version of nvd3.
plnkr example

Rolling back to older versions of d3, nvd3, and angular-nvd3 shows a different error, so maybe it's my code and not angular-nvd3?
TypeError: nv.models[options.chart.type] is not a function
plnkr example 2

+1

+1

I am having same issue. On website it says that 1.0.9 is compatible with nvd3 1.8.1+ but it is not. I get the error described above. Even when I use exactly 1.8.1 version of nvd3 it does not work. However rolling back to 1.0.8 as suggested fixes the problem.

angular-nvd3 v1.0.9 + nvd3 v1.8.4 + d3 v4.2.6 (BROKEN)
angular-nvd3 v1.0.9 + nvd3 v1.8.1 + d3 v4.2.6 (BROKEN)
angular-nvd3 v1.0.8 + nvd3 v1.8.4 + d3 v4.2.6 (WORKS)

@jjcad in your demo you include d3.js script in wrong way:
<script> src="https://cdnjs.cloudflare.com/ajax/libs/d3/3.5.3/d3.js"</script>

fix to
<script src="https://cdnjs.cloudflare.com/ajax/libs/d3/3.5.3/d3.js"></script>

and everything works fine.

That's incredibly embarassing. I can't believe I didn't notice that.

This still seems to have problems. I get errors when trying to use the latest versions as described above.
http://plnkr.co/edit/Ygt5n30WGuaIaw9IY56o?p=preview

any news with this error? @krispo

also having that problem

Still having the same issue. Downgrading to 1.0.8 as per @goodies4uall 's suggestion fixes it.

Yep, I'm still seeing the error.

New comer.    angular_nvd3 tutorial does not work

save with levydev. Tried the 'basic usage' and it didn't work.

+1

Just started using angular-nvd3.  Ran into this issue and found this thread via google.  I too solved by changing to 1.0.8, for what it's worth.


Android: Using deprecated Android API?

During the iOS development, I noticed some parity issues in the initialization of the module. iOS needs an app ID, client ID and url, while Android uses an API key. Looking at the Android docs, Android requires the same as iOS there, which leads me to think that the Android implementation may use an outdated API? I can easily migrate to the newer one while I am at it, just let me know!

Interesting. I was using those docs:
https://developer.zendesk.com/documentation/zendesk-web-widget-sdks/sdks/android/getting_started/
which uses zendesk.messaging only, I'm not using the whole support library. So it is a different part of the API. iOS messaging needs a key too: https://developer.zendesk.com/documentation/zendesk-web-widget-sdks/sdks/ios/getting_started/
But we can implement both parts

Looks like the SDK I'm using is newer:

The Zendesk Web Widget and SDKs are relatively new, and as such, do not have all of the features and customization options of our previous Classic SDKs. Depending on your needs and the interactions that you'd like to provide to your customers, you may be interested in exploring them as well. You can check out our documentation to learn more about the Classic SDKs

but we can't use both:

Note: The Zendesk mobile SDK for Messaging is not compatible with the Classic mobile SDKs. Using both within the same app is not supported and may produce unexpected results.

So if we want to support more features I should switch to the old SDK you are using

Okay, weird architecture decision from Zendesk. Then just keep it as-is for now and orientate based on the needs of the community later?

If both display the same Messaging view it should be fine for now :+1:
I'll try to get a demo account and check both implementations. Could you add a binary file in the PR then I can review it at the weekend and merge the stuff.
Thanks!
I'll keep this one open and check everything at the weekend


queue helper: move kumo.on get_queue_config to own function

Add setup_get_queue_config function to make use of the helper and still be able to set get_queue_config handlers in init.lua for rollup.
Not sure if it's the right way to do it though.

Yeah, I use apply_ip_rollup_to_queue_config in the queue config event handler in init.lua that's why I wanted to setup a way to skip the event handling in the helper.
I'll change it to your alternate setup method.


Let initial_layout be a list

What is the expected enhancement?
Lets the user pass a list of numbers as an initial_layout to the compile function that maps the circuit from top to bottom in the quantum registers.

We decided to alter the format of the initial_layout to something like this:
[('q0', 0), ('q1', 0), None, ('q1', 1), ('q0', 0)]

where each tuple specifies one circuit qubit, and each position in the list corresponds to a physical qubit on the chip (in this case 5 qubits). The physical qubits are assumed to be ordered (Qobj has this assumption too).
This will hopefull have the flexibility of the current dictionary approach, but much easier to write (which was the goal of #727).

we want a single initial layout for a batch of circuits. This needs to be documented as well

this is done with the Layout object that receives a list.
the rest is propagating it to the global compile/execute functions as part of #978 .


Make resourceName optional for setting up the localization file

This is to loosen the rule of resourceName.
In my solution, I have single localization file for each language (i.e. en.json, ar.json etc.).

Could you please provide a unit tests for this one?

In this case we don't need to use a generic version of IStringLocalizer coz it's useless

@abarrak I know your changes was little and fix the issue, but I'd like to take more further to use IStringLocalizer instead of IStringLocalizer<T>

Kudos for that. Pretty much resolve the issue in optimal way.
Hope we have it soon in next version.

Hope we have it soon in next version.
Hope to publish  a NuGet package soon

Thanks @abarrak


bson: error trying to connect: invalid certificate

on macos: error: error sending request for url (https://cdn.skypack.dev/bson): error trying to connect: invalid certificate: UnknownIssuer
at https://deno.land/x/mongo@v0.27.0/bson/mod.ts:2:0

Check your connection and then your certificate authority settings, that's a client issue


Use case for "textgroup" tokens

Original parser(markdown-it) does not have textgroup tokens, usually a paragraph has a list of elements which can be of any type, and the core leaf node is just text.
Why and what is the need for textgroup specifically?

I have been having problems with the textGroup token - explained here: https://github.com/iamacup/react-native-markdown-display/issues/42#issuecomment-562199006


Adapt logic for Custom Serving Runtime migration and adapt OVMS OOTB

Description

Closes #2059 #2048
How Has This Been Tested?

Deploy the new OVMS model
Clone other template and remove the opendatahub.io/modelServingSupport annotation
Check that OMVS will only supports multi model
Check that the Serving Runtime with no annotation only supports multi model

Test Impact

Adapted tests and added unit testing coverage
Request review criteria:

Self checklist (all need to be checked):

[X] The developer has manually tested the changes and verified that the changes work
[X] Commits have been squashed into descriptive, self-contained units of work (e.g. 'WIP' and 'Implements feedback' style messages have been removed)
[X] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[X] The developer has added tests or explained why testing cannot be added (unit tests & storybook for related changes)

If you have UI changes:

[ ] Included any necessary screenshots or gifs if it was a UI change.
[ ] Included tags to the UX team if it was a UI/UX change (find relevant UX in the SMEs section).

After the PR is posted & before it merges:

[ ] The developer has tested their solution on a cluster by using the image produced by the PR to main

/approve

when is this one going into incubation? @lucferbux


WFLY-4463 Genrate IIOP stubs manually if IBM jvm is used

Windows Build 1279 is now running using a merge of 86719d84d3af201425afa7a3bffc348fff32efde

Linux with security manager Build 1143 is now running using a merge of 86719d84d3af201425afa7a3bffc348fff32efde

Linux Build 6167 is now running using a merge of 86719d84d3af201425afa7a3bffc348fff32efde

Linux Build 6167 outcome was FAILURE using a merge of 86719d84d3af201425afa7a3bffc348fff32efde
Summary: Exit code 1 (new) Build time: 0:00:20
Build problems:
Process exited with code 1

Windows Build 1279 outcome was FAILURE using a merge of 86719d84d3af201425afa7a3bffc348fff32efde
Summary: Exit code 1 (new) Build time: 0:00:23
Build problems:
Process exited with code 1

Linux with security manager Build 1143 outcome was SUCCESS using a merge of 86719d84d3af201425afa7a3bffc348fff32efde
Summary: Tests passed: 819, ignored: 356 Build time: 0:08:40

Linux Build 6168 is now running using a merge of cf3cc5782c876862f59a2db110259a3ba7725085

Linux with security manager Build 1144 is now running using a merge of cf3cc5782c876862f59a2db110259a3ba7725085

Windows Build 1280 is now running using a merge of cf3cc5782c876862f59a2db110259a3ba7725085

Linux Build 6168 outcome was FAILURE using a merge of cf3cc5782c876862f59a2db110259a3ba7725085
Summary: Exit code 1 Build time: 0:00:18
Build problems:
Process exited with code 1

Windows Build 1280 outcome was FAILURE using a merge of cf3cc5782c876862f59a2db110259a3ba7725085
Summary: Exit code 1 Build time: 0:00:23
Build problems:
Process exited with code 1

Linux with security manager Build 1144 outcome was SUCCESS using a merge of cf3cc5782c876862f59a2db110259a3ba7725085
Summary: Tests passed: 819, ignored: 356 Build time: 0:05:42


help ,please

I have trained the model for 20 eopchs completly, but I couldn't get good result.Maybe 20 epochs result in underfitting or overfitting?PLEASE~

If you're not improving on your loss then probably it is underfitting, but it's difficult to tell for sure without any background. Can you maybe paste in a plot of losses or just the loss figures for your 20 epochs?
P.S. Is this the same data you're training on?

Hello. Thank you so much for this code it works amazingly. Though I was trying to export the model trained using this link: https://www.tensorflow.org/text/tutorials/transformer. But it's throwing me an error

It says AttributeError: 'Tensor' object has no attribute 'lower'
I need to export this model to use it in a flask app. Any help would be appreciated
Thanks

As I can see from a high level, the issue starts when you are using ExportTranslator for the function call, which is decorated using @tf.function. This constructs the graph for execution. I think if you remove @tf.function, i.e., make the execution eager, then this should work.
However, I understand that it can make your model slow and less deployable. The link you mentioned uses the tf.data API for preprocessing, see this:
def make_batches(ds):
  return (
      ds
      .shuffle(BUFFER_SIZE)
      .batch(BATCH_SIZE)
      .map(prepare_batch, tf.data.AUTOTUNE)
      .prefetch(buffer_size=tf.data.AUTOTUNE))

as opposed to my code:
dataset = tf.data.Dataset.from_tensor_slices((inputs, targets)).shuffle(BUFFER_SIZE).batch(BATCH_SIZE)

This API creates a seamless pipeline of data and enables end-to-end model execution from raw data to raw output. Unfortunately, I haven't used it in my code and have a static preprocessing which seems to be the root of your issue. If you can translate your data (at least the test or live data from your app) to the tf.data pipeline and pass that to the model, then you should be good, I guess.
LMK if that helps.
Thanks!

Hey there!
Sorry for the late reply but thankfully it worked
So thanks to you
I removed the decorator and it worked for now. Haven't tried creating tf.data api though.
However I want to save this model and use it somewhere else.
So when I save this model using tf.saved_model.save(summarizer_model, 'save_dir') , then load the model using
model = tf.saved_model.load('save_dir') and then try to run it it shows the following error:

When I try saving it with tf.keras.models.save_model(summarizer_model,'save_dir')
I get the following error:

There is no problem running the model that was created with ExportTranslator above before saving it:

Any help would be appreciated
Thanks in advance!

Unfortunately, i haven't come across this error. But I found this: https://github.com/tensorflow/tensorflow/issues/37439#issuecomment-600290097
I think you'll need to use tf.keras.model.save
Hope this helps

Thanks for the tip
I've tried this but doesn't work for me
I'll find a workaround and let you know
But yes thanks for the help!
Cheers!


problem french accent

Accented characters no longer display correctly in french.

(It worked well until a few weeks ago)

Hi,
Check it out:
https://sourceforge.net/p/webadmin/bugs/5270/


S3cmd fails to delete recursively a bucket created during test

Tested with

oio-swift: 2e883e55a10103629c1934146edbde057f81db08 (master)
swift:  e6e78925f2674e33e8262a842412ebe66e89cf2d (stable/ocata)
swift3: b65a2a77cbe275ea50adf99a1e38c46ac801b7a6 (master)

$ ./s3cmd ls -r s3://murlock-s3cmd-autotest-1
2017-05-29 09:44        13   s3://murlock-s3cmd-autotest-1/single-file/single-file.txt
2017-05-29 09:44  16777216   s3://murlock-s3cmd-autotest-1/urandom.bin
2017-05-29 09:44  16777216   s3://murlock-s3cmd-autotest-1/urandom2.bin

$ ./s3cmd rm -r --force s3://murlock-s3cmd-autotest-1
delete: 's3://murlock-s3cmd-autotest-1/single-file/single-file.txt'
delete: 's3://murlock-s3cmd-autotest-1/urandom.bin'
delete: 's3://murlock-s3cmd-autotest-1/urandom2.bin'

$ ./s3cmd ls -r s3://murlock-s3cmd-autotest-1
2017-05-29 09:44        13   s3://murlock-s3cmd-autotest-1/single-file/single-file.txt
2017-05-29 09:44  16777216   s3://murlock-s3cmd-autotest-1/urandom.bin
2017-05-29 09:44  16777216   s3://murlock-s3cmd-autotest-1/urandom2.bin

Please note that uploading manually three files with same name/path, it works:
$ ./s3cmd put /etc/passwd s3://tmp/single-file/single-file.txt
WARNING: Module python-magic is not available. Guessing MIME types based on file extensions.
upload: '/etc/passwd' -> 's3://tmp/single-file/single-file.txt'  [1 of 1]
 2994 of 2994   100% in    0s    26.25 kB/s  done

$ ./s3cmd put /etc/passwd s3://tmp/urandom.bin
WARNING: Module python-magic is not available. Guessing MIME types based on file extensions.
upload: '/etc/passwd' -> 's3://tmp/urandom.bin'  [1 of 1]
 2994 of 2994   100% in    0s    28.29 kB/s  done

$ ./s3cmd put /etc/passwd s3://tmp/urandom2.bin
WARNING: Module python-magic is not available. Guessing MIME types based on file extensions.
upload: '/etc/passwd' -> 's3://tmp/urandom2.bin'  [1 of 1]
 2994 of 2994   100% in    0s    27.92 kB/s  done

$ ./s3cmd ls -r s3://tmp
2017-05-29 09:59      2994   s3://tmp/single-file/single-file.txt
2017-05-29 09:59      2994   s3://tmp/urandom.bin
2017-05-29 09:59      2994   s3://tmp/urandom2.bin

$ ./s3cmd rm -r --force s3://tmp
delete: 's3://tmp/single-file/single-file.txt'
delete: 's3://tmp/urandom.bin'
delete: 's3://tmp/urandom2.bin'
$ ./s3cmd ls -r s3://tmp
$

As seen with you, it appears that issue is related with multipart object with Delete Multiple Objects API operation.

I reproduced the bug. I noticed that it does not appear when there is proxy-logging in the pipeline between tempauth and slo, and force_swift_request_proxy_log option of swift3 is true.

@murlock Can you confirm this fix ?

The issue is still here:
I've used
[DEFAULT]
bind_port = 5000
workers = 1
user = murlock
log_facility = LOG_LOCAL0
log_level = DEBUG
eventlet_debug = true

[pipeline:main]
pipeline = catch_errors cache swift3 tempauth proxy-logging slo proxy-server

[app:proxy-server]
use = egg:oioswift#main
allow_account_management = true
account_autocreate = true
sds_namespace = OPENIO
sds_proxy_url = http://<IP_ADDRESS>:6000
user = murlock
object_post_as_copy = false
log_name = OIO,NS,oioswift,1
sds_connection_timeout=5
sds_read_timeout=5
sds_write_timeout=5

[filter:autocontainer]
use = egg:oioswift#autocontainer
default_account = myaccount
offset = 6
mask = 0xFFFFFFFFFF0000FF
base = 10
format = %016d

[filter:gatekeeper]
use = egg:swift#gatekeeper

[filter:proxy-logging]
use = egg:swift#proxy_logging

[filter:catch_errors]
use = egg:swift#catch_errors

[filter:ratelimit]
use = egg:swift#ratelimit

[filter:healthcheck]
use = egg:swift#healthcheck

[filter:cache]
use = egg:swift#memcache
memcache_servers = <IP_ADDRESS>:11211

[filter:slo]
use = egg:swift#slo

[filter:staticweb]
use = egg:swift#staticweb

[filter:swift3]
use = egg:swift3#swift3
location = localhost
force_swift_request_proxy_log = true
log_level = DEBUG
storage_domain = localhost
s3_acl = true
# check8bucket_owner = false
# min_segment_size = 8
bucket_db_enabled = true
bucket_db_host = <IP_ADDRESS>:6379

[filter:tempauth]
use = egg:swift#tempauth
log_level = DEBUG
user_demo_demo = DEMO_PASS .admin
log_level = DEBUG

user_tester2_tester2 = TESTER2 .admin

Test still show issue:
(oio) murlock@asus:~/openio/resources/s3cmd (master)*$ dd if=/dev/urandom of=bigfile bs=1M count=35
35+0 records in
35+0 records out
36700160 bytes (37 MB, 35 MiB) copied, 0,258571 s, 142 MB/s
(oio) murlock@asus:~/openio/resources/s3cmd (master)*$ ./s3cmd -c ./s3cfg_port_5000 put bigfile s3://test/dir/bigfile
WARNING: Module python-magic is not available. Guessing MIME types based on file extensions.
ERROR: S3 error: 404 (NoSuchBucket): The specified bucket does not exist.
(oio) murlock@asus:~/openio/resources/s3cmd (master)*$ ./s3cmd -c s3cfg_port_5000 mb s3://test
Bucket 's3://test/' created
(oio) murlock@asus:~/openio/resources/s3cmd (master)*$ ./s3cmd -c ./s3cfg_port_5000 put bigfile s3://test/dir/bigfile
WARNING: Module python-magic is not available. Guessing MIME types based on file extensions.
upload: 'bigfile' -> 's3://test/dir/bigfile'  [part 1 of 3, 15MB] [1 of 1]
 15728640 of 15728640   100% in    0s    46.25 MB/s  done
upload: 'bigfile' -> 's3://test/dir/bigfile'  [part 2 of 3, 15MB] [1 of 1]
 15728640 of 15728640   100% in    0s    55.25 MB/s  done
upload: 'bigfile' -> 's3://test/dir/bigfile'  [part 3 of 3, 5MB] [1 of 1]
 5242880 of 5242880   100% in    0s    46.65 MB/s  done
(oio) murlock@asus:~/openio/resources/s3cmd (master)*$ ./s3cmd -c ./s3cfg_port_5000 put /etc/passwd s3://test
WARNING: Module python-magic is not available. Guessing MIME types based on file extensions.
upload: '/etc/passwd' -> 's3://test/passwd'  [1 of 1]
 3020 of 3020   100% in    0s   118.67 kB/s  done
(oio) murlock@asus:~/openio/resources/s3cmd (master)*$ ./s3cmd -c ./s3cfg_port_5000 rm -r --force  s3://test
delete: 's3://test/dir/bigfile'
delete: 's3://test/passwd'
(oio) murlock@asus:~/openio/resources/s3cmd (master)*$ ./s3cmd -c ./s3cfg_port_5000 ls  s3://test
                       DIR   s3://test/dir/
(oio) murlock@asus:~/openio/resources/s3cmd (master)*$ ./s3cmd -c ./s3cfg_port_5000 ls  s3://test/dir/
2017-08-31 12:00  36700160   s3://test/dir/bigfile


Fix tests

@Rich-Harris Need to enable also travis

On my windows everything is okay. And I will make some noise to fix appveyor.

Do not merge yet please

@Rich-Harris It was npm3 deduping :)

:+1:

It was npm3 deduping :)

(╯°□°）╯︵ ┻━┻
Thanks! Have enabled Travis


feat(server): Lobby server improvements

Addresses some of the issues raised by #429

Creates seat credentials when a player joins a game, deleting them when they leave, rather than instantiating them all once when a game is created. This stops credentials leaking as described by @flamecoals.

Enables some basic customisation of authentication by adding generateCredentials and authenticateCredentials options to the Lobby server.
If provided, generateCredentials can be called in place of shortid and receives the Koa ctx object, so request headers etc. can be used for credential generation. This can be an async function if needed.
authenticateCredentials receives a simplified signature of (credentials, playerMetadata) when called from the server master (compared to { action, gameMetadata, gameID, playerID } used internally). In non-synchronous masters, authenticateCredentials can also be an async function to support third-party API calls.

There should be no breaking changes here. I changed the signature of the SocketIO server transport, but as far as I can tell, that wasn’t exposed externally in any way.

I think previously the default unique ID was very long, so it made bad
links. I asked to change to a shorter one, which at the time we decided to
open up for customization. My only requirement is for it to be short and
preferably URL friendly
On Thu, Dec 19, 2019, 5:58 PM Nicolo John Davis<EMAIL_ADDRESS>wrote:

@nicolodavis commented on this pull request.
In docs/documentation/api/Server.md
https://github.com/nicolodavis/boardgame.io/pull/532#discussion_r360199825
:

@@ -24,6 +24,10 @@ A config object with the following options:

transport (object): the transport implementation.
If not provided, socket.io is used.

+4. generateCredentials (function): an optional function that returns player credentials to store in the game metadata and validate against. If not specified, the Lobby’s uuid implementation will be used.
Sorry if I missed some context in the original issue discussing this, but
what's the use-case for having a customized function to generate
credentials that isn't just invoking something like uuid?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nicolodavis/boardgame.io/pull/532?email_source=notifications&email_token=AAH4TB6T3YKA6E75QZU5ZFDQZQRGHA5CNFSM4J5UTJQ2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCP4DUDY#discussion_r360199825,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH4TB4HGEU6BOWSNRGK4QDQZQRGHANCNFSM4J5UTJQQ
.

I hadn’t thought about URLs. I have seen some people providing links to share for each seat when a game is created. I guess these changes would remove the credential leaking, but might prevent people from doing that kind of thing?

For freeboardgame.org, if I remember correctly, we share only the room id
and the server assigns the seat on the fly. But I need to review it to be
sure
On Thu, Dec 19, 2019, 6:15 PM Chris Swithinbank<EMAIL_ADDRESS>wrote:

I hadn’t thought about URLs. I have seen some people providing links to
share for each seat when a game is created. I guess these changes would
remove the credential leaking, but might prevent people from doing that
kind of thing?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nicolodavis/boardgame.io/pull/532?email_source=notifications&email_token=AAH4TBYLOTMZRX5PKLLHLVDQZQTDLA5CNFSM4J5UTJQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHLUYLI#issuecomment-567757869,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH4TBYCGM7EEI3HVBWRGBDQZQTDLANCNFSM4J5UTJQQ
.

I hadn’t thought about URLs. I have seen some people providing links to share for each seat when a game is created. I guess these changes would remove the credential leaking, but might prevent people from doing that kind of thing?

Why would it prevent people from creating links to join specific seats?  If generateCredentials returns something that is URL friendly, it should still be possible, no?

If generateCredentials returns something that is URL friendly, it should still be possible, no?

Absolutely, but the credentials would have to be created one-by-one for each seat via the join endpoint (because they’re created on join, rather than on create game). That said, at the moment, you can only get a seat’s credentials by joining it, so presumably people are already “joining” several times to get the credentials and then displaying them all to a user.

@delucis Yeah, we'll have to figure out what's the best way to support joining specific seats via a URL (I think that's a nice feature to have).  That's beyond the scope of this PR of course, so let's get this in first.

@delucis What's the next step here?  Just double-checking that this is not waiting on me.

Sorry, dropped the ball on this one. It’s basically ready.
The one thing I’ve been indecisive on is the signature of the new generateCredentials and authenticateCredentials methods. The first just gets the raw Koa ctx, while the latter gets credentials from the player’s action payload and playerMetadata, which is the stored metadata for the player ID making the move. In other words, the first is very general (to allow use of custom headers in the join request), while the second is locked to some specific aliases (to hide the implementation complexity).
I kind of don’t like that these aren’t balanced and worry if they’re too specific to my experience. I forked a version of the server and integrated with Firebase Auth, but am not sure how helpful this generate/authenticate pattern would be for other services, because I don’t have experience using them.
In other words, I think it’s good to go and the fix for credential leaking is a definite improvement, I’m just fretting about details 😃

That's fine.  We can change the signatures if we see a future use-case that would benefit from something a bit different.


Skip headers and footers for skipped pages

Description
With pagebreak(to: "odd") we can skip pages to reach a certain parity. However, headers and footers still show up on the inserted blank page. It would be nice if there could be an option to disable any rendering on the skipped pages.
Use Case
Sometimes we need the skipped pages to be completely blank.

Is it more sensible to definitely not render any stuff on skipped pages?
 The status quos is A, you propose letting users choose A or B via an option, and I propose only B. I can't think of any cases where A would be useful.
I think it helps to prevent an unnecessary accumulation of options.

Is it more sensible to definitely not render any stuff on skipped pages?
 The status quos is A, you propose letting users choose A or B via an option, and I propose only B. I can't think of any cases where A would be useful.
I think it helps to prevent an unnecessary accumulation of options.

I don't really agree with this; it may be a requirement to have headers and footers on all pages of your document, depending on whom you are submitting it to.

@PgBiel reasonable, I don't have a strong opinion on this one so I'll add the option in my PR #2882 :)

What also ties in with this is the ability to have something like "This page intentionally left blank" printed on the page.

Is there a workaround for custom headers? I experimented with metadata and state, but couldn't find a good solution.

Nevermind, I got it to work. Here's a my metadata based workaround for a document with a cover page:
#let header(loc) = {
  let curpage = loc.page()
  let iscurpageeven = calc.even(curpage)
  // Show header unless <disable_header> is found on previous page and the
  // current page is even
  if not (query(<disable_header>, loc).filter(el => el.location().page() == curpage - 1) != () and iscurpageeven) {
    counter(page).at(loc).first()
  }
}

// Cover page
#pagebreak()

// Left page blank
#counter(page).update(0)
#set page(
  header: locate(loc => header(loc))
)
#pagebreak()

= A
#lorem(500)

#metadata("disable_header") <disable_header>
#pagebreak(to: "odd")

= B
#lorem(1000)

#metadata("disable_header") <disable_header>
#pagebreak(to: "odd")

= C
#lorem(500)

There could be an option on the page function for this, although I don't have a good concise name for this
The option could be a more general marginal filter though that might be overkill
Perhaps, we could also make it achievable in the header itself via introspection although that has the problem that it loses composability with an existing header/footer/numbering

What about creating a page.empty sub-element which inherits all styles from page by virtue of them being auto.
Such an element could be created when  pagebreak(to: _) creates intentional empty pages. As well as when a user explicitly inserts it or multiple strong pagebreaks.
Then, simple show/set rules would allow us to set heading and footer to none, or setting the default content using the background/foreground.
#set page.empty(
  header: none,
  footer: none,
  background: align(center + horizon)[Page intentionally left empty.]
)
// ...

Hmm, duplicating all page properties on a page.empty element doesn't feel nice to me. Conceptually I like the idea of a show-set rule more, but it is indeed tricky.

I developed another workaround that seems to work better than @agrueneberg's solution (still thanks for the inspiration, though!).
#let is-page-empty() = {
  let empty-page-start-labels = query(selector(<empty-page-start>))
  let empty-page-end-labels = query(selector(<empty-page-end>))
  let page-num = here().page()
  empty-page-start-labels.zip(empty-page-end-labels)
    .any(((start, end)) => {
      (start.location().page() < page-num
        and page-num < end.location().page())
    })
}
#show pagebreak: it => {
  [#metadata(none) <empty-page-start>]
  it
  [#metadata(none) <empty-page-end>]
}

#set page(
  numbering: "1 / 1",
  footer: context {
    if is-page-empty() {
      return
    }
    counter(page).display(page.numbering, both: true)
  }
)

#lorem(5)
#pagebreak(to: "odd")
#lorem(5)

I developed another workaround that seems to work better than @agrueneberg's solution when no page is inserted (still thanks for the inspiration, though!).

That workaround sadly breaks links when used in a show heading rule.
I guess one of the most common applications for this would be always starting chapters on odd numbered pages.
#show heading.where(level: 1): it => {
  pagebreak(to: "odd")
  it
}

Your workaround inserts a metadata element before the pagebreak. Because metadata is not considered whitespace links pointing to a heading will now point to the page before the pagebreak instead of to the heading, which is on the page after the pagebreak.

I developed another workaround that seems to work better than @agrueneberg's solution when no page is inserted (still thanks for the inspiration, though!).

That workaround sadly breaks links when used in a show heading rule. I guess one of the most common applications for this would be always starting chapters on odd numbered pages.
#show heading.where(level: 1): it => {
  pagebreak(to: "odd")
  it
}

Your workaround inserts a metadata element before the pagebreak. Because metadata is not considered whitespace links pointing to a heading will now point to the page before the pagebreak instead of to the heading, which is on the page after the pagebreak.

Oh, that is a good point. This is unfortunate. :/

This last iteration is about fixing the page number associated with the headings, right? Besides the outline, the second problem is where the links point inside the resulting PDF. with the metadata before the pagebreak, the links will go to the previous page and not to the heading.
I currently use a workaround that requires manually adding the metadata, so that it is not part of the heading and doesn't break links & page numbers. I do at least include a check that these chapter ends are placed properly: https://github.com/TGM-HIT/typst-diploma-thesis/blob/aee8bb654d40ac7efc905d7f88fa22f2edf9309b/src/utils.typ#L8-L111

This indeed works great! Since the necessary pieces and 0.12 adaptations are a bit distributed throughout this thread, here is my take on it:
// make pagebreaks detectable
#show pagebreak: it => {
  [#metadata(none) <empty-page-start>]
  it
  [#metadata(none) <empty-page-end>]
}

// check whether this is an empty page
#let is-page-empty() = {
  let page-num = here().page()
  query(selector.or(<empty-page-start>, <empty-page-end>)).chunks(2).any(((start, end)) => {
    start.location().page() < page-num and page-num < end.location().page()
  })
}

// skip footer on empty pages
#set page(
  numbering: "1 / 1",
  footer: context if not is-page-empty() {
    counter(page).display(page.numbering, both: true)
  },
)

// demonstration
#lorem(30)

#pagebreak(to: "odd")

#lorem(30)

I have adjusted is-page-empty() a bit: I use an or selector to only do one query. I'm not sure, but I assumed that this is maybe more efficient? I'm sure Laurenz will correct me if not.


Strange stretched images at top of features

https://crimethinc-staging.herokuapp.com/1900/09/11/border
and
https://crimethinc-staging.herokuapp.com/1900/09/11/barc
for example.

and https://crimethinc-staging.herokuapp.com/1900/09/11/breaking

css on the image is set to width 100%

i'm still getting into this project, so i cant know the overall scope of this; should this not be 100% or is it a case of sometimes it should, sometimes it shouldn't.  In that case we would need another class.  Otherwise, the css that's causing this appears to be https://github.com/crimethinc/website/blob/master/app/assets/stylesheets/views/_article.scss#L254

Those old texts are gonna need a lot of hand tuning. They had a lot of old crufty HTML and inline CSS in them.
But yes, to your point, I think we'll need a case for non-100% width images. As the exception, with 100% as the rule, I think.

you might be able to get away with adding height: auto; to the image css class. That should stretch/shrink the images height to keep the native aspect ratio (source)
gif example

Good call, @astronaut-wannabe. Wanna submit a pull request?

@veganstraightedge will do 👍

opened https://github.com/crimethinc/website/pull/216


feat: hnswlib document index

Goals:
First implementation of a Document Store.
Design doc: https://lightning-scent-57a.notion.site/Document-Stores-v2-design-doc-f11d6fe6ecee43f49ef88e0f1bf80b7f
Usage Example:
# create a Document Store
from docarray.storage.backends.HnswDocStore import HnswDocumentIndex
from pydantic import Field
from docarray.typing import NdArray
from docarray import DocumentArray, BaseDocument

class MyDocument(BaseDocument):
    tens: NdArray[10]

store = HnswDocumentIndex[MyDocument](work_dir='path/to/work/dir')

# index some data
data = DocumentArray[MyDocument]([MyDocument(tens=np.random.randn(10)) for i in range(10)])
store.index(data)

# find by np array
result = store.find(np.random.random((10,)), embedding_field='tens', limit=5)
result = store.find_batched(np.random.random((2, 10)), embedding_field='tens', limit=5)

# find by Document
result = store.find(MyDocument(tens=np.random.randn(10)), search_field='tens', limit=5)
result = store.find_batched(DocumentArray[MyDocument]([MyDocument(tens=np.random.randn(10)) for i in range(10)]), search_field='tens', limit=5)

# delete data
del store[data.id]  # delete all

# advanced configs
class MyDocument(BaseDocument):
    tens_one: NdArray = Field(dim=10, space='cosine')
    tens_two: NdArray = Field(dim=10, space='l2')
store = HnswDocumentStore[MyDocument](work_dir='path/to/work/dir')

# select search field
data = DocumentArray[MyDocument]([MyDocument(tens_one=np.random.randn(10), tens_two=np.random.randn(10)) for i in range(10)])
store.index(data)
result = store.find(np.random.random((10,)), search_field='tens_one', limit=5)
result = store.find(np.random.random((10,)), search_field='tens_two', limit=5)

# use query builder
q = store.build_query()
q.find(query=data[0], search_field='tens_one', limit=5)
q.find(query=data[1], search_field='tens_two', limit=5)
q.filter(filter_query={'tens_two': {'$exists': True}})
result = store.execute_query(q.build())

# nested search
class InnerDocument(BaseDocument):
    tens_one: NdArray = Field(dim=10)

class MyDocument(BaseDocument):
    d: InnerDocument
    tens: NdArray = Field(dim=10)

store = HnswDocumentStore[MyDocument](work_dir='path/to/work/dir')
data = DocumentArray[MyDocument]([MyDocument(d=InnerDocument(tens_one=np.random.randn(10)), tens=np.random.randn(10)) for i in range(10)])
store.index(data)

result = store.find(np.random.random((10,)), search_field='tens', limit=5)
result = store.find(np.random.random((10,)), search_field='d__tens_one', limit=5)

ToDo:

[x] basic search
[x] automatic conversions in the base class
[x] query builder interface

[x] autocomplete for method kwargs

[x] think about other interface methods such as num_docs() etc
[x] think about abstraction layers
[x] infer tensor dimensionality from type hint
[x] handle config passing properly
[x] persistence using SQLite

[ ] proper error messages when things go wrong

[x] handle HNSWLib nuances around saving/loading and changing configurations
[x] deleting documents
- [ ] nested access syntax: change __ to .
[ ] test torch and tf
[ ] enable arbitrary data types in fields
[ ] subindices
[ ] tests

Note: unchecked boxes above have been moved to separate PR

It is not clear to me how composability of the QueryBuilder work

I think we need to leave that up to the individual backends. Since every backend defines their queries differently, I don't think we can compose queries for them. So the base query builder just collects all the calls and args.
Actually I would love to automate this more across different backends, but couldn't think of an approach. Do you have an idea?

I would now call this PR ready to review & merge.
Note: Only the part considering the AbstractDocumentStore is considered ~done, there is still more work to do on the HNSWLib implementation. But this will be tackled in a separate PR.
That way we can unblock work on other backends/DBs.
So when reviewing please focus on:

AbstractDocumentStore implementation
how the HNSWLib implementation interacts with the abstraction layers

I added an .md with instructions for creating a new Doc Index class, I'll address the **kwargs comments tomorrow

can we mark all of the test as "slow" and "docstore" related ?

yep makes sense


mvSync

It'd be nice to have mvSync to replace fs.renameSync

+1

+1

+∞
Without this there isn't a trivial way to replace an existing fs.renameSync call.