http: websockets should interact with full http filter chain

Currently, the http connection manager immediately surrenders websocket requests to the websocket handler, bypassing all http_filters. This is problematic for API front proxies which need to terminate client TLS and pass authentication info in headers to upstream API servers. An Http::StreamDecoderFilter implementing such a proxy will not be called in the websocket handling code path, effectively disallowing TLS client auth on requests requiring websockets.
cc @rshriram @mattklein123

The websocket spec requires that the server responds with upgrade headers checked in isWebsocketUpgradeRequesrt:
Upgrade: websocket
Connection: Upgrade

A fairly general solution to this problem would be to defer handing off the connection to the websocket manager until after a successful response is received.
This would also allow recycling of http connections on failed upgrade requests to websocket handlers (e.g. when the upstream returns a 403 on a websocket upgrade request). Today, these failed connections need to be explicitly closed by the upstream.

cc @rshriram @mattklein123

@mikedanese the functionality change definitely makes sense to me. I think there are a few options here on how we could fix things. Unfortunately none of them are going to be easy.

Modify as you suggest so that we end up proxying the initial request all the way through to the router and back, and then do the hand off. There are some gotchas here that aren't immediately clear to me how to solve.
a) Early data (this was fixed recently). I think the data would have to be held by the connection manager until the response is received.
b) When the connection manager switches over to WS, the existing filters likely need to be destroyed. I generally have concerns about filters not being WS aware, and they may basically have to be reset to work properly (and then will that yield messed up stats, etc.). This in general makes me wonder if we need HTTP filters to actually be WS aware in some way.

Don't actually fully proxy the WS request to upstream, but allow filter iteration from the connection manager for WS requests. This would have to respect filter stop, deal with early data, and have all the same problems about filters being reset as (1), so it's probably about the same amount of work.

I will admit I don't have a very clear proposal right now without sitting down and doing some more thinking, so hopefully someone else can dig in and come up with a formal design proposal. @rshriram @ggreenway @alyssawilk for more comments.

Matt, for b) were you thinking of handling the WS upgrade as a header only request/response, then handing off any data and the rest of the connection to the tcp proxy session as a "second request"? I think that could be done pretty cleanly but you're more familiar with the data plane than I am.

Yeah, I think this is exactly how it would have to work, and I think would be the cleanest solution. We can dispatch a "request" and then depending on the response, decide what to do from there inside the connection manager.

One alternative is to add a new codec that supports the bare minimal websocket stuff framing. While http filters can be used with websockets, filters would typically see only the first req/resp and then the rest is opaque or even simply an extended decodeData()?
I haven’t revisited this in a while. But this was one initial line of thought.

It'd be helpful to us if websocket ugrades traversing an H2 hop could have full header sanitation on the H2 hops and onData calls for the websocket payload (for say DoS byte accounting).  I haven't looked at the websocket spec lately, but if we just allow pass-through of the upgrade header and make sure that bidirectional H2 works correctly, would this "Just Work"?  Anyone object to allowing this as opposed to only supporting CONNECT style upgrades as suggested on #1630?

Ok, fair, maybe I do want #1630.  I've filed https://github.com/nghttp2/nghttp2/issues/1181 to see if we can get (or add) nghttp2 support for this.
That would leave us with H2 "websockets" being treated as HTTP for both header and data accounting and H1 being treated as HTTP for headers and TCP proxying for payload.  Per 1) b) if I can sort out any bidi-HTTP/1 issues, would anyone object to at least having a configurable option for the HTTP/1.1 websockets for passing not just headers but also body through the HTTP filter chain rather than doing TCP proxy handoff?    As Matt points out the filters need to be websocket-aware in any case, and I can't speak for others but given the current things we do onData (mostly byte counting to various data sinks) it's easier for us to apply existing HTTP filters to websocket payload than detach them and implement the same onData functions on the TCP side and it's nice to have things accounted for consistently.

Also @ggreenway as he's been doing websocket changes and may have an opinion about adding more complex paths :-P

WebSockets is such an awkward thing to handle here. If we pass it through most of the http stack, you have to make all of those bits of the stack handle some non-http. If not all the filters support this, you'll have to carefully document which filters can be used with WebSockets. And we'll be adding complexity to all the filters that do handle WebSockets. If we don't go through the http code, we lose many of the benefits of WebSockets starting out as http.
I think I'd be more in favor of only handling the part of the data that really is http in the http-filters, to avoid complexity leaking into every filter. And then figure out some way to share the code, or at least make common the stats/accounting, for the bidirectional websocket data after the initial http handshake is complete.

@ggreenway that was my initial suggestion. I think if we do this the filters only see a header only request for the upgrade. That's all.

That seems reasonable. I don't think the code for http/1 WebSockets will be too bad. I think http/2 will be stranger because we can't drop to a TcpProxy; we'll still have to go through at the bottom part of the h2 stack.

Yeah, that's precisely my concern.   I'd started playing around with #1630 and I think we need some discussion of how we want to handle websockets in general in Envoy since I'd prefer we handle both paths consistently.
My assumption is if we went with an H2-H2 connect hop or H1-H2 websocket->CONNECT upgrade per #1630, the entire websocket payload would pass through the filters because that path is the only way we can send the data out through a single outbound H2 stream.   If we went that route, each filter is going to have to handle websocket (and other CONNECT) payload anyway.  I'd rather consistently pass things through onData for the current H1-H1 and the H2-H2 CONNECT->websocket downgrade (also per 1630) than have things handled significantly differently for H2 upstream and H1 upstream with the TCP proxy hand-off for one case and treating it like HTTP for the other.
The alternate is that we come up with some clever idea of how to jam a TCP proxy filter stack in the H2 path bridging the HttpConnectionManager directly to the H2 stream the router is writing to.  Beyond not seeing a really clean way to do that, the TCP stack seems the wrong abstraction for this case.  It's really not a standalone connection so for example doing idle timeouts if the stream stalls due to being preempted by higher priority streams (once we handle priorities) won't be correct.
For another way of looking at it, as TCP filters should support on[Raw]Data, HTTP filters should support onHeaders/on[HTTP]Data, and ideal websocket/connect filters should support onHeaders, on[Raw]Data.  Right now we're bridging the two by trying to pass the headers through HTTP filters and data through TCP filters, but the data will have to pass through an HTTP onData for serialization H2 path regardless.  Given this, maybe there's some clean way of making it clear if any HTTP filter is websocket-friendly and the HCM can just bypass any filter which should not apply?
Happy to schedule a quick chat over hangouts/zoom or we can discuss this on Tuesday if either would be easier.

Yeah, let's schedule some time to discuss this and figure out the best path forward.

I think the best thing to do here might be to have a separate filter stack for web socket connections. The filter stack construction code would have to be changed slightly, but I don't think it would be very difficult to wait until initial headers are received. WS filters can be different types, and optionally a filter could implement both types so it could be used in both filter stacks. This would be a medium/large project, but would probably leave us in the cleanest place afterwards.
But yes we should definitely discuss live to brainstorm what to do.

The summary of the conversation of today's community meeting is we're going to in configuration allow both an HTTP filter chain and a websocket filter chain, where for now in Envoy we'll reuse existing HTTP Filter APIs so folks can reuse their filters for both if they so choose.
Plan A involves using the existing router filter for websocket-to-upstream, with the caveat if we find that upstream connections don't handle pipelined HTTP followed by a websocket upgrade, there may be follow-up work to ensure we use a fresh connection for the upgrade rather than a recycled connection.
The other thing discussed was how to handle the H1/H2 upgrades/downgrades.  Envoy currently consistently normalizes on HTTP/2 semantics, so that filters don't have to branch where H1 and H2 differ.  In this one case we definitely want to normalize (imagine someone wanting to have a CORS filter blocking based on method, where it would block differently depending on if it was H1 websocket (GET with upgrade header) or H2 websocket (CONNECT style).  I'm mildly inclined to in this one case to normalize on HTTP/1.1 style (downgrade incoming H2 CONNECT to GET-with-upgrade before creating the filters) since websocket really is more of an HTTP/1.1 concept, but if anyone has even a mild preference for consistently treating things as H2 I'm just as happy to go that route.  Speak now!
The current websocket implementation (header intercept and TCP proxy handoff) will be supported until the new version is implemented, and then will go through the usual Envoy deprecation cycle to give folks plenty of time to both test and deploy the new way of doing things.

Hey @mattklein123 and @ggreenway
My proposed API changes for "new style" websockets basically allow a custom filter chain for any upgrade type configured on a per-listener basis (adding it to the HttpConnectionManager for now).  My thought was that'd be a bit more flexible for other upgrades folks might want as well as being reusable for connect support.  SG?
// The configuration for HTTP upgrades.
// For each upgrade type desired, an UpgradeConfig must be added.
message UpgradeConfig {
// The case-insensitive name of this upgrade, e.g. "websocket".
// For each upgrade type present in upgrade_configs, requests with
// Upgrade: [upgrade_type]
// will be proxied upstream.
string upgrade_type = 1;
// If present, this represents the filter chain which will be created for
// this type of upgrade.  If no filters are present, the filter chain for
// HTTP connections will be used for this upgrade type.
repeated HttpFilter filters = 5;
};
repeated UpgradeConfig upgrade_configs = 23;

To confirm this is going inside http connection manager ? Is there a possibility to add network filters? For example, you could imagine streaming arbitrary tcp connections (eg Mongo or MySQL over a h2 stream just like websockets. And these things would benefit from a network filter more than http filter).

Neither the current implementation or the changes discussed here allows attaching a network filter.  We're basically just reusing the HTTP is processing [HTTP-headers, HTTP-data] for processing [HTTP-headers, Arbitrary-Data].  I don't think it'd be a bad thing to support network filters for the data processing part but the problem is if we use a HTTP/TCP hybrid, we end up with a big disparity between how we handle upgrades/connect for H1 and H2 (where we simply can't TCP proxy since it's still stream based, so it basically has to go through something akin to the HTTP filter APIs at some point)
It's not the most elegant workaround ever, but in the short run one could write an http filter adapter/wrapper for any network filters to simply pass the "HTTP" onData to the network filter's onData functions.   Ideally in the long run we'd actually change the UpgradeConfig to take a WebSocket filter which could basically wrapper HTTP filters or TCP proxy filters, but I think I'm only doing the first step to getting us there.

@alyssawilk LGTM

@alyssawilk What other upgrade types are possible? Do http filters make sense for them? We're kind of shoe-horning http filters in for websockets, because it's close enough. Are there any other potential upgrade types where that won't make sense?

I was thinking connect upgrades might want to go this path, and while right now we're only parsing upgrade headers, I was thinking of adding a "magic keyword" for connect which was unlikely to overlap with anything real in HTTP land.
But really for all upgrades, there's the upgrade header path and then a bunch of onData calls, so I think the HTTP filters (which take headers and then data) are a more logical API match.

Sounds reasonable to me.

ok, I have a new awful corner case to discuss, which is websockets with chunked bodies (request or response bodies)
I believe technically they're allowed.  They're nonsensical for H2 since you wouldn't be able to differentiate the body payload from the websocket payload.  But we'd want the http-body/websocket-body delineation to survive an H1-H2-H1 hop.  I think the way to do that is just proxy the raw chunks over he H2 link, and put in a substitute header x-envoy-upgrade-encoding-was-chunked for the H2 hop which gets turned back into "transfer-encoding: chunked" for the subsequent H1 hop.
So preferences on if we accept

only upgrades with no bodies
only upgrades only with explicit content lengths
upgrades with any sort of bodies?
I'd prefer 1 or 3 for consistency but I'm up for whatever.  If I hear nothing back I'm going for 3 since I'm halfway to implementing that in any case.

@mattklein123 @ggreenway @PiotrSikora

Is this valid, though? Once WebSocket handshake is completed, the connection turns into bidirectional end-to-end bytestream that's unrelated to HTTP, and should be opaque to the proxy, so I don't believe that Transfer-Encoding: chunked is valid here. Also, WebSocket protocol uses its own data framing, so it shouldn't care about chunking.
If you're seeing this in the wild, then I suspect that the intermediary advertises Transfer-Encoding: chunked, but switches to the bytestream tunnel anyway and doesn't actually produce valid chunks.
Also, I'd like to hear a strong argument as to why do we need to use x-envoy-upgrade-encoding-was-chunked and send Transfer-Encoding: chunked to the upstream, since it's a hop-by-hop header.

Once the websocket handshake is complete, the payload is now websocket and not chunked HTTP.  As I read it, the HTTP request-response should totally allowed to be chunked as it's valid HTTP.  Something like this where there's a chunked body, a terminal chunk, then websocket payload.
I don't think anyone should intentionally do this, but I'm concerned there'd be some proxy which took a content-length: 0 request and transformed it to a T-E: chunked\r\n\r\n0\r\n\r\n style body.  Or something which auto-chunked on the response path as response bodies are more likely.  So I'd prefer we either completely disallow bodies (content-length: 0 or bust) or handle both cases.
If we agree this is a corner case we ought to handle (T-E chunked is currently accepted and broken in our current websocket implementation), when the data traversed the H1->H2 hop, we'd have to preserve the boundary between HTTP body data and websocket payload.  The best* way to do that I can think of in H2  is to literally proxy the raw H2 payload (chunks included), and then re-append the T-E:chunked header when doing the H1 downgrade.  We have to communicate that the H1 payload is chunked over the H1-H2 hop and you're not allowe to use T-E chunked header, hence my proposed header shenanigans.
*We could also invent a new framing layer, or buffer the full request body and append a content length. But the former is obviously more complicated and the latter is less obviously super-complicated (which I can explain offline) so I'm pretending I didn't think of either.

@alyssawilk i don't have a strong opinion here. My general feeling is to support as few things as possible and then wait for someone to complain about other permutations.

Do we have to drop bodies all together ? We could support upgrades with bodies within limits of what Envoy accepts today. No chunking business. And no business of half http payload and half websocket payload. I don’t even think it’s possible since the client has to wait for the server to respond with upgrade accepted and then client starts the framing by setting its sequence numbers etc. are you thinking of a scenario where the server sends websocket payload with upgrade confirmation ?

@alyssawilk I don't believe that HTTP request body before switching to WebSocket is a thing, and even if there are peers out there that emit stuff like that, then the behavior seems to be undefined, and I'd rather reject such requests, than support this weirdness and add to the problem (...unless we have a very good reason to do it).
RFC6455, sec. 1.7 says:

The WebSocket Protocol is an independent TCP-based protocol.  Its
only relationship to HTTP is that its handshake is interpreted by
HTTP servers as an Upgrade request.

i.e. WebSocket is not HTTP request-response, but a protocol that (ab)uses HTTP Upgrade for its handshake.
Granted, if the upgrade fails, then in theory request continues as a HTTP protocol, but I don't think that's supported by anything out there.
On top of that, GET with request body is undefined as well, since RFC7231, sec. 4.3.1 says:

A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.

FWIW, this is a tcpdump between Chrome & http://websocket.org/echo.html:
GET /?encoding=text HTTP/1.1
Host: echo.websocket.org
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://websocket.org
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,pl;q=0.8
Cookie: _ga=GA1.2.1696519655.1530136642; _gid=GA1.2.1985693603.1530136642; _gat=1; __zlcmid=n7hRtGQ5EUa36S
Sec-WebSocket-Key: JiUddN+YyhIb+TwvFCOFWA==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

HTTP/1.1 101 Web Socket Protocol Handshake
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Headers: authorization
Access-Control-Allow-Headers: x-websocket-extensions
Access-Control-Allow-Headers: x-websocket-version
Access-Control-Allow-Headers: x-websocket-protocol
Access-Control-Allow-Origin: http://websocket.org
Connection: Upgrade
Date: Wed, 27 Jun 2018 21:43:42 GMT
Sec-WebSocket-Accept: 2+qxxjue1vLopkSrGRTVv8nGZSk=
Server: Kaazing Gateway
Upgrade: websocket

No Content-Length: 0 (since it's implied for GET requests) or Transfer-Encoding weirdness.

Piotr, I'd be happy to block GET-with-body because I think it's an HTTP abomination, but where do you see that upgrades must be GETs?  From what I was reading they can be any valid HTTP request.
@rshriram again I'd really rather fully handle bodies or not handle bodies.  Right now the behavior allows T-E but is entirely broken and I don't like that state of affairs.   As said I also don't want to handle content-length style bodies and not TE as I've seen enough proxies which transform to be twitchy about handling one and not the other.
Once I land my in-flight refactor I'll push out my WIP for handling both body types and folks can say yea or nay on the complexity with code to look at.  SG?

https://tools.ietf.org/html/rfc6455#section-4.1:

The method of the request MUST be GET, and the HTTP version MUST be at least 1.1.

I agree with @PiotrSikora. Until we see a definite need, I'd say reject any body in an upgrade request.

I'm happy to change the existing implementation and my outstanding new mode to reject both and document we do not currently support upgrades with bodies. Before I go ahead and do that, @rshriram as the one person who wants body support could you comment why?

Not in request. I should have been clearer. Body support in the response. That said I just realized that we already support body in the response since the upstream connection is made as opaque tcp. Apologies for the confusion!

Ah, that makes much more sense.  @PiotrSikora and @ggreenway thoughts on this?  The code for handling response bodies is basically the same as request bodies so if there's a legit request I'd be inclined to just handle bodies.

What does opaque mean in this context?


Add unit testing for naming fix

Summary
add testing for https://github.com/linkedin/datahub-gma/pull/416
Testing Done
unit testing :)
To reproduce the issue, I modified the testing and UNDID 416's changes, resulting in:
> Task :dao-api:test

Gradle suite > Gradle test > com.linkedin.metadata.dao.utils.ModelUtilsTest.testDecorateValue FAILED
    java.lang.RuntimeException at ModelUtilsTest.java:753
        Caused by: java.lang.NoSuchMethodException at ModelUtilsTest.java:753

and
java.lang.RuntimeException: java.lang.NoSuchMethodException: com.linkedin.testing.EntityValue.hasDatahasInfo()
	at com.linkedin.metadata.dao.utils.ModelUtils.decorateValue(ModelUtils.java:949)
	at com.linkedin.metadata.dao.utils.ModelUtilsTest.testDecorateValue(ModelUtilsTest.java:753)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

So I know that this new testing does work as intended.
Checklist

[x] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[x] Links to related issues (if applicable)
[x] Docs related to the changes have been added/updated (if applicable)

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 67.58%. Comparing base (9e6a2e7) to head (615bd47).

Additional details and impacted files
@@            Coverage Diff            @@
##             master     #417   +/-   ##
=========================================
  Coverage     67.58%   67.58%
  Complexity     1522     1522
=========================================
  Files           137      137
  Lines          5954     5954
  Branches        644      644
=========================================
  Hits           4024     4024
  Misses         1659     1659
  Partials        271      271

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Add dev files to dockerignore

Closes #1488
Code Changes

[x] Added fides.toml to .dockerignore
[x] Removed login info from config files

Steps to Confirm

[x] Run test suite
[x] run nox -s build(dev)"` and verify builds with no errors
[x] run nox -s "build(prod)" and verify builds with no errors
[x] remove the volume from the fides section docker-compose.yml and verify the nox -s dev runs and works without issue.
[x] set the FIDES__CONFIG_PATH to the fides.test_env.toml file in the docker-compose.yml and verify nox -s dev runs and works without issue.

Pre-Merge Checklist

[ ] All CI Pipelines Succeeded
Documentation Updated:

[ ] documentation complete, or draft/outline provided (tag docs-team to complete/review on this branch)
[ ] documentation issue created (tag docs-team to complete issue separately)

[ ] Issue Requirements are Met
[ ] Relevant Follow-Up Issues Created
[ ] Update CHANGELOG.md

Description Of Changes
Write some things here about the changes and any potential caveats

@ThomasLaPiana can you try to build this and see what happens? When I run nox -s clean then nox -s "build(dev)" -- nocache the container still has the files that we added to the .dockerignore

For those following along:
It was the fault of the git reset --hard in the Dockerfile

@ThomasLaPiana tests are failing with container for service "fides" is unhealthy. Any idea what would cause this? I think at lease part of the problem is it looks like git is required in the test_cli.py test, and a requirement for this issue was to remove git from the container.

I ended up having to add git back because it is required in several places.

@ThomasLaPiana any ideas why the docs build won't pick up environment variables? It has all the environment variables it needs to create the database url, but it still isn't building it.

@sanders41 i'll hop in and do some troubleshooting

@sanders41 fides deploy is failing because it relied on default values being set, I'll fix by defining them in the sample fides.toml

@sanders41 this is the failure I'm seeing from the docs container:
 config.database.async_database_uri,
AttributeError: 'dict' object has no attribute 'async_database_uri'
nox > Command docker compose run --rm --service-ports --user=root docs /bin/bash -c 'pip install -e /fides && mkdocs build' failed with exit code 1

something with the config changes isn't right, it's causing this exact failure in both the docs and the deploy command

@sanders41 and I reviewed the full config one last time, and want to double-check the defaults for these settings:
dev_mode = true # does this default false?

[logging]
level = "DEBUG" # this should default to INFO

[security]
app_encryption_key = "atestencryptionkeythatisvalidlen" # triple-check
drp_jwt_secret = "testdrpsecret" # triple-check
root_username = "root_user" # triple-check
root_password = "Testpassword1!" # triple-check
oauth_root_client_id = "fidesadmin" # triple-check
oauth_root_client_secret = "fidesadminsecret" # triple-check

[user]
api_key = "test_api_key" # probably ignore?
encryption_key = "test_encryption_key" # remove?

Thanks @sanders41 - once this passes checks, we'll get it ready for landing.


[Snyk] Upgrade openrouteservice-js from 0.2.0 to 0.3.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade openrouteservice-js from 0.2.0 to 0.3.0.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 1 version ahead of your current version.
The recommended version was released a month ago, on 2023-04-20.

Release notes

Package name: openrouteservice-js

0.3.0 - 2023-04-20chore(release): 0.3.0

0.2.0 - 2022-06-10chore(release): 0.2.0

    from openrouteservice-js GitHub release notes

Commit messages

Package name: openrouteservice-js

2504198 Merge pull request #73 from GIScience/chore/release-0.3.0
ced6256 chore(release): 0.3.0
cb6aeef Merge pull request #72 from GIScience/refactor/BREAKING-remove-unused-properties
62d9afe refactor!: remove unused properties from library
5d34cd7 Merge pull request #71 from GIScience/build/update-dependencies
5f29873 build(deps): update to latest manageable dependencies
f4f6d55 Merge pull request #63 from GIScience/native-promise
ad479aa build: remove bluebird and superagent dependencies
c87c5ed build: update dist files
d2752b5 docs(README): adjust examples and add local instance example
f63e5ca test: adjust and increase coverage
0c336ee refactor: split createRequest parts to new fetchRequest function
3270f5b feat: replace superagent 'request' with native 'fetch()'
56d06bd refactor: move from explicit Promises to async functions
6de4c14 refactor: remove bluebird import
222abf5 Merge pull request #70 from GIScience/refactor/BREAKING-remove-unused-functions
d372680 docs(README): remove clear() usage from examples
fff7398 test: remove tests for removed functions
441fd38 refactor: remove unused functions
d2af9b1 Merge pull request #69 from GIScience/fix/geocode-request-args
ed2e491 fix: reqArgs in structuredGeocode to this.requestArgs
e8bf723 build(deps): Run npm audit fix
eae46ec build(deps): Update superagent to v8.0.9
7bfdf96 Merge pull request #58 from GIScience/feature/increase-coverage

Compare

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

superseded by https://github.com/GIScience/ors-map-client/pull/393


Sqlite score database for replays + Input handling rewrite

Sqlite score database for replays instead of using the filesystem. This change is not backwards compatible. Player name can be set in game.cfg (defaults to "ARK").
Database code is just found in scores.c. The database design could use a bit more planning and we could save more important things to the player data table instead of a career-tetris-count.
Speaking toward the database design:

The data is not normalized right now. So, for example, replay data is completely tied to score data. If having replay data and having score data don't imply each other in the future, we would need an upgrade strategy to normalize the data.
The scores table uses shiromino values for grades, modes, etc. Maybe a view can be created for more human-readable data.

Refactored a lot of the replay code in replay.c. Packed replay input data into single bytes instead of saving bytes that store how long the button has been held. This required rewriting the input code to use hold_dir and hold_time variables. See core.c for the bulk of those changes. Perhaps we can get rid of the old keyflags and instead always use the packed input data?
A side-effect of the change is that I wasn't meticulous in preserving the old behavior 100% and I feel like the timings are a bit off.
EDIT:
Lock protection doesn't seem to work, I don't know if it was working before.

There was some worry that the frame timings had been made inaccurate. This is still not certain but I'm about 95% sure everything's all fine, so I'm going ahead with this so we can start focusing on the move to C++.


[DO-NOT-MERGE] Enabled GPR_ABSEIL_SYNC

Let's try this out again with #21606.
Things to be addressed.
Ruby artifacts based on manylinux2010
Currently Ruby artifacts are generated on the Ubuntu 16.04 via rake-compiler-dock, which works for most Linux distribution but not CentOS 6 because of its old version of glibc. This can be solved by using CentOS 6 based docker images when generating artifacts. WIP in #23344.
bundler: failed to load command: ./distribtest.rb (./distribtest.rb)
LoadError: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by /usr/local/rvm/gems/ruby-2.3.8/gems/grpc-1.31.0.dev-x86_64-linux/src/ruby/lib/grpc/2.3/grpc_c.so) - /usr/local/rvm/gems/ruby-2.3.8/gems/grpc-1.31.0.dev-x86_64-linux/src/ruby/lib/grpc/2.3/grpc_c.so

Bazel RBE MSAN C/C++ failures
Since Abseil doesn't like threads running after the main exits, MSAN tests particularly claim that they have errors. Currently it has 23 failed targets. (ref)

//test/core/debug:stats_test
//test/core/end2end:h2_* (12 ea)
//test/core/handshake:client_ssl_test@poller=epoll1
//test/core/handshake:server_ssl_test@poller=epoll1
//test/core/security:tls_security_connector_test@poller=epollex
//test/cpp/grpclb:grpclb_api_test@poller=poll
//test/cpp/microbenchmarks:bm_* (5 ea)

grpc_build_artifacts_multiplatform: passed except ruby

With #23378, msan failures became better and remaining failures are

//test/core/end2end:h2_proxy_nosec_test@empty_batch@poller=epoll1
//test/cpp/microbenchmarks:bm_callback_streaming_ping_pong@poller=epollex
//test/cpp/microbenchmarks:bm_cq@poller=epoll1
//test/cpp/microbenchmarks:bm_cq@poller=epollex
//test/cpp/microbenchmarks:bm_error
//test/cpp/microbenchmarks:bm_fullstack_streaming_ping_pong@poller=epollex
//test/cpp/server:server_builder_with_socket_mutator_test@poller=poll
//test/cpp/util:slice_test

Tested with #23344: grpc_build_artifacts_multiplatform: running

grpc_build_artifacts_multiplatform: running

grpc_build_artifacts_multiplatform: running

All failures from Bazel RBE MSAN C/C++ and Bazel RBE Windows Debug C/C++ are not relevant to this.

@yang-g Thanks! I already pressed the merge button but I'm running the test internally.


fix: Updated sorting/comb_sort.cpp

Updated sorting/comb_sort.cpp according to issue #1443

@ayaankhan98 please use squash-merge. Thank you. 🙂


Bcmoham winter23

Updated API version to V53 and added the identifier in flexipages
Update to scratch org bash file from 7 days to 15 days
Added RecordTypeId in comm-account.json

All checks including build check pass.
Merging to main


[Github] Remove deprecation of AppSystemTestBehaviour

Hey,
Recently, I tried to secure app scripts for a customer using unit tests.
However, I couldn’t find any documentation on how this is supposed to be done.
In the end, I just created a unit test in the project that ensures the app is installed and loaded using loadAppsFromDir.
Therefore, the edited trait shouldn't be marked as internal with version 6.7.
Is there another way to handle this?
I also didn’t find any changelog entry regarding the deprecation.

Imported from Github. Please see: https://github.com/shopware/shopware/pull/5179

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

[public] FixVersion Changed: This issue will be / was solved in Shopware version <IP_ADDRESS>.
[created from NEXT-39224, comment 508056]


Uncaught Error In CassandraHostRetryService.verifyConnection Can Kill RetryRunner

There is a non-zero chance of a java.lang.Error stopping subsequent executions of the RetryRunner task.
CassandraHostRetryService.verifyConnection should catch and log Throwable instead of Exception. Also, it would be nice if that log message included the affected host.

In the end, the error turned out not to be originating in verifyConnection, however verifyConnection should probably still catch Throwable instead of Exception in order to be able to not interrupt checks for other hosts.
Pull request to follow...


Remove code which transforms stringified array into array

This fixes https://github.com/waterlinejs/postgresql-adapter/issues/5 based on how node-postgres expects json values to be passed.

Any thoughts regarding this @tjwebb? Think it is needed (to properly handle json)

Bump. Nudge. @tjwebb


Loading SCSS with the ?url flag causes the import to fail

[x] Read the docs.
[x] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
[x] This is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.

Describe the bug
Similar to #2455, when importing SCSS into a JS file, with the ?url flag, the import will fail.
A related, but apparently different bug, is that if ?url is used with a CSS file, it evaluates to a string like export default "/src/style.css". This may deserve a separate issue.
Reproduction
This can be reproduced with:

yarn create @vitejs/app --template vue vite-sample; cd
yarn add sass
Create src/style.scss
Add an import to App.vueimport data from "./style.scss?url"
console.log(data)

Error in console
[plugin:vite:css] expected "{".
  ╷
1 │ export default "/src/style.scss"
  │                                 ^
  ╵
  src/style.scss 1:33  root stylesheet
/home/jonathan/src/git.ec2software.com/jonathan/vite-sample/src/style.scss:1:33
    at Object._newRenderError (/home/jonathan/src/git.ec2software.com/jonathan/vite-sample/node_modules/sass/sass.dart.js:13537:19)
    at Object._wrapException (/home/jonathan/src/git.ec2software.com/jonathan/vite-sample/node_modules/sass/sass.dart.js:13374:16)
    at _render_closure1.call$2 (/home/jonathan/src/git.ec2software.com/jonathan/vite-sample/node_modules/sass/sass.dart.js:80373:21)
    at _RootZone.runBinary$3$3 (/home/jonathan/src/git.ec2software.com/jonathan/vite-sample/node_modules/sass/sass.dart.js:27269:18)
    at _FutureListener.handleError$1 (/home/jonathan/src/git.ec2software.com/jonathan/vite-sample/node_modules/sass/sass.dart.js:25797:19)
    at _Future__propagateToListeners_handleError.call$0 (/home/jonathan/src/git.ec2software.com/jonathan/vite-sample/node_modules/sass/sass.dart.js:26094:49)
    at Object._Future__propagateToListeners (/home/jonathan/src/git.ec2software.com/jonathan/vite-sample/node_modules/sass/sass.dart.js:4543:77)
    at _Future._completeError$2 (/home/jonathan/src/git.ec2software.com/jonathan/vite-sample/node_modules/sass/sass.dart.js:25927:9)
    at _AsyncAwaitCompleter.completeError$2 (/home/jonathan/src/git.ec2software.com/jonathan/vite-sample/node_modules/sass/sass.dart.js:25270:12)
    at Object._asyncRethrow (/home/jonathan/src/git.ec2software.com/jonathan/vite-sample/node_modules/sass/sass.dart.js:4292:17
Click outside or fix the code to dismiss.
You can also disable this overlay with hmr: { overlay: false } in vite.config.js.

System Info

vite version: 2.1.0
Operating System: Arch Linux
Node version: v15.10.0
Package manager (npm/yarn/pnpm) and version: yarn

Logs (Optional if provided reproduction)

Run vite or vite build with the --debug flag.
Provide the error log here.

What do you expect to get by appending ?url to an SCSS file? Multiple CSS files are going to be concatenated into one file during build so it's not a 1 to 1 mapping like static assets.

My expectation would be to point the the resulting CSS after compilation, so I can have a link tag that I inject at runtime reference it, so in development it would be /src/style.scss (which the vite dev server compiles on request) and in production it would be dist/assets/style.b4186631.css or whatever is output.
If I understand, the problem of what to do is that the styles are concatenated, scoped to the JS, but I'm trying to reference a style directly, so it may be part of one or more bundles that's associated with various scripts, not a single CSS bundle for that SCSS entrypiont.
The usecase I'm trying to solve is scoping my CSS inside of a shadow DOM element. Another domain is including a script from my site to get a component. I want to omit adding the CSS until I manually add it to the shadow node.

Same problem for me basically. We want to load different SCSS files for different pages and use React Helmet for that and would like to point to the URL of the file dynamically instead of having Vite appending the style automatically to the page.

Any progress yet? I am facing a similar scenario when dealing with shadowdom, need to get scss compilation result and inject a preload link into head

I've started some hacking on it #4604 for a few hours, but the build tools are bringing my poor machine to its knees. (It's pretty old and lightweight.) Sorry for dropping my brain dump here.
Here's what I've learned so far. It looks like most of the relevant (development) changes will be made in packages/vite/src/node/plugins/css.ts

Using fd0a0d9bcaf0fd9098c5eb1a0c53226575fdcccb as an example, getting ?url to return. (I have a  hacky solution with detecting the ?url, I didn't look too hard for the correct way to get that.); avoids the compile error.
When directly accessing a css preprocessed file, vite behaves differently when a JS/TS/etc file imports it.

If a js file imports /src/style.scss, the dev server returns JS that appends the compiled CSS to the document
If no js file imports /src/style.scss, the dev server returns the raw source code (not compiled)
The css source file needs to be resaved for the dev server to update the result (it's cached across restarts)

vite build doesn't produce an output for /src/style.scss even if it's imported with or without ?url
vite build adds stylesheet links to the built HTML with the compiled css.

Development Server
Number 2 above, probably doesn't matter. the import behavior for JS is necessary for the intended behavior. I'm thinking if you import /src/style.scss it should return export default "/src/style.scss?compiled", then a new ?compiled query would return the results of compiling the source file.
Build
Based on behavior, I'm guessing there is some sort of registration when a CSS import is encountered in a script file.  I'm hoping it wouldn't be too difficult to register a new css file (the manifest already returns an array of css files per JavaScript file) and output the css linked similarly as a normal CSS file and inline the URL in. I haven't looked at the build portion too much.

The same error happens when using raw for scss files (import text from './src/style.scss?raw')

The behavior of referencing CSS and SCSS in Vue files is also different。
when use CSS:
=== App.vue ==
<template>

div1

div2

</template>

=== ./div1.css ===
.div1{
    background-image: url(./assets/logo.png);
    width: 80px;
    height:80px;
}

=== ./style/div2.css ==
.div2{
    background-image: url("../assets/logo.png");
    width: 80px;
    height:80px;
}

Compilation results:
.div1[data-v-243a7a0a]{
    background-image:url(./logo.03d6d6da.png);
    width:80px;
    height:80px
}
.div2[data-v-243a7a0a]{
    background-image:url(./logo.03d6d6da.png);
    width:80px;
    height:80px
}

The same code  rename css to scss:
Compilation results:
.div1[data-v-12b736e0]{
    background-image:url(./logo.03d6d6da.png);
    width:80px;
    height:80px
}
.div2[data-v-12b736e0]{
    background-image:url(../assets/logo.png);
    width:80px;
    height:80px
}

"background-image:url(../assets/logo.png); " is error in div2.

I don't care if scss file has its compiled css's url, but I think css file should get its url.
import cssUrl from 'someCssFile.css?url' : syntax like this should be supported.
however:
import compiledCssUrl from 'someScssFile.scss?url' : this has different meanings
I think we should write it like:
import scssUrl from 'someScssFile.scss?url'
import compiledCssUrl from 'someScssFile.scss?url?scss'

My use case is when using CSS within a Web Component. So:
import css from '../styles/webcomponent.css?url';
console.log(`Static import: ${css}`); // Static import: export default "/styles/webcomponent.css"

// vs

const  css = new URL('../styles/webcomponent.css', import.meta.url).href;
console.log(`Import meta: ${css}`); // Import meta: http://localhost:3000/styles/note.css

Import meta works fine, but I guess the stylesheet isn't processed? Correct me if I'm wrong. I'm not using some plugin yet (e.g.: autoprefixer), so I can't say for sure.

Want to mention that the behavior for import styles from './styles.css?url' is inconsistent between production and development.
During production, it returns a Data URL, while in development it returns the path to the file. That seems okay-ish, but neither point to the concatenated output file (which doesn't exist in development).

Same issue devs! Any updates on this?

Same issue. My team needs to have fine control over the order/position at which css files are added to the DOM, hence we cannot rely on vite's built-in css import handler and must manually create <link rel="stylesheet" href="...">. We need the capability to get the asset url from css files for this work.
The only work around we can  think of is renaming the .css as .txt, import it as ?raw, and manually set the


QCharts

Is there any way to include specific modules like QCharts into the install process?

In version 0.5, it try to install all of extra modules like qcharts, but not the all.
In version 0.6a1 and later, aqt has an option '-m' or '--module' that accept list of extra modules such as
$ python -m aqt install 5.14.0 linux desktop -m qcharts,qtnetworkauth

fantastic. works like a charm.


Correct SparseVector.parse documentation

There's a small typo in the SparseVector.parse docstring (which says that it returns a DenseVector rather than a SparseVector), which seems to be incorrect.

Can one of the admins verify this patch?

LGTM

Jenkins test this please

Test build #51353 has started for PR 11213 at commit 1e73745.

Test build #51353 has finished for PR 11213 at commit 1e73745.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/51353/
Test PASSed.

Merged to master/1.6


Need support cn-northwest region at AWS

Rancher versions:
rancher/server: v2.0.0-alpha12
can not support cn-northwest-1 region at AWS

cn-northwest-1  is supported now

We need to update docker-machine to 0.15 from 0.14 to support cn-northwest-1.

@loganhz rancher is updated to machine v0.15.0, can you add that region to the list in the UI?

It’s already in. I guess we can close it now.

Verified fixed and close it. master 07/25.


Added view configuration to SheetView

Hi @xuri
I'm adding an additional configuration, for how sheet is presented:
Normal:
<sheetViews>
    <sheetView workbookViewId="0" tabSelected="1"/>
</sheetViews>

Page Break Preview: view="pageBreakPreview"
<sheetViews>
    <sheetView workbookViewId="0" zoomScaleNormal="100" zoomScale="60" view="pageBreakPreview" tabSelected="1"/>
</sheetViews>

Page Layout: view="pageLayout"
<sheetViews>
    <sheetView workbookViewId="0" zoomScaleNormal="100" view="pageLayout" tabSelected="1"/>
</sheetViews>

Codecov Report

Merging #1136 (d5ecbfb) into master (156bf6d) will decrease coverage by 0.02%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master    #1136      +/-   ##
==========================================
- Coverage   98.22%   98.20%   -0.03%
==========================================
  Files          29       29
  Lines       18622    18626       +4
==========================================
  Hits        18292    18292
- Misses        224      228       +4
  Partials      106      106

Flag
Coverage Δ

unittests
98.20% <0.00%> (-0.03%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

sheetview.go
94.36% <0.00%> (-5.64%)
:arrow_down:

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 156bf6d...d5ecbfb. Read the comment docs.

LGTM, thank you.


Add empty and stacked indexes

Fixes #142

Draft for now, because of the 3.2.0 target. Other than that, this should be ready.


Support explicitly passing in local files in options.stylsheets

This PR addresses the issues in #329.

Coverage increased (+1.8%) to 98.901% when pulling e2d0ff5f83d40a5fe7137b65a108cf1c7302c11c on tobek:master into e7aba63301e762997ca1abb82e64e46aaf2b170f on giakki:master.


Code not working on VS2017 RC 2

Thank you very much for the tutorials but unfortunately your code is not working on VS2017 RC 2. First of all there is no project.json file in  VS2017 RC 2. When I managed that, new errors came shortly: namely AddIdentityServer(), since the service thus not have that method.
I could not event run the application! (Running http://localhost:5000/.well-known/openid-configuration step in https://identityserver4.readthedocs.io/en/dev/quickstarts/1_client_credentials.html)
You know identityserver better than me but I believe that you have to design the document step-by-step without ignoring any tiny detail and jumping from one place to another.(eg, adding identity models before adding ApiResource). I also believe, the document should reflect latest implementation in visual studio also.
Can you please update the documentation please?
Thank you very much.

Thank you very much for the tutorials but unfortunately your code is not working on VS2017 RC 2

Given how unstable the Microsoft tooling has been for the past year (or more), we didn't see the value in trying to support VS 2017 at this time. Once they RTM we will support it.


Wrong service file loaded in native mode after upgrading Mandrel from <IP_ADDRESS> JDK 17.8 to <IP_ADDRESS> JDK 21.0

Before the upgrade the service loader has loaded the resource META-INF/services/org.apache.cxf.bus.factory from the application runner quarkus-cxf-integration-test-mtom-awt-2.5.0-SNAPSHOT-runner.jar but now after the Mandrel upgrade, the resource is loaded from a dependency org.apache.cxf:cxf-core.

@zakkak @galderz is there any way to get back to the old behavior (which is BTW consistent with the JVM mode)?

@ppalaga can you please provide a reproducer? It sounds like a GraalVM bug to me, but would need to have a look at it first.

Here is how to reproduce:
git clone git@github.com:quarkiverse/quarkus-cxf.git
cd quarkus-cxf
# the commit that upgrades to Quarkus 3.5.0
# there is a workaround in the main branch right after it,
# so being at this particular commit is important
git reset --hard fea5378251d6aa98f6dad12dbbf4dc796d303e74
# build the whole source tree
mvn clean install -DskipTests -Dquarkus.build.skip -Denforcer.skip
# run some native test
mvn clean verify -Pnative -Dquarkus.native.container-build
...
[ERROR]   MtomAwtIT>MtomAwtTest.uploadDownloadMtom

The root cause is that org.apache.cxf.BusFactory.getBusFactoryClass(ClassLoader) sees the default META-INF/services/org.apache.cxf.bus.factory from cxf-core rather than the one that we write into the application at build time (implemented around here )
And so the BusFactory loads the default implementation instead of our custom io.quarkiverse.cxf.QuarkusBusFactory

The issue is introduced by https://github.com/oracle/graal/commit/d5000f4146e66faaa4d79cd80c5b3274fcf12e14 I will have a better look probably next week.
@olpaw FYI

This feels like a native image bug if not possible to have similar semantics as jvm?

Correct

The issue is introduced by oracle/graal@d5000f4 I will have a better look probably next week.
@olpaw FYI

Wrong mention... Sorry Paul. cc @chumer

Upstream Graal fix: https://github.com/oracle/graal/issues/7678

The upstream fix has been merged and should land in GraalVM for JDK 22 and Mandrel 24.0. A backport request is pending to get the fix in GraalVM for JDK 17 and Mandrel 23.1 as well.

Thanks a lot, @zakkak!

I am closing this leaving the workaround in place.

The upstream fix has been merged and should land in GraalVM for JDK 22 and Mandrel 24.0. A backport request is pending to get the fix https://github.com/oracle/graal/pull/7957#issuecomment-1841664895 and https://github.com/graalvm/mandrel/issues/629.

FTR the upstream fix will land in land in GraalVM for JDK 21 and Mandrel 23.1 in the upcoming January CPU releases.


Composite primary key panic: Too many rows found.

Describe the bug
Panic while running init on a table with a composite primary (3 column)
reform-db: 2021/01/18 13:36:59.455251 cmd_init.go:117: ColumnName: `scope_value` (string), OrdinalPosition: 3 (int)
reform-db: 2021/01/18 13:36:59.455258 cmd_init.go:117: ColumnName: `scope` (string), OrdinalPosition: 2 (int)
reform-db: 2021/01/18 13:36:59.455269 cmd_init.go:117: ColumnName: `key` (string), OrdinalPosition: 1 (int)
reform-db: 2021/01/18 13:36:59.455275 cmd_init.go:135: Too many rows found. Please report this bug.
panic: Too many rows found. Please report this bug.

goroutine 1 [running]:
gopkg.in/reform.v1/internal.(*Logger).Fatalf(0xc000400340, 0xad8583, 0x2c, 0x0, 0x0, 0x0)
	/home/ism/go/src/gopkg.in/reform.v1/internal/logger.go:51 +0xea
main.getPrimaryKeyColumn(0xc000414b00, 0xc0004069fa, 0x6, 0xc000406a00, 0x6, 0xc000406a06, 0x6, 0x0)
	/home/ism/go/src/gopkg.in/reform.v1/reform-db/cmd_init.go:135 +0xb16
main.initModelsInformationSchema(0xc000414b00, 0xad3f0c, 0x25, 0xae7178, 0x0, 0xc000061660, 0x1233400)
	/home/ism/go/src/gopkg.in/reform.v1/reform-db/cmd_init.go:157 +0x2ad
main.cmdInit(0xc000414b00, 0xc00002c034, 0x22)
	/home/ism/go/src/gopkg.in/reform.v1/reform-db/cmd_init.go:202 +0xc4d
main.main()
	/home/ism/go/src/gopkg.in/reform.v1/reform-db/main.go:146 +0x500

To Reproduce
Create a table with more than one column in the primary key
Expected behavior
for reform to either deal with composite primary keys or quietly skip it for that table, currently cmd_init.go seems to panic if the number of columns involved is larger than 1 but also has a warning if it is equal to 1 if OrdinalPosition is bigger than 1 which I do not think is a case that can happen

What database is that? And please provide a CREATE TABLE statement

What database is that? And please provide a CREATE TABLE statement

Postgres 12.5
I assume it'll happen irregardless of table structur so long that the PRIMARY KEY constraint is on more than one column
CREATE TABLE public.config (
    revision integer DEFAULT 0,
    cga uuid,
    key text NOT NULL,
    scope public.config_scopes NOT NULL,
    scope_value text NOT NULL,
    value jsonb DEFAULT 'null'::jsonb NOT NULL,
    created_at timestamp with time zone DEFAULT CURRENT_TIMESTAMP NOT NULL,
    updated_at timestamp with time zone DEFAULT CURRENT_TIMESTAMP NOT NULL
);

ALTER TABLE ONLY public.config ADD CONSTRAINT config_pkey PRIMARY KEY (key, scope, scope_value);

Postgres 12.5
I assume it'll happen irregardless of table structur so long that the PRIMARY KEY constraint is on more than one column
CREATE TABLE public.config (
    revision integer DEFAULT 0,
    cga uuid,
    key text NOT NULL,
    scope public.config_scopes NOT NULL,
    scope_value text NOT NULL,
    value jsonb DEFAULT 'null'::jsonb NOT NULL,
    created_at timestamp with time zone DEFAULT CURRENT_TIMESTAMP NOT NULL,
    updated_at timestamp with time zone DEFAULT CURRENT_TIMESTAMP NOT NULL
);

ALTER TABLE ONLY public.config ADD CONSTRAINT config_pkey PRIMARY KEY (key, scope, scope_value);

Thanks, I will take a look

Thanks, I will take a look


Add CASE_SENSITIVE_EQUAL threshold

Finally got around to implementing this. This PR adds a new threshold called CASE_SENSITIVE_EQUAL which trumps all other matches, as discussed in #20.
I've also added a few tests and updated the README accordingly.
Let me know if you have any feedback or would like me to make any changes :)

Current coverage is 100% (diff: 100%)

Merging #22 into master will not change coverage

@@           master   #22   diff @@
===================================
  Files           1     1
  Lines          78    82     +4
  Methods         0     0
  Messages        0     0
  Branches        0     0
===================================
+ Hits           78    82     +4
  Misses          0     0
  Partials        0     0

Powered by Codecov. Last update eacc0e9...20c4221

This is perfect! Thanks!

LGTM


Investigate 500 responses

Here's a few representative errors. It's not sequestered to just one api, or source, so at first glance, I don't see anything amiss.
[2015-03-31 14:57:15] mollusk.DEBUG: That entry? It's the CitySen Lounge [] []
[2015-03-31 14:57:15] mollusk.CRITICAL: >>>>>>>> GET /location/foursquare/4e1f7814b61c8ce9c7cd2b68
[2015-03-31 14:57:26] mollusk.DEBUG: That entry? It's the Field & Fire Bakery [] []
[2015-03-31 14:57:26] mollusk.CRITICAL: >>>>>>>> GET /location/foursquare/52234e3a498e569a19ca3a5e
[2015-03-31 14:57:41] mollusk.DEBUG: That entry? It's the Urban Institute for Contemporary Arts [] []
[2015-03-31 14:57:41] mollusk.CRITICAL: >>>>>>>> GET /location/foursquare/4b2bd7b0f964a5202abc24e3
[2015-03-31 14:57:51] mollusk.DEBUG: That entry? It's the Premier Skateboarding [] []
[2015-03-31 14:57:51] mollusk.CRITICAL: >>>>>>>> GET /location/facebook/233021996762657
[2015-03-31 14:58:36] mollusk.ERROR: Server error response [url] http://dgri-mantle.herokuapp.com/photos/instagram/facebook/339653176124537 [status code] 500 [reason phrase] Internal Server Error [] []
[2015-03-31 14:58:36] mollusk.DEBUG: YoChef Café PHOTOS is empty, not growing anything. [] []
Here is the full log from today's run... http://d.pr/f/19DOb

@janson Let me know if you encounter any more 500s.

Latest number of changes in #22 should address the rest of the issues.


Predictoor agent issues: (a) New blocks have 0 topics (b) README doesn't specify to use publisher

To reproduce
Go through predictoor.md flow

Where barge is run on branch issue374-replace-pdr-components-with-pdr-backend.
Until running main random predictoor.

(venv) trentmc@tlm-macbook:~/code/pdr-backend $ python3 pdr_backend/predictoor/main.py
<EMAIL_ADDRESS>can't open file '/Users/trentmc/code/pdr-backend/pdr_backend/predictoor/main.py': [Errno 2] No such file or directory
(venv) trentmc@tlm-macbook:~/code/pdr-backend $ python3 pdr_backend/predictoor/approach1/main.py
Starting main loop...
HTTPConnectionPool(host='<IP_ADDRESS>', port=8000): Max retries exceeded with url: /subgraphs/name/oceanprotocol/ocean-subgraph (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x124629a90>, 'Connection to <IP_ADDRESS> timed out. (connect timeout=1.5)'))
Got new block: 26197 with 0 topics
HTTPConnectionPool(host='<IP_ADDRESS>', port=8000): Max retries exceeded with url: /subgraphs/name/oceanprotocol/ocean-subgraph (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x124634750>, 'Connection to <IP_ADDRESS> timed out. (connect timeout=1.5)'))
Got new block: 26198 with 0 topics
HTTPConnectionPool(host='<IP_ADDRESS>', port=8000): Max retries exceeded with url: /subgraphs/name/oceanprotocol/ocean-subgraph (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x124637450>, 'Connection to <IP_ADDRESS> timed out. (connect timeout=1.5)'))
Future errors like this will be hidden
Got new block: 26200 with 0 topics
Got new block: 26201 with 0 topics
Got new block: 26203 with 0 topics
Got new block: 26204 with 0 topics
Got new block: 26206 with 0 topics
Got new block: 26207 with 0 topics
Got new block: 26209 with 0 topics
Got new block: 26210 with 0 topics
Got new block: 26212 with 0 topics
Got new block: 26213 with 0 topics
Got new block: 26215 with 0 topics
Got new block: 26216 with 0 topics

Perhaps a key thing: I'm not sure if i ran publisher or not before. (The README doesn't specify to do this, but I may have done it separately.) That would be the first thing to check.
Trent to Berkay: But I'm a bit worried. It keeps saying "0 topics". It should give topics sometime, no?
Berkay: (implied yes. And): Yes did you run pdr publisher? If yes, could you inspect the logs
Trent: First: is it (a) the assets are not published and pdr publisher supposed to be run before anything else, or (b) the assets are already published, we just have to look int he right place.  If (a) , we need to add publishing to the README flow.
Berkay: It is probably a, if the logs show that the deployments were successful then it could be a subgraph issue
Trent: I had run publisher separately to do some of my own testing. It seems that it did publish successfully. Then it likely is a subgraph issue. [OR a publishing issue!!]
Berkay: Ah I guess so, could you try to query subgraph to see if there are any predict contracts:
http://localhost:9000/subgraphs/name/oceanprotocol/ocean-subgraph/graphql?query=query+MyQuery+{
++predictContracts+{
++++id
++++token{
++++++name
++++}
++}%0A}

Update 1: I wasn't able to load the subgraph queries. Turns out that barge wasn't doing --with-graph. I reported that and fixed it in #80.
Then I did do the query suggested by Berkay above. Result: no results. See attached.

Berkay: they aren't deployed yet
Trent: But what does the --with-pdr-publisher argument in barge do then?
Berkay: It should deploy once the contracts are ready
Berkay: You can inspect the logs of the container docker ps to find the id then docker logs -f {id}
Trent: it doesn't have pdr-publisher
Berkay: Publisher is dead, docker ps -a should display it
Trent: found it
pdr-publisher-log.txt

Trent:
Great news, it [the query] works!

(For reference, at the url like above. http://localhost:9000/subgraphs/name/oceanprotocol/ocean-subgraph/graphql?query=que[…]%0A++++id%0A++++token%7B%0A++++++name%0A++++%7D%0A++%7D%0A%7D)
I didn't know how to filter docker logs before. That was super useful. I could monitor as publisher was doing its things, then subgraph. Once subgraph was done compiling, the query worked. So, thank you overall!!
  502  docker ps -a
  503  docker ps |grep publis
  504  docker logs -f 2feaf3f786a8
  505  docker ps |grep subgraph
  506  docker logs -f dd680cfd046

Trent: now, back to this issue.
And... still not working :(
(venv) trentmc@tlm-macbook:~/code/pdr-backend $ python3 pdr_backend/predictoor/approach1/main.py
Starting main loop...
HTTPConnectionPool(host='<IP_ADDRESS>', port=8000): Max retries exceeded with url: /subgraphs/name/oceanprotocol/ocean-subgraph (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x116b22c50>, 'Connection to <IP_ADDRESS> timed out. (connect timeout=1.5)'))
Got new block: 804 with 0 topics
HTTPConnectionPool(host='<IP_ADDRESS>', port=8000): Max retries exceeded with url: /subgraphs/name/oceanprotocol/ocean-subgraph (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x116b31650>, 'Connection to <IP_ADDRESS> timed out. (connect timeout=1.5)'))
Got new block: 805 with 0 topics
HTTPConnectionPool(host='<IP_ADDRESS>', port=8000): Max retries exceeded with url: /subgraphs/name/oceanprotocol/ocean-subgraph (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x116b3c390>, 'Connection to <IP_ADDRESS> timed out. (connect timeout=1.5)'))
Future errors like this will be hidden
Got new block: 807 with 0 topics
Got new block: 808 with 0 topics
Got new block: 810 with 0 topics
Got new block: 811 with 0 topics
Got new block: 813 with 0 topics
Got new block: 814 with 0 topics
Got new block: 816 with 0 topics
Got new block: 817 with 0 topics
Got new block: 819 with 0 topics
Got new block: 820 with 0 topics
Got new block: 822 with 0 topics
Got new block: 823 with 0 topics


fix issues

Problem
Describe the purpose of this change. What problem is being solved and why?
Solution
Describe the approach you took. Link to any relevant bugs, issues, docs, or other resources.
Type of Change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[ ] Infrastructure change (CI configs, etc)
[ ] Non-code change (docs, etc)
[ ] None of the above: (explain here)

Test Plan
Describe specific steps for validating this change.

in a comment? So: index_name = 'gpt-4-langchain-docs'  # metadata : parameters

View entire conversation on ReviewNB

no its on the cell metadata, anyway, i edited it

View entire conversation on ReviewNB


TypeScript defintions

added support for TypeScript
no need to anything special from the user. in the new version of TS. npm install is enough :)

What is required RE: maintenance?

just update the definition file if needed

i've made this definition to some tiny experiment i wrote using this library and i would like to create it in TypeScript.
also i saw that glimmer is now in TypeScript, so maybe someone who developed glimmer will have some input about this commit.

Unless this definition is enforced (I.e. the tests fail when the definition is out of sync) I'm not sure we should land this.

it's totally your decision. i did this anyway for myself, and i can totally understand if doesn't align with this project needs.
since this project isn't updated very often, it seems to me it's a plus (and it will make my life a bit easier (-;).
but if this addition will be a burden for you. i totally understand if you won't merge this PR.

It is pretty awesome that you took the time to do this, please don't get me wrong! I am just not an expert TypeScripter so I have no clue what it would take to maintain over time.
Maybe @wycats / @chancancode / @krisselden have a better understanding.

NOTE for myself:
here change to:
    attributes?: [string, string, boolean | void][];

i've fixed a few things and added some types. tell me if rebase is needed

Any new? It seems it won't be ever be merged so I have no idea if I should fix conflicts and updated as needed or just close the PR. Both options are fine with me

@oriSomething can you rebase? :)

Sorry @oriSomething, I misspoke! I want to thank you for your work, but we are working on converting the whole project to TypeScript, which would include generating typings when publishing :)
If you want to help with the conversion ping me, I'm trying to figure it out myself 😁

@locks I would really glad to help, but unfortunately I don't have the time right now, and if an employer doesn't need me to fix something in some OSS project, I barely have the time off work. I wish I could say I'll have a time in a month or two, but you can ask @rwjblue I say for too long 😞


styled.keyframes.withConfig is not a function

Reopening https://github.com/styled-components/babel-plugin-styled-components/issues/213 as I'm still experiencing this issue despite the suggestion provided.
I'm using v3.4.10 of styled-components and v1.10.0 of babel-plugin-styled-components. This is what I'm using in my component :
import styled, { keyframes } from 'styled-components'

const rotate = keyframes`
  from {
    transform: rotate(0deg);
  }

  to {
    transform: rotate(360deg);
  }
`

This is bundled (wrongly ?) into the following :
var rotate = styled.keyframes(['from{transform:rotate(0deg);}to{transform:rotate(360deg);}']);

Same problem here...

I have the same issue. Any idea what is the root cause?

+1

My issue was that I had a bad test file that I forgot to delete and this error was thrown out of place.

Also having the same issue, not sure what's going on.

Hi, we're also experiencing this using. When we build a React component using babel, we see the following output:
styled.keyframes.withConfig is not a function
FAIL  packages/Video/__tests__/Video.spec.jsx
  ● Test suite failed to run
    TypeError: styled.keyframes.withConfig is not a function
      227 |
      228 | var zindexPopover = 1600;
    > 229 | var spinnerRotate = styled.keyframes({
          |                  ^
      230 |   '100%': {
      231 |     transform: 'rotate(360deg)'
      232 |   }

This is what I'm using. Also, is support for styled components v4 still in active development?

Package
Version

babel-plugin-styled-components
1.10.0

jest-styled-components
7.0.0-2

jest
24.8.0

react
16.8.6

styled-components
4.2.1

How are you importing styled? keyframes is a named export so you have to bring it in like this:
import { keyframes } from 'styled-components';

@probablyup we are importing styled as a default export and keyframes as a named export as you've described. I updated my comment above to include links to the source code I'm working through. Please have a look.

We probably just need another check here to make sure we aren't transpiling styled.keyframes: https://github.com/styled-components/babel-plugin-styled-components/blob/e3829d28f2b460e097f1499f6091a52b667ef1b4/src/visitors/displayNameAndId.js#L142

I have a strong suspicion this is something to do with environment setup. I have a lot of complex projects using all parts of s-c and have never seen this behavior.

I am also seeing this when trying to run jest in a project consuming multiple component libraries built with styled components.
I was getting caught on one component lib, but removing it from my transformIgnorePatterns solved the issue for that lib.
Now a different component lib is throwing the same error, however, this lib isn't in my transform ignore patterns or having anything special done to it.
I also don't see anything in that component libraries config that would be the root cause.

Package
Version

babel-plugin-styled-components
1.10.0

jest-styled-components
7.0.0-2

jest
24.5.0

react
16.8.6

styled-components
4.2.0

We could probably just filter styled.keyframes from https://github.com/styled-components/babel-plugin-styled-components/blob/master/src/utils/detectors.js?

Seeing a very similar issue when trying to run jest:
typeerror: styled.createglobalstyle.withconfig is not a function

Still trying to determine if this is specific to something in my environment, though.

Seeing a similar issue when running jest:
TypeError: styled.css.withConfig is not a function

It started occurring when I split a single library into two: Lib A and Lib B.
When component from Lib A imports a component from Lib B both libs built using this plugin.
Same build process in both, nothing really changed.
Using it as always:
import styled, { css } from 'styled-components';

I made a repo reproducing the issue. Not sure if its a bug or something wrong with my env setup 🤔.

More info: With my current setup, the last compatible version was v1.6.4.  Which really makes me believe its an issue on my end but not sure what, the sample repo is pretty straight forward 🤔

Having the same problem what I discovered today was that when we target ES modules the build output works perfectly fine. This issue happens only in CommonJS output for us. We are using Rollup to build our components for npm distribution in both ES and CJS versions.
Below are examples of the output.
index.cjs.js
var spinnerRotate = styled.keyframes(["100%{transform:rotate(360deg);}"]);

index.es.js
var spinnerRotate = keyframes(["100%{transform:rotate(360deg);}"]);

Would anyone know which direction we should go debugging this?

It seems like Rollup doesn't resolve named exports correctly: https://github.com/rollup/rollup/issues/3011
Could be related to this problem.

Following up on my comment above, my team and I are using this workaround to avoid the styled.keyframes.withConfig is not a function error:
View source for 'Spinner'
import styled from 'styled-components'

const keyframes = require('styled-components').keyframes

const spinnerRotate = keyframes`
  100% {
    transform: rotate(360deg);
  }
`

It's strange having to mix ES2015 import and CommonJS require in the same file. However, when we build our component using Rollup using the syntax above, we no longer see the error in our Jest tests. Errors would appear when components consuming our 'Spinner' would run keyframes from our CommonJS export of Spinner. Here is the CommonJS export of Spinner, which contains the following lines:
function _interopDefault (ex) { return (ex && (typeof ex === 'object') && 'default' in ex) ? ex['default'] : ex; }

var styled = _interopDefault(require('styled-components'));

...

var keyframes = require('styled-components').keyframes;

It's possible that Rollup's _interopDefault method is only fetching the default export, which could explain why the error in question gets thrown. I haven't had an opportunity to dig further, but I'll follow up once I do.

@theetrain Your fix worked for me, I went back to my rollup config later though and changed the output format to umd and it fixed this problem as well! I had to add my globals and a name but it worked.
from:
  output: [
    {
      file: pkg.main,
      format: 'cjs',
      sourcemap: true,
    },
    {
      file: pkg.module,
      format: 'es',
      sourcemap: true,
    },
  ],

to:
  output: [
    {
      file: pkg.main,
      format: 'umd',
      sourcemap: true,
      name: 'my-components',
      globals: {
        react: 'React',
        'prop-types': 'PropTypes',
        grommet: 'grommet',
        'styled-components': 'styled',
        'styled-system': 'styledSystem',
      },
    },
    {
      file: pkg.module,
      format: 'es',
      sourcemap: true,
    },
  ],

I had a similar error related to styled-components and typescript-plugin-styled-components (which extends from babel-plugin-styled-components).
As I was using the typescript-plugin-styled-components to add readable classnames to the DOM whilst developing (related to this thread; https://github.com/styled-components/styled-components/issues/976). The error was this one;
SyntheticEvent.extend.withConfig is not a function

The error was resolved when downgrading typescript-plugin-styled-components to 1.0.0.
Leaving this here for anyone else googling the same keywords I did ^^

const keyframes = require('styled-components').keyframes

Ran in to this issue (again) after updating a bunch of dependencies and our rollup babel plugin after migrating to React 17.
The above solution worked in our NextJS app loading a component library that included a keyframe import from styled-components.
Thanks again for this @theetrain 🙏

I'm not a huge fan of unnecessary dynamic imports. Especially with TS, we rely a lot on the inferred types that the named imports give you.
I had this error happening when importing a library, and it broke the tests on the consuming app.
We didn't want to change the way the library worked to accommodate that.
Changing Jest's config to ignore the library did the job for me:
jest.config.js
transformIgnorePatterns: ['/node_modules/(?!LIB_NAME).+$'],
Hope this helps =)


add Label Sleuth version to the bug report template

Codecov Report

Merging #329 (5fc1c28) into main (a605cd4) will increase coverage by 0.07%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #329      +/-   ##
==========================================
+ Coverage   82.14%   82.22%   +0.07%
==========================================
  Files          57       57
  Lines        3870     3870
==========================================
+ Hits         3179     3182       +3
+ Misses        691      688       -3

Impacted Files
Coverage Δ

label_sleuth/orchestrator/orchestrator_api.py
67.30% <0.00%> (+0.71%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


"Invalid" items are being assined a bit too eagerly. A cursory lookup shows some tiles reference objects in the "invalid" category. Need to revise this.

When assigning items to Tiles, I put a safeguard that would disallow putting "Invalid" items in a tile. Here, "Invalid" means an item that has its index lower than or equal to the first free index. But, when actually doing the assignments, there's several instances where "Invalid" items are assigned to somewhere and, hence, should be valid.
Since that should've been impossible, from my understanding of the file format, a few solutions would have to be considered:

Consider an invalid item whatever value isn't referenced by any Tile or Container/Mobile object. Doesn't go in line with the way the file is organized, though.
Consider invalid items all those whose indices match the values in the free idx array below the threshold, since they tell which indices in the object arrays should be free. That'd need some more logic, but it's doable. Yet, I don't know how correct that'd be. According to the docs, any idx above the threshold should be ignored.

I could also peek into hank's code... See how he does things.

Apparently the label "Invalid" I'm adding to the objects is inaccurate. What's "used" is what's referenced by the tiles and containers. The remaining data is irrelevant. I should use only a reference counter (to prevent double additions - although would that be a cool way of making some items be placed in more than one place?).
I think this is used mostly when populating the containers, I should iterate through all items with reference counters >1 (or through all tiles), populate the containers found, and the containers in those containers. Maybe, instead of something recursive (ugh), populate a queue with GameObjects and add/remove items from the queue as I fill in the objects.

I think some traps also act as containers. Need to implement an interface to consolidate that behavior - containers and mobileobjects, now with something else, is too much of a hassle.

Fixed with #55


Add etcher apt-repo because the one provided by balena is down

Issue https://github.com/balena-io/etcher/issues/4059 describes why the main public etcher repo provided by Balena stopped working.

[ ]  Create apt-repo on US repo (https://us.mirrors.headup.ws/)
[ ]  Sign deb package
[ ]  Add GPG key to gist.github.com
[x]  Change to Cherokee Webserver
[ ]  Share with the community
[ ]  Replicate repo for LATAM (https://cl.mirrors.headup.ws/)

URL to complete this:

public key
earthly howto
DO howto


Image icon over date?

In case of a special event, i want to show an image icon over a date. How can i go about this?

Currently we don't support this functionality, we will be grateful if you would like to give it a try.


Update readme to make it easier to read

Is your feature request related to a problem? Please describe.
I went through the readme several times. The sections do not flow. Filled with commands and code, everything looks messy.
Describe the solution you'd like
A reorganization of the readme. Complete flow of reading. For eg -

What is this project
What does this do
Motivation
How can you use it

Example snippets for use

How can you develop for it

Pre requisites
configurations
build
tests

Describe alternatives you've considered
I understand this might seem like a low priority task, but a good readme is extremely important. Maybe open this up as a good-first-issue so someone else could take it.

I'd like to have a go at this, I agree that the current order of the readme doesn't flow well.

@annahayhurst Thanks!


fix: error mismatch

because of recently modify for storage backend, it breaks the error chain

Can you please run cargo +nightly fmt --all

i have run the command, i don't know why the rustfmt seems strange


Unable to "Read" from Cosmos DB

I've followed the steps on setting up CosmoDB and also creating the echo bot on node.js. I realise that the code can only "Write" to the database but unable to "Read" From it.
I.e. in this example if I were to send "hi1" and "hi2", the end result does not store "hi1" as it did not read it from the database.
How can I resolve this? Thank you.

Detalji dokumenta
⚠ Ne uređujte ovu sekciju. Ona je neophodna za povezivanje problema slijedom docs.microsoft.com ➟ GitHub.

ID: 7538ed7a-5bb8-abc0-23e7-5b118e2fd47f
Version Independent ID: f6181862-6527-6698-afcd-4f6d240123da
Content: Write directly to storage - Bot Service - Bot Service
Content Source: articles/v4sdk/bot-builder-howto-v4-storage.md
Service: bot-service
GitHub Login: @DeniseMak
Microsoft Alias: kamrani

CosmosDbStorage is deprecated, instead you should use CosmosDbPartitionedStorage. You can read more in the Azure documentation about how to partition Azure Cosmos DB.

Closing now that the changes have been merged live.


fix: adds pagetheme colors

closes #5235
Signed-off-by: Remi Kristelijn<EMAIL_ADDRESS>Hey, I just made a Pull Request!
This will add undocumented pageThemes and makes it able to overwrite it. This is documented in both the docs and storybook
:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. ([more info] (https://github.com/backstage/backstage/blob/master/CONTRIBUTING.md#creating-changesets))
[x] Added or updated documentation
[x] Tests for new functionality and regression tests for bug fixes
[x] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

Just wondering, if you put a console.log({themeId}); here https://github.com/backstage/backstage/blob/master/packages/core/src/layout/Page/Page.tsx#L37
you see a lot of different values that are not documented. What is the plan with that?
I know it is not directly related to #5235 but still


Add Express Checkout service

Express checkout service should verify is possible to do the express checkout (any shipping address, any payment method).

If yes, it should set up the default shipping address, delivery mode and payment method by endpoints #1617
For now, the delivery mode should be configurable by store owner (storefront config #3923). Later it can use also #3915/#3920.

This service should have a method for setting default checkout options.
We'll re-use existing checkout button / page label.

@Xymmer
I have some new edge cases, which should be chosen in:
defaultDeliveryMode: [DeliveryModePreferences.FREE, 'premium-gross'],

If there is no free option, should it take first cheapest or iterate to next and take the most expensive?
What has a bigger priority?

first cheapest

@Xymmer
After discussing with Marcin, we can see the handicap of this solution.
We used an array for allowing prioritize options, first matching will be chosen.
The previous example means, what if store owner want to set free, or most expensive (if free is not available), similar to defaultDeliveryMode: [DeliveryModePreferences.FREE, DeliveryModePreferences.MOST_EXPENSIVE],
I know that it is an edge case, but we should still support it. Else, arrays have sense only with codes. Still if the store owner set only defaultDeliveryMode: [DeliveryModePreferences.FREE] then will be chosen least.
What do you think about it?


The links in the list of artifacts is wrong

The list of artifacts uses the environment_id instead of the build_id, which leads to wrong links
The links are built like http://localhost:5000/conda-store//build/11/lockfile/ instead of http://localhost:5000/conda-store/api/v1/build/11/lockfile/ (the /api/v1 part is missing)

PR Related: https://github.com/Quansight/conda-store-ui/pull/104

Done


refactor: remove g:did_typescript_hilink and :HiLink

This change is based on the discussion in #277.
To reduce the difference between this repository and the upstream vim/vim, this PR does the following refactorings. The behavior of this plugin should not change.

Remove g:did_typescript_hilink variable. The variable is used not to :hi def link the same highlight item multiple times. However, today's Vim raises no error when :hi def link is used for the same highlight item twice. The second command execution is simply ignored. So the variable is unnecessary.
Remove :HiLink custom command. This is just an alias to :hi def link so expanding it manually. :HiLink is usually used to avoid errors on pretty old Vim which doesn't support def, but we don't support such old Vim actually.

I confirmed all syntax tests passed.

thanks!


Installation issue

Hey, glad someone has been working on this!
I tried downloading and installing your module on my Linux install of FVTT 0.4.3.  I have the files in the starfinder folder under modules however Step 2 I'm getting "Incorrect manifest file https://raw.githubusercontent.com/wildj79/foundryvtt-starfinder/master/system.json for module installation. Requires module.json"
I'm not a dev but have a fair amount of IT experience.  Not sure if this is a FVTT issue or specific to your module.

As stated in discord, this is not a module but a system. So to install, go to the "Game Systems" tab, click on the "Install System" button on the bottom of the screen, then paste https://raw.githubusercontent.com/wildj79/foundryvtt-starfinder/master/system.json into the "Manifest URL" input box.


fix: call useTreeData().move() more time

Closes
✅ Pull Request Checklist:

[ ] Included link to corresponding React Spectrum GitHub Issue.
[x] Added/updated unit tests and storybook for this change (for new code or code which already has tests).
[ ] Filled out test instructions.
[ ] Updated documentation (if it already exists for this component).
[ ] Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

Tree data will lock or lose node when call move() more time.
🧢 Your Project:

Moved here https://github.com/adobe/react-spectrum/pull/1465, closing

Moved here https://github.com/adobe/react-spectrum/pull/1465, closing


Does it possible to add a update message function?

Which the update function can let user to update the loading object message?
for example:
loading...
then update the mesasge to
processing...
etc.
Thanks for your help.

Hi @KinkiWu, if you want to change the message programatically, after the loading state has started, there's no easy way but you can do that:
$('.loading-overlay-content', $('#element').Loading().overlay).html('Processing...')

Maybe in the future we can provide a better way of doing that via a simple function call.

In v1.3 it is also possible to call again the plugin, with no duplicated overlay.
Feel free to reopen this issue if you still have problems.

Thanks CarlosBonetti, I just update the plugin to v1.3, it work normally.
I am very appreciate your help.


Windows docker cannot pull microsoft/windowsservercore if a virus scanner is installed

Please see this issue that has been logged for months but no action:
https://github.com/Microsoft/Virtualization-Documentation/issues/355
Maybe it is not logged in the correct place? so I am logging an issue here.
Description
Please see https://github.com/Microsoft/Virtualization-Documentation/issues/355 for details from many people who have encountered this problem in different contexts.
Having a virus scanner installed prevents any Docker images from being loaded on Windows Server 2016.
Steps to reproduce the issue:

Install docker on Windows Server 2016
Symantec Endpoint Protection 12.1.6 is installed (or any other scanner listed in the aforementioned issue)
docker pull microsoft/windowsservercore OR docker pull microsoft/nanoserver

Describe the results you received:
The image is downloaded and extracted. Sometime after the extraction completes the pull fails with an error:
bce2fbc256ea: Extracting [==================================================>] 252.7 MB/252.7 MB
3ac17e2e6106: Download complete
failed to register layer: re-exec error: exit status 1: output: ProcessUtilityVMImage C:\ProgramData\docker\windowsfilter\47bb01e457a6b11b3dad02d3bfe3b3e84f7ac24e208685e282ead787d0292567\UtilityVM: The process cannot access the file because it is being used by another process.
Describe the results you expected:
Able to pull microsoft/windowsservercore OR microsoft/nanoserver
Additional information you deem important (e.g. issue happens only occasionally):
Reported by many people for a variety of different virus scanners. It does not appear that disabling the scanner or creating folder exclusion rules helps. Only completely uninstalling the scanner works which is not possible in many environments.
I also tried with the latest docker 1.14-dev with the same results.
Output of docker version:
Client:
 Version:      1.12.2-cs2-ws-beta
 API version:  1.25
 Go version:   go1.7.1
 Git commit:   050b611
 Built:        Tue Oct 11 02:35:40 2016
 OS/Arch:      windows/amd64

Server:
 Version:      1.12.2-cs2-ws-beta
 API version:  1.25
 Go version:   go1.7.1
 Git commit:   050b611
 Built:        Tue Oct 11 02:35:40 2016
 OS/Arch:      windows/amd64

Output of docker info:
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.12.2-cs2-ws-beta
Storage Driver: windowsfilter
 Windows:
Logging Driver: json-file
Plugins:
 Volume: local
 Network: nat null overlay
Swarm: inactive
Default Isolation: process
Kernel Version: 10.0 14393 (14393.321.amd64fre.rs1_release_inmarket.161004-2338)
Operating System: Windows Server 2016 Standard
OSType: windows
Architecture: x86_64
CPUs: 4
Total Memory: 32 GiB
Name: VOTTPAWEIN2016
ID: YA6Z:R7KB:MKR2:FKSX:PGZ2:P7FD:FWEA:GS5S:F7CC:TAJ4:P2Q4:QPS2
Docker Root Dir: C:\ProgramData\docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):
In this case Windows Server 2016 is a VM running under VMWare.

/cc @friism

@drnybble There's not really a lot that the Docker can do if you've elected to install software on your machine (antivirus in this case) that blocks Docker from operating. I recommend getting in touch with the people that implemented the software that's blocking Docker from working on your system. Microsoft has also helpfully published a guide to antivirus programmers, that you can reference: https://msdn.microsoft.com/en-us/windows/hardware/drivers/ifs/anti-virus-optimization-for-windows-containers

I installed a trial version of Symantec Endpoint Protection 14 and indeed I am now able to pull images successfully. I will close this issue. However, folks have reported issues with a variety of AV packages:

Norton 360
Norton Internet Security
Symantec Endpoint Protection
BitDefender
McAfee
At least this issue will alert them to upgrade to the latest or hound their AV provider!

I had the same error with "The process cannot access the file because it is being used by another process.". I tried to disable Kaspersky Internet Security, to add exclusion, but only after complete uninstall of KIS things are finally working.

@dukenukem7j it may be worth opening a ticket with Kaspersky for that; I know there's other virus scanners that made changes to bring compatibility with Docker


[aes] Forcing main/cipher core FSM signals sometimes doesn't trigger fatal alerts

@vogelpi
if you look at PR #13571
and run /util/dvsim/dvsim.py hw/ip/aes/dv/aes_masking_sim_cfg.hjson -i aes_control_fi -r 1 -t xcelium  -s=1108401101
you will see tb.dut.u_aes_core.u_aes_control.gen_fsm[2].gen_fsm_n.u_aes_control_fsm_i.u_aes_control_fsm.cipher_in_ready_i
begin forced  high - and the two other interfaces continuing on as usual - not fatal is asserted.
this is one of the signals in the list you wanted me to check.

I've renamed the issue to make it representative for #13646 as well. The behavior of these tests is very similar.
It's not a problem in the RTL but the test. The test forces a signal which doesn't have an effect in a reasonable amount of time
At the moment, about 1 out of 10 FI test runs fail because of this. Since we have many passing seeds for these FI tests and coverage looks pretty good, I am proposing to fix the test after V2S/M2.


Confused about CustomGeometry and GeometryCollection in 'place'

The place schema lists CustomGeometry as one of the possible 'place' types: https://github.com/opengeospatial/ogc-feat-geo-json/blob/6e27bc226f8da975d691a064f44e3e3fc150b941/core/schemas/place.json#L40
There is no mentioning of GeometryCollection.
The geometry objects schema lists CustomGeometry and GeometryCollection too.
Which one of the two schemas are true?

Based on the schema, currently you cannot use GeometryCollection in the "place" member - whether that was intentional or not. This should be addressed together with #71.


Increase the default scroll sensitivity to 3

This is more in line with most programs out there. For instance, scrolling by 3 lines is the default in most Windows programs.
Moreover, it typically results in less physical strain over time as you don't need to use the mouse wheel as much to navigate.

Bump :slightly_smiling_face:

I don't really see the point of changing such a minor default setting. I don't think this (arguable) improvement is really worth changing defaults for.


Feature/aliasing

Create MSAA buffer in ComponentCamera
Render using MSAA buffer
Can toggle MSAA on/off on Debug Window

I have fixed the issues, when you can, approve it if it seems correct @mariofv! :)

All cool now!


make lexer.words() work with lexer.bygroups()

(Original issue 1229 created by lohner on 2016-04-15T14:20:27.979750+00:00)
In rare cases lexer.words(keywords) doesn't group the matched words such that using it together with lexer.bygroups is not guaranteed to work.
An example of such a case is e.g. keywords = ('A','B','C',).
A solution could be to surround make_charset(oneletter) with open_paren + ... + close_paren in pygments/regexopt.py at line 57?

(Original issue 1229 last updated on 2016-06-01T16:54:37.898219+00:00)
(Issue automaticaly closed due to status in Bitbucket: resolved)

(Original comment by tshatch on 2016-06-01T08:05:07.457112+00:00)
Sorry, I don't understand.  Could you give a full example of the call to words() that fails?

(Original comment by lohner on 2016-06-01T08:48:59.345382+00:00)
What I mean is, that using words(('A','B','C',), suffix=r'([0-9]+)').get() results in '[ABC]([0-9]+)' instead of '([ABC])([0-9]+)' as I expected. Thus using it together with bygroups in tokens as e.g. in
tokens = { 'root': [(words(('A','B','C',), suffix=r'([0-9]+)'), bygroups(Keyword,Comment))] }

relating [ABC] to Keyword and [0-9]+ to Comment fails.
As far as I understood regexopt, this issue only arises if all arguments to words are single letters. Thus it only occurs in rare or even artificial situations. Nevertheless, if tokens is for example automatically generated this could be a problem.

(Original comment by tshatch on 2016-06-01T16:54:37.893379+00:00)
Fix a bug in default grouping in regexopt when the words are all the same length.
Fixes #1229
→ <<cset 4459f971dd43>>


Enable tobiko execution on the test-operator zuul job

Both Tempest and Tobiko will be executed with test-operator.
Depends-On: https://github.com/openstack-k8s-operators/ci-framework/pull/1171

recheck


chore: adjust 2ndary hyperlink button resource

GitHub Issue: n/a
PR Type
What kind of change does this PR introduce?

Refactoring (no functional changes, no api changes)

Description
Inline stray MaterialSecondaryHyperlinkButtonStyle resource
Other information
re: https://github.com/unoplatform/Uno.Themes/pull/1055#pullrequestreview-1526755910

@mergifyio backport legacy/2x


Test issue, please ignore

test

test

bad birdie :angry:

good birdie 🐣

test

what did I do

Everything


Add enable_self_service_portal variable

The variable will give an ability to enable the self service portal, which is disabled by default.
Types of changes
What types of changes does your code introduce to <repo_name>?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices apply)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have read the CONTRIBUTING.md doc.
[x] I have added necessary documentation (if appropriate).
[ ] Any dependent changes have been merged and published in downstream modules.

thanks @ashishbista, version 0.4.0 published.


feat: add --only-templates flag

For instance, check this PR  in TanStack, https://github.com/TanStack/query/pull/7861
The problem is when repository has too many packages the amount of scroll on the PR page will increase, adding another detail to the pkg.pr.new links conditional with a flag like --collapsed-links will help resolve this case

Can we have onlyTemplates option that only shows the user defined options? Since that's what Seb suggested.
instead of the --collapsedLinks option.

What I'd like is something like this:

This PR has been continuously released. You can run its code in one of our templates:

template-js
template-ts

Alternatively you can try the PR code directly into your project:

Dependencies
npm add https://pkg.pr.new/@docusaurus/core@7861
npm add https://pkg.pr.new/@docusaurus/utils@7861
npm add https://pkg.pr.new/@docusaurus/theme-common@7861

Maybe you can consider the comment has 2 sections.
And let me activate sections and order them? For example --section templates --section dependencies
And let me pass a custom section intro message for both.

Full example CLI options:
--section templates
--templates-intro 'This PR has been continuously released. You can run its code in one of our templates:'
--section dependencies
--dependencies-intro 'Alternatively you can try the PR code directly into your project:'

@slorber For now, let's only show the templates for the option --onlyTemplates
For further customization, as #173 suggested, we'd have a json output that would allow maintainers have more control over the output!
wdyt?

Fine with a simple option 👍

let me know once it's on npm
By the way what's the final comment with this new option?
Is the comment template part of this repo? I may want to fork it and customize for our own needs eventually.

Hmm, could you give me more context?

Hmmm not sure what to add: we agreed to keep this option simple and not have the ability to provide custom labels like my former suggestion. Can I implement it myself by forking/patching this package, or is the final message being created/posted by some StackBlitz internal backend?

Can I implement custom labels myself by forking/patching this package, or is the final message being created/posted by some StackBlitz internal backend?

Oh yea, with the #183, now you can turn comments off, get the json output and then create your own message! 😄
We will release soon.

@Aslemammad that probably works but looks more complicated, do you have a full github action example flow doing so?
As far as I remember it's a bit annoying in terms of security to have your action post a GitHub comment and build the code.

As far as I remember it's a bit annoying in terms of security to have your action post a GitHub comment and build the code.

Yea, haven't looked into that, but for sure, it might have its own trade offs. But I guess that's only way we can make it extensible and let others custmize on top of it, without building many abstractions in code, which is a bit challenging.
@pngwn might want to share thoughts on this?

Yes we do this a lot over on gradio. It is indeed a little more annoying but relatively straightforward.
I'll post an example flow shortly.

Fwiw I do think the JSON approach is preferable to additional formatting params. This allow the most flexibility, and can even allow you to add the info to an existing CI reply rather than every service generating additional replies (which also gets very noisy).

Yes JSON is flexible, now if you tell me how to wire it in my CI properly and I just have to copy/paste the complex actions files, that works for me 😄

Just waiting for a release and I'll post it (the old pr link is dead now). Has this been released?

I'll also make a PR to the docs / readme when it is out.

Hey not yet, we want to batch it with few other goodies and then!
Sorry for that.
On Fri, Aug 23, 2024 at 5:12 PM pngwn @.***> wrote:

I'll also make a PR to the docs / readme when it is out.
—
Reply to this email directly, view it on GitHub
https://github.com/stackblitz-labs/pkg.pr.new/pull/172#issuecomment-2307123772,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJBMICBOI6CBEYYUAD2YGJTZS433XAVCNFSM6AAAAABMRY7NYSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBXGEZDGNZXGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

No worries!