Change StalenessDelta to be per-statement

With the current package-global StalenessDelta you have to pick a single
StalenessDelta for all queries that will be ever done in your process.
This is difficult, when the queries you are processing vary wildly in
duration (1h vs 30d). In the case of a 1h query, a 5m StalenessDelta is
okay (maybe too long) but for a 30d range that might be too low (as the
step interval may be significnatly longer).
This change allows the user of the engine to define a function to
determine a StalenessDelta based on the query that you are processing.
This maintains compatibility by providing a default function to return a
5m duration (the old hard-code).

This is necessary for metrics proxies (such as promxy to function.

What are you trying to do that a single value doesn't cut it? It is recommended to have a single interval per Prometheus to keep things sane, https://www.robustperception.io/keep-it-simple-scrape_interval-id/

@brian-brazil I'm not sure I follow the concern here. The original issue states that the issue is with StalenessDelta, but the link you pasted is for scrape interval.
To restate the issue again the issue comes when querying ranges of data with a step that outstrips the StalenessDelta. For example, if I where to get data from prometheus at a step of 600s (6m) then there would be many holes in the outputted graph, because the datapoints aren't within the StalenessDelta (currently hardcoded at 5m).
This PR gives the users of the promql.Engine a mechanism to override these values depending on their use case. In this example the client could set the StalenessDelta as a multiple of the step (or to another hard-coded value).

To restate the issue again the issue comes when querying ranges of data with a step that outstrips the StalenessDelta.

Changing the staleness delta doesn't change that. You need to change the query in that case, not the staleness delta. In particular you need to increase the range on your rate function.

Changing the staleness delta doesn't change that. You need to change the query in that case, not the staleness delta. In particular you need to increase the range on your rate function.

Actually the staleness delta is exactly the thing to change. If we look at the code we can see that the vectorSelector (as an example) uses the StalenessDelta to determine which values belong to the vector. If the iterators are populated with data that has a long step (greater than the StalenessDelta) then datapoints will be missing in the resulting vector.

If the iterators are populated with data that has a long step (greater than the StalenessDelta) then datapoints will be missing in the resulting vector.

That is the intended behaviour, intervals greater than 2 minutes are not advised. Can you expand more on the type of data you're working on where this is coming up?

That is the intended behaviour, intervals greater than 2 minutes are not advised. Can you expand more on the type of data you're working on where this is coming up?

This is not an unreasonable default for scrape interval, but retrieval of data may not be able to adhere.
The specific case I'm working with is with promxy -- an aggregating promql proxy to give you a unified access point for all your various prometheus clusters. Promxy is implemented as a Querier which in turn fetches its data from prometheus over the HTTP api. With a hard-coded 5m StalenessDelta that means that promxy must fetch data from the downstream prometheus hosts with a step of no greater than 5m. This is extremely limiting especially for fetching data over large time ranges. For example, if I where to fetch the data for 30d of data that would come out to 172800 datapoints (at 15s scrape interval). With the current hard-coded 5m I could reduce the number of points fetched to 8640, but thats still significantly more datapoints that something like grafana would show. Meaning I'm stuck putting additional load on the downstream asking for more data than necessary just to appease promql's hard-coded StalenessDelta.
With the patch in this PR I could provide a function that could calculate a StalenessDelta for the query I'm returning. In this case where I'm getting 30d of data, I may ask for data every 10m (which is 4320 points) with this patch I could set the StalenessDelta for this Statement execution to 20m -- which would allow for missing datapoints etc.
The goal of StalenessDelta is to determine "how old is too old" for a datapoint, or in other words if there was a "gap" in data because there wasn't a scrape. To do this the StalenessDelta needs to be relative to the Step. In the case of local-to-prometheus this is done because the ScrapeInterval is lower than the StalenessDelta, but for other people trying to implement the Querier interface such queries maybe be excessively expensive (meaning this issue isn't unique to promxy).

I can kinda see what you are trying to do, but this is not a good approach as you will often be returning almost random data to your users due to ignoring lots of data points.
When you're doing this sort of thing you need the raw data, without involving PromQL. I'd suggest looking at the query endpoint with a range selectior rather than query_range, and possibly also the remote read endpoint.

First things first, down sampling isn't random. If the user wants to
downsample and they get a downsampled response they are happy. This is done
in prom sometimes with aggregation clusters etc.
As for fetching raw data through querry, this is exactly what I used to do,
but in the case of a user asking for a large time range (or large number of
timeseries) this can easily overwhelm Prometheus, and more importantly the
original query from the client (e.g. grafana) only wanted a specific step,
so we don't need 100% since they defined what step they want.
As it stands today the only way to get fork/reimplement promql is to fetch
every data point which isn't scalable. Similarly I'd expect Prometheus to
do similar things under the hood for a query_range with large steps.
On Dec 26, 2017 12:33 PM, "Brian Brazil"<EMAIL_ADDRESS>wrote:
I can kinda see what you are trying to do, but this is not a good approach
as you will often be returning almost random data to your users due to
ignoring lots of data points.
When you're doing this sort of thing you need the raw data, without
involving PromQL. I'd suggest looking at the query endpoint with a range
selectior rather than query_range, and possibly also the remote read
endpoint.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/prometheus/prometheus/pull/3627#issuecomment-354010322,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABi3nX7JPHB9YY2P7IXGfYuOG_VuVE8Wks5tEVf-gaJpZM4RM9GY
.

First things first, down sampling isn't random

That it's deterministic doesn't mean that throwing away 90% of your data is going to produce a good result.

If the user wants to downsample and they get a downsampled response they are happy.

That depends on whether the response is meaningful and the meaning is what the user expects.

As for fetching raw data through querry, this is exactly what I used to do, but in the case of a user asking for a large time range (or large number of timeseries) this can easily overwhelm Prometheus

This is one of the big reasons we recommend against trying to build something like this. Doing it correctly usually requires moving a lot of data about, and it's easy to take out all of your monitoring with a single query.

Similarly I'd expect Prometheus to do similar things under the hood for a query_range with large steps.

It doesn't, that's up to the user and we for example have been working with Grafana to help make this easier.
The staleness delta is not the solution to the problem you're having, it's merely a symptom. If you can share with me an example query that you're having issues with I can show you how to approach this.

That it's deterministic doesn't mean that throwing away 90% of your data is going to produce a good result.

My reply there was to point out that downsampling != random (as you had implied previously

often be returning almost random data

"good result" is relative to the desired result. If the user requests a downsampled result, then returning a downsampled result is completely fine. The issue of "goodness" is when the desired and actual outcomes differ.

This is one of the big reasons we recommend against trying to build something like this.

The goal here of this proxy is less about aggregation and more about metric discovery. With any moderate install base you end up with many prometheus instances. These all end up as a variety of sources in grafana which confuses users to no end. And then if you want to increase the reliability of prometheus by having redundant hosts, then you introduce problems there as well (no backfilling, etc.). For this sort of a system where the server product wants to ignore as much as it can about the surrounding infrastructure, a proxy that can route metrics sounds exactly like what it wants.

The staleness delta is not the solution to the problem you're having, it's merely a symptom.

If that is the case, what is the problem I am having? From the data I have I see missing datapoints coming back from the query_range endpoints, and I have to deal with them in some mechanism. Right now the source prometheus node has a fixed 5m staleness delta, meaning if there isn't a datapoint within 5m of the step then it returns no datapoint. For me to then infer up a level that this means there was no data since the last step is incorrect as well.
To make this a concrete example, lets say there is a metric foo and it is being scraped every 1m. If I where to send a query_range for foo for 2d of data with a step of 10m starting at time t. In this case we'd expect a response of 288 datapoints. Lets say there was a gap in scrape data, specifically from t+1m -> t+11m. In this case prometheus' response at time t+10m will be null, as there was no value in the StalenessDelta. This leaves the caller (a remote instance of promql) to show that there was no data from t -> t+20 because there was no datapoint there. In this case of a downsampled response, its not unreasonable to expect/want that to be smoothed over. If I'm looking at a report of the last 3m of data I don't want holes for a day because there was a gap in data for 10m. Conversely if I had a tight scrape interval of 1s then I wouldn't want data thats 5m to count as relevant, because that means that 300 scrapes failed (which is a lot)!
In the case of prometheus the server promql works alright because the scrape interval is consistent, and it has all of the data local to the box. In the case of many datasources, the promql  package isn't at all equipped to handle this. With a single package-level global there is no way for me to change it based on datasource, so I have to (at best) create different processes in different binaries to handle multiple sources that want different StalnessDeltas.
I could see an argument for moving StalenessDelta to be an engine-wide metric, but this path of "we can't change the StalenessDelta" doesn't make sense to me. If promql is supposed to be used for a variety of sources (which the Querier interface and various remote read plugins seem to imply) then this should be configurable at a more granular level than it currently is. IMO doing it on a per-request basis would be ideal, as it gives the caller the most flexibility in setting the value.

I've had a look at your code. Instead of retCount you should use a WaitGroup, which fix the race you have there.
From what I can see for the case your support there's a much simpler way to do what you want using remote read and the remote read endpoint. Configure all the sub-Prometheus servers as remote read endpoints of the main Prometheus. This isn't quite the way to do this, but it'll do similar to what you have. The caveats about taking out all your monitoring at once remain.

which fixs the race you have there.

What race condition? That code uses channels and goroutines, there is a single goroutine waiting for the responses, and because of it there is no need for locks etc. Doing it this way means I can start processing responses as soon as the first one shows up, instead of waiting until the last one responds. If you see a race, could you expand on it?

there's a much simpler way to do what you want using remote read and the remote read endpoint.

How is this much simpler? I can see that this would hit a different (unstable) endpoint, but that doesn't solve any of the issues we're talking about in this PR, it simply moves my implementation to an unstable API-- unless remote read/write somehow give you access to controlling promql internals?

And then if you want to increase the reliability of prometheus by having redundant hosts, then you introduce problems there as well (no backfilling, etc.).

This is a very hard problem, Prometheus avoids this type of clustering as it's quite difficult to get right, let alone right and reliable. Your code appears to be ignoring this problem. For simplicity I suggest talking to only one of a HA pair.

These all end up as a variety of sources in grafana which confuses users to no end.

Ah, you're trying to build one of those. You'll need to add in the external_labels of the Prometheus you're talking to in the query result then. Otherwise metrics between different Prometheus servers will clash.
In practice I find it fairly obvious which Prometheus contains which data. For example the Cassandra Prometheus contains Cassandra metrics, the infrastructure Prometheus contains node exporter metrics etc. matching your general architecture.

From the data I have I see missing datapoints coming back from the query_range endpoints, and I have to deal with them in some mechanism.

If the data isn't being returned due to staleness, then that is as the data is stale and thus you don't want it returned. This is a problem with naive downsampling, you're getting the same result as if the scrape interval was 10m - which is correct. And why a scape interval of no more than 2m is recommended.

In this case of a downsampled response, its not unreasonable to expect/want that to be smoothed over.

What you want here for gauges is avg_over_time, so that all values get smoothed equally and all data is used.

Conversely if I had a tight scrape interval of 1s then I wouldn't want data thats 5m to count as relevant, because that means that 300 scrapes failed (which is a lot)!

The new staleness handling in 2.0 should cover you there. Where this setting matters there is around crashes, which are expected to be rare.

IMO doing it on a per-request basis would be ideal, as it gives the caller the most flexibility in setting the value.

Having seen the confusion the global setting already causes, I'd be wary of making it possible to make the semantics more convoluted. You could bump the staleness delta to a high value and leave it to new staleness to handle the rest, it's not the sort of thing you should need to tweak per query.
At a high level, this is not a great way to try and downsample. As you've found for example missing data is a bit tricky to deal with, and you'll also run into issues with counters such as missing resets. The /query_range function is intended for use directly in graphs, not as a way to downsample raw data.
It's expected that users would implement a long term storage system that featured downsampling and were made to work with the remote read feature. Downsampling is not a feature that belongs in Prometheus itself, and attempting to shoehorn it in is not likely to end well. If you want to downsample properly you need to work with the raw data directly so that you can handle all the edge cases
When presenting data back to PromQL you also need to make it look right, as in not downsampled. This is what remote read endpoints would need to do, and considering that you're basically implementing an in-process remote read endpoint also what you should do.

What race condition?

Ah, I misread. I thought the goroutine started earlier than it did.

it simply moves my implementation to an unstable API-- unless remote read/write somehow give you access to controlling promql internals

It's not that unstable, it's pretty safe to build on and many companies are doing so. It does give you something that no other API does in that it completely bypasses PromQL, and thus gives direct access to the actual raw data including the stale markers.

Your code appears to be ignoring this problem. For simplicity I suggest talking to only one of a HA pair.

I'd like some more specifics about what all problems are being ignored, but let that whole thread

Ah, you're trying to build one of those. You'll need to add in the external_labels of the Prometheus you're talking to in the query result then. Otherwise metrics between different Prometheus servers will clash.

Already done and in the example config :)

This is a problem with naive downsampling, you're getting the same result as if the scrape interval was 10m - which is correct.

Well, this is actually an alignment problem. There is already a concept in getting data thats "close" to the requested time (which is why StalenessDelta even exists). The problem here is that you can't control what your promql thinks is stale-- which seems especially crazy since you (as the binary using promql) have more insight into the data you are feeding it.

What you want here for gauges is avg_over_time, so that all values get smoothed equally and all data is used.

How do you do this from the Querier interface? From that level all I know is a labelset and a range of time, there is no mechanism for me to know whether it is a counter or a gauge.

The new staleness handling in 2.0 should cover you there.

From looking at master it seems that 2.0 still has a package-level variable (renamed, but still the same thing), which means it doesn't address my concern of more-granular control over StalenessDelta.

Having seen the confusion the global setting already causes, I'd be wary of making it possible to make the semantics more convoluted.

I'm not sure I follow how this makes things more convoluted? My suggestion is to leave the setting exactly the same for prometheus but make it controllable for clients of the promql package -- which ash been my intent from the beginning of this PR.

You could bump the staleness delta to a high value and leave it to new staleness to handle the rest, it's not the sort of thing you should need to tweak per query.

Not sure what you mean by this? In the case of someone implementing the Querier interface, you may control that setting based on which datasource you are pulling from. It seems to me that setting the value to the largest you think you could ever want would be significantly worse than allowing it to be configured on a per-query (or per engine) basis.

If you want to downsample properly you need to work with the raw data directly so that you can handle all the edge cases

This is a somewhat flawed statement, especially since the scaling of prometheus is almost entirely based around rescraping and aggregation (which all "downsample" in their own way without access to the original data).

When presenting data back to PromQL you also need to make it look right, as in not downsampled. This is what remote read endpoints would need to do, and considering that you're basically implementing an in-process remote read endpoint also what you should do.

I'm not sure what you mean by this? You mean to say that from downsampled data I need to present to promQL data that is not downsampled? That is by definition not possible (I could make up data, but thats not generally a good plan). The problem I'm running into is that promql has some assumptions about what the data looks like, and I can't configure them (StalenessDelta in this case). So if I'm understanding your suggestion it is to return data as if I had datapoints every <whatever_the_scrape_interval_is> -- meaning I need to just fill in lots of datapoints that match for the time between the steps? If so, that causes all the rate numbers etc. to be calculate incorrectly, as promql assumes that the datapoints you have are real.

It's not that unstable, it's pretty safe to build on and many companies are doing so.

From the documentation about remote_read: Remote read is experimental: breaking changes to configuration are likely in future releases. I'm not sure how to read that as a stable supported API.

I'd like some more specifics about what all problems are being ignored, but let that whole thread

The code doesn't consider that the Prometheus servers in a pair will have slightly different data, let alone the possibility that they have wildly different data due to events such as a network partition.

There is already a concept in getting data thats "close" to the requested time (which is why StalenessDelta even exists). The problem here is that you can't control what your promql thinks is stale-- which seems especially crazy since you (as the binary using promql) have more insight into the data you are feeding it.

StalenessDelta is primarily a performance optimisation to avoid pull in too much data. If you're doing things in a normal fashion you shouldn't care what its value is as it'll have no effect semantically.

How do you do this from the Querier interface?

You'd adjust the query you are making to Prometheus.

Well, this is actually an alignment problem.

I don't follow. A different alignment will have the same issue, depending on the underlying data.

From that level all I know is a labelset and a range of time, there is no mechanism for me to know whether it is a counter or a gauge.

There isn't, this is one of the big challenges of downsampling. The approach I propose is looking at the function around the selector, which remote read will pass on at some point in future.

I'm not sure I follow how this makes things more convoluted?

For example you think this solves your problem, in reality it would lead to you implementing incorrect semantics causing further confusion and contortions as the new incorrect semantics were attempted to be worked around.
The gap you are seeing here is correct and desirable. Pondering it overnight you actually need to do a step further to ensure the user sees the gap and have consistent semantics given the downsampling algorithm that is in use. In particular when a time series disappears from one step to the next you should insert a stale marker.

This is a somewhat flawed statement, especially since the scaling of prometheus is almost entirely based around rescraping and aggregation (which all "downsample" in their own way without access to the original data).

Not really, the recommended ways of doing things includes downsampling so as not to skip data when a higher scrape interval is used. So for example if you were scraping once an hour, you'd be pulling a rate[1h].

You mean to say that from downsampled data I need to present to promQL data that is not downsampled? That is by definition not possible (I could make up data, but thats not generally a good plan).

Yes, that's what needs to be done.

So if I'm understanding your suggestion it is to return data as if I had datapoints every <whatever_the_scrape_interval_is> -- meaning I need to just fill in lots of datapoints that match for the time between the steps? If so, that causes all the rate numbers etc. to be calculate incorrectly, as promql assumes that the datapoints you have are real.

That's the basic approach I propose, if you look at other monitoring systems it's pretty normal to fill in gaps between downsampled data. For example for counters you'd want to make it increase at the right rate. This is only something that will be possible via remote read though, see #2580.

I'm not sure how to read that as a stable supported API.

We're planning on changing the transport to GRPC, but the core seems solid. Note that no stability guarantees are offered on the various Prometheus internals you are pulling in, I'd worry more about those.

The code doesn't consider that the Prometheus servers in a pair will have slightly different data, let alone the possibility that they have wildly different data due to events such as a network partition.

This is actually covered in the merge logic in the proxyquerier, I'd be more than happy to explain that some other time-- but this is completely off-topic of this PR

StalenessDelta is primarily a performance optimisation to avoid pull in too much data.

How is this a performance optimization to not pull so much data? StalenessDelta is applied after fetching the data from the datastore, it is used (according to the code and the comments) to [determine] the time since the last sample after which a time series is considered stale. This is not a performance optimization, this is a mechanism to determine when a dataseries is "stale" meaning it has no data that would be valid for a calculation at that particular point in time.

If you're doing things in a normal fashion you shouldn't care what its value is as it'll have no effect semantically.

This actually has huge effects semantically even in normal usage. In the previous example I gave, if you have a scrape interval of 1s with a StalenessDelta of 5m any datapoint can be used from a vector that is within 5m of the time that you are fetching. This means that the data result will vary based on the value, which means that there is a semantic implication of the StalnessDelta configuration.

You'd adjust the query you are making to Prometheus.

I'll repeat the question How do you do this from the Querier interface?, if you are working at the Querier interface you don't have access to the query to rewrite it in any mechanism.

The approach I propose is looking at the function around the selector, which remote read will pass on at some point in future.

So to be clear the suggestion you are giving me is to use non-existant functionality?

in reality it would lead to you implementing incorrect semantics causing further confusion and contortions as the new incorrect semantics were attempted to be worked around.

You keep mentioning that the proxy will cause more problems, but I'm not asking you to make or implement it. We are really off in the weeds talking about that proxy when this PR is only about making StalenessDelta more configurable-- can we get back on topic?

Pondering it overnight you actually need to do a step further to ensure the user sees the gap and have consistent semantics given the downsampling algorithm that is in use. In particular when a time series disappears from one step to the next you should insert a stale marker.

Users do (and will) see gaps, the problem is right now I can't control when they'll see a gap with how much I downsample because of the hard-coded StalenessDelta -- if that was configurable I could scale it with the sample rate.

Yes, that's what needs to be done.

So, what is the suggestion here? You have asked for an impossibility or made-up data.

That's the basic approach I propose, if you look at other monitoring systems it's pretty normal to fill in gaps between downsampled data. For example for counters you'd want to make it increase at the right rate. This is only something that will be possible via remote read though, see #2580.

Well, this actually varies dramatically across monitoring systems in how they do this. If you look at RRD/Whisper files they can do this on the storage layer because they know if the metric is a counter or a gauge and as such can make a decision. This doesn't end up with "correct" data, but it ends up with less "close enough" data -- which is sufficient for their purposes. In prometheus there is no mechansim for me to determine from the promql statement whether a metric is a counter or a gauge, so I'm left having to ask all of the data. Ideally I'd ask for 100% of data, but if the time range is large, downsampling is required to not break downstreams. As to "fill in the gaps" this was a previous approach in proxmy, but you cannot "make up" datapoints to pass back up from the Querier interface, as promql assumes they are actual scrape instances. Meaning that if I return 2 matching datapoints it assumes that it didn't change during that duration. If I only have downsampled data I cannot make that assertion, so it'd be better for me to only pass the data I have instead of guessing what the data might be.

We're planning on changing the transport to GRPC, but the core seems solid. Note that no stability guarantees are offered on the various Prometheus internals you are pulling in, I'd worry more about those.

I'm not sure what the objective of that point is? For the golang dependencies I have them pinned, so I'm not immediately concerned with them changing on me -- as they won't be a suprise. The APIs that I need to "rely" on are the HTTP v1 APIs from prometheus, since those are outside the project and how I actually fetch data.
Overall this entire PR conversation has drifted entirely from the original proposal to make StalenessDelta more configurable. I realize that this naive downsampling method can have some problems, but for a large section of use-cases it is sufficient. It is also significantly less complicated than a "more correct" approach-- which will come later (as that will probably require either (1) large changes to promql engine to add in hooks etc to rewrite or (2) a re-implementation of promql to handle creating eqivalent "cheaper" queries to downstream prometheus servers.) The question I have is does this PR break or make promql engine worse? Since its 100% compatible I don't see this as a problem.

How is this a performance optimization to not pull so much data? StalenessDelta is applied after fetching the data from the datastore, it is used (according to the code and the comments) to [determine] the time since the last sample after which a time series is considered stale.

It's used to control how much data instant vector evaluation pulls and processes from local storage by the engine. It's not used after the data is fetched.

So to be clear the suggestion you are giving me is to use non-existant functionality?

Yes, discussions around downsampling are at a relatively early stage so some of the required functionality hasn't been implemented yet. Even though I've been designing this for some time now, as it happens the discussions only really started yesterday.

In the previous example I gave, if you have a scrape interval of 1s with a StalenessDelta of 5m any datapoint can be used from a vector that is within 5m of the time that you are fetching. This means that the data result will vary based on the value, which means that there is a semantic implication of the StalnessDelta configuration.

That's not how staleness works in Prometheus, see https://www.youtube.com/watch?v=GcTzd2CLH7I for more detail (though that's slightly outdated).
The way to handle this is by inserting staleness markers when a timeseries disappears from one step to the next. No need to change StalenessDelta.

I'll repeat the question How do you do this from the Querier interface?, if you are working at the Querier interface you don't have access to the query to rewrite it in any mechanism.

I meant the queries being send out to /query_range.

Users do (and will) see gaps, the problem is right now I can't control when they'll see a gap with how much I downsample because of the hard-coded StalenessDelta -- if that was configurable I could scale it with the sample rate.

With the current downsampling algorithm the gaps you are seeing are correct, in fact there are fewer gaps than there should be.

We are really off in the weeds talking about that proxy when this PR is only about making StalenessDelta more configurable-- can we get back on topic?

The topic is implementation of downsampling, StalenessDelta doesn't really come into it. You should consider the StalenessDelta as a universal constant, and design things to work with rather than against it.

So, what is the suggestion here? You have asked for an impossibility or made-up data.

Yes, make up data. If you request data from query_range that is more than 2m apart, then you need to do some interpolation.

In prometheus there is no mechansim for me to determine from the promql statement whether a metric is a counter or a gauge, so I'm left having to ask all of the data.

If it's being used with rate, irate, increase or resets it's a counter. Otherwise it's a gauge. Making that and other useful information accessible to downsampling is what #2580 is about.

As to "fill in the gaps" this was a previous approach in proxmy, but you cannot "make up" datapoints to pass back up from the Querier interface, as promql assumes they are actual scrape instances.

I'm not following you here.

If I only have downsampled data I cannot make that assertion, so it'd be better for me to only pass the data I have instead of guessing what the data might be.

Downsampling is the art of making it seem as though you have full data when you don't. At it stands the code is already futzing with the data, as using query_range loses the timestamp of the original data.

I realize that this naive downsampling method can have some problems, but for a large section of use-cases it is sufficient.

Yes it's the naive way of doing things using an interface that isn't suited for the task. I understand what you are trying to do, and I'm trying to help you implement it in the best way possible.

The question I have is does this PR break or make promql engine worse? Since its 100% compatible I don't see this as a problem.

In my opinion yes it makes the engine worse, as it'll lead to more support requests by users who mistakenly think that changing staleness delta helps them with whatever problem they're having. We've had quite a problem with this for this particular setting historically. Every knob and tunable we have results in increased support load and user confusion. For example we recently had to hide some settings intended for our own loadtesting/development as users were starting to get confused by them.
If someone were to request this for something that made sense semantically, then I'd consider it.

@jacksontj If I understand correclty (I haven't read all the code), promxy executes PromQL via /query_range against backend Prometheus servers, and then runs PromQL once again on the returned data?
Unfortunately I would have to agree with @brian-brazil that this is not a use case we would want to support, since it is fraught with all the problems mentioned above, when not computing PromQL on raw data (configurable staleness delta or not).
Maybe there will be full distributed query evaluation at some point in Prometheus that will do all this correctly, but I believe that's quite far off.

@juliusv promxy optionally switches between query and query_range. I agree that ideally we'd all be able to use raw data always, but sometimes thats not feasible (slow serialization, limited memory, etc).
Regardless of people's opinions on promql against query_range, this PR isn't about promql over query_range, its about being able to control the StalenessDelta with some flexibility when using promql as a library. As I had mentioned earlier this is just as useful for the downsampling case as it is for cases with very tight scrape intervals (as mentioned previously, 5m staleness for a 1s scrape is excessive).

That still doesn't address the lack of granular configuration for the StalenessDelta but hopefully we can completely separate out these two issues.

If someone presents us with a good use case for it we can look at it then, but that has yet to occur.

If someone presents us with a good use case for it we can look at it then, but that has yet to occur.

Wouldn't wanting to change it based on the scrape interval of the remote storage node be a "good use case"? If not, what constitutes a "good use case"?

Wouldn't wanting to change the StalenessDelta based on the scrape interval of the remote storage node be a "good use case"?

No, that's a bad setup. Data in a remote storage node should have the same interval as the the Prometheus, and even then that's something that does not require changing it on a per-query basis.

If not, what constitutes a "good use case"?

One that comes from following the recommended ways to use Prometheus and makes semantic sense.

Data in a remote storage node should have the same interval as the the Prometheus

I think the point here is being missed. If I make something that uses promql and fetches data from multiple prometheus hosts based on some criteria, depending on which prometheus server I send the request to I would want to modify the StalenessDelta.

recommended ways to use Prometheus

Meaning people using the promql library directly are by definition excluded?

Meaning people using the promql library directly are by definition excluded?

Only users using promql directly have the potential to have a valid use for this. Fishing for a valid use case to justify an invalid use case is not a winning strategy.
It has been explained how to handle this properly in your code, I'd suggest taking this advice rather than continuing to follow red herrings.

Only users using promql directly have the potential to have a valid use for this.

This is literally my use-case, I am using promql directly -- not inside prometheus.

Only users using promql directly have the potential to have a valid use for this.

This is literally my use-case, I am using promql directly -- not inside prometheus.

I think what @brian-brazil meant is that there is no use case beyond that, and the use case laid out here using the library directly runs into all kinds of problems (and is very arcane besides that) that make the use case not valid enough.
I was briefly considering that if we at some point add general support for per-query options (that would be exposed to the end-user via the web API), it would be somewhat more palatable to coincidentally also have the staleness delta as one of several options in there. But I do tend to agree with @brian-brazil that this should normally be a server-wide setting and we have not yet seen a valid use case that justifies supporting per-query changes of this.

using the library directly runs into all kinds of problems

What sorts of problems? Currently using promql directly and so far its been working quite well.

and is very arcane besides that

Not sure what you mean by arcane? Its not really old, nor is it magical.
The ask here is not necessarily per-query, its per datasource (since this is a proxy of many prometheus hosts). Because promql is just a library IMO it doesn't make sense for it to know too much about what data came from where, so changing it on a per-query basis seems to make more sense. If we'd rather make promql's package keep track of the scrape interval of the data we could do that-- but that seems like the wrong approach.

Another way of stating it (which is hopefully clearer)-- the StalenessDelta should be tied to the data that you are processing (this is because you want to set it based on granularity of data etc.). In the current state (package-level variable) any program that wants to use the promql package can't use data from sources with different granularity. To solve this I believe there are 2 options (1) per-statement or (2) per-engine. This PR is an implenentation of 1 (since that allows greater flexibility) but if we want to take the second approach thats also fine with me (as I've stated before). Having a single package-wide variable severely limits the usefulness of the promql package

I understand what you are saying, however this is not a use case we feel makes sense to support. There are better ways to approach what you're trying to do, and I following up on the suggestions above.
This discussion is going around in circles, so I'm close it off now.


Update texlab expectation

References
Address failure seen in https://github.com/jupyter-lsp/jupyterlab-lsp/pull/927 and described in https://github.com/jupyter-lsp/jupyterlab-lsp/issues/894#issuecomment-1510410526
Code changes
Updated expected diagnostic value
User-facing changes
None
Backwards-incompatible changes
None

Yep, the build chain changed a fair amount, too... so I guess that's on me.
With rust stuff, if it builds and passes CLI smoke tests, I usually just
ship it. 😳

50 minutes mamba setup on MacOS with py3.10, worth keeping an eye if this is a pattern or one-of:


scp add an extra '@' in front of user name.

let g:netrw_scp_cmd = "pscp -q -i ".$HOME."\aaa.ppk
let g:netrw_list_cmd = "plink -i ".$HOME."\aaa.ppk HOSTNAME ls -Fa "
execute "e<EMAIL_ADDRESS>When I tried to  scp file, vim add an '@' to my username. So the username became "@username", and I unable to login or remote edit any file.

win 7
gvim80 (gvim74 if fine for me.)

Please look at :help netrw-debug and get a debugging trace of your issue and send a copy to me (my email is in the help section -- you'll need to remove the embedded NOSPAM).

Finally, I found what's going wrong.
My username contain '.' (ex: taylor.tang) that cause this issue.
Add a slash could fix this.

I found what's going wrong.
My userame contain '.' cause this issue.
I replace the regex in fun s:RemotePathAnalysis in netrw.vim.
"  let dirpat  = '^(\w{-})://((\w+)@)=([^/:#]+)%([:#](\d+))=/(.)$'
let dirpat  = '^(\w{-})://(([^@]+)@)=([^/:#]+)%([:#](\d+))=/(.)$'
It works for me now.


caprine-bin: remove redundant mainProgram specification

Description of changes
The meta.mainProgam attributes is already specified per-system (per-binary-file to be precise).
This partially reverts commit d26b1b2d4a5c0845f3aee6af86123a2c280c473a.
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[X] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

Wouldn't it make more sense to keep this and remove the attr from the per-system

@Artturin Sounds great. Updated.


Axis Tick Width Setting

Global/Individual Axis Tick Width Setting
Feature description:
The Axis lines have Width settings
plot.XAxis.Line(width: 2);
However, there is no setting to set the width of the ticks (Major/Minor)
Code example:
Individual Axis
plot.XAxis.TickWidth(2);
plot.YAxis.TickWidth(4);

Hi @SaltyTears, this just got added and will be in the next release
ScottPlot.Plot plt = new();
plt.XAxis.AxisTicks.MajorTickLength = 10;
plt.XAxis.AxisTicks.MinorTickLength = 5;

(Those AxisTicks objects have lots of properties that can be customized)


Add confirmation for deleting a note

Adds a confirmation prompt when attempting to delete a note.
The video demonstrates three flows:

Deleting with keyboard navigation (Backspace or Delete) on the Index screen.
Deleting with the Delete icon on the Index screen.
Deleting from the Delete icon (with Advanced Settings enabled) in the Note screen.

Screencast from 2024-03-02 13-36-49.webm

all-contributors add @bricker code

@all-contributors please add @bricker  for code


Angular Release Cadence and Version Numbers

Unless there is anyone in disagreement with a good use case, ng-intercom will follow the major release numbers of Angular. The next released version of ng-intercom will be v6 and the current master will be marked as v5.

<3 i like this. not totally semver-friendly while in beta, but it's a little late for that now. sounds good to me!


[Narwhal] Cache now cleans up the expired entries from sub-caches more reliably

This PR changes the internal data structures in Cache struct from IndexMap<K, VecDeque<OffsetDateTime>> to BTreeMap<OffsetDateTime, K>, to remove expired entries from the cache and fix the memory leak without too much overhead.
Profiling the memory impact of this PR with heaptrack showed following improvements (4-node network, 2000+ rounds = 26 minute run):

Peak heap memory: before 13.9MB, after 9.7MB
Total memory leaked: before 12.7MB, after 6.3MB
Cache::retain_and_insert() peak heap usage: before 5.5MB, after 3.5kB
Cache::retain_and_insert() peak leaked memory: before 5.5MB, after 3.5kB

The implementation partly relies on the convention that Cache call sites are using the same expiration interval for a given sub-cache (e.g. Cache::insert_inbound_transmission() is always called with snarkos_node_narwhal::gateway::CACHE_REQUESTS_INTERVAL- interval). With this assumption, all the expired entries can be safely and efficiently dropped from the same timestamp-ordered cache on every Cache::retain_and_insert() call - even the entries unrelated to the key.

Hmm, CI failure on node-narwhal seems to be related to this PR and especially the commit https://github.com/AleoHQ/snarkOS/pull/2598/commits/deefc6d8c8979e52dbfdd4badab5ca6b894d9d0b which definitely made the test_quorum_threshold flakier.
I can reproduce it locally around 40% of runs, though making tx cannons slightly slower makes the test pass always, so it is a workaround. I'll continue investigations.

I updated the PR with a reduced (down to 1s) time resolution; the test workaround should no longer be needed.

LGTM. Merging (failures unrelated)


fix: k8s dashboard link.

k8s dashboard required https.
http does not currently have a corresponding endpoint.
So if you try to access it like this, you will get an error: "no endpoints available for service".

/approve
(sorry about the wait)


MediaSourceEngine integration tests fail on Safari 10

In Safari 10, MediaSourceEngine integration tests trigger failed assertions in MediaSourceEngine.  Example:
Safari 10.0.1 (Mac OS X 10.12.1) MediaSourceEngine ends the stream, truncating the duration FAILED
	Failed: Spurious updateend event!
	jasmineAssert@test/test/boot.js:37:13
	onUpdateEnd_@lib/media/media_source_engine.js:682:22
	[native code]

This could indicate a bad assumption in MediaSourceEngine, an implementation bug in Safari, or a bad test.  Needs investigation.

Two bugs found in Safari 10's MSE implementation:
https://bugs.webkit.org/show_bug.cgi?id=165336
https://bugs.webkit.org/show_bug.cgi?id=165342


Disable old Catalog's readonly mode

Description
When BTP_CATALOG feature is enabled, we render old Catalog in readonly mode - we should disable this functionality, at least for now (while keeping BTP_CATALOG feature on).

@PK85 please confirm what the behaviour should be here

@valentinvieriu for now just disable that read_only when btp-operator resources are present. Please make it configurable, and when time comes to migrate I will ask u to enable that back.

@PK85 we will disable this, but please create another issue explaining what does it mean to be configurable and when we should put it in read only ( would you have special config map set in the cluster ?)


Make this tool to be able to generate this tool automatically from command line after push to concrete branch

So how the result should look like in the end?


Hardcoded value prevents use with testnets

https://github.com/spacebudz/lucid/blob/2c42cd886c2c4bc64bff8eee639e8805d8bb81fd/src/provider/blockfrost.ts#L54

Hey I'm not sure what you mean exactly?

I'm using Lucid against the preview testnet but it looks like it's querying a mainnet address
blockfrost.js:60          GET https://cardano-preview.blockfrost.io/api/v0/addresses/addr_vkh1ekt7trgums23tkhfjnwkpe3zypzslpdpg8n8xekqqzy3cqtmhjp/utxos?page=1 404


Set session preset (finished)

Added a new option to be able to set up the video/picture quality

@pjcabrera made the change

PR looks good and works great. Tested with CameraManager.CaptureQuality.medium and CameraManager.CaptureQuality.high and it produced files of the expected sizes for each setting.
@manask88 now you need to create another PR from the same branch, but instead of using our master as the base, use https://github.com/lwansbrough/react-native-camera


Windows: fix sparse matrix indexing type

DO NOT MERGE Another guess work...

/test

wtf the failures are gone (986 -> 1xx)?!

Jenkins, test this please

@asi1024 I fixed it. Unlike on Linux, np.intc != np.int32 on Windows.

Jenkins, test this please.

Jenkins CI test (for commit d5690bdaa895ec9401c1a66d3983035694453b5a, target branch master) failed with status FAILURE.

Jenkins, test this please

Jenkins CI test (for commit d5690bdaa895ec9401c1a66d3983035694453b5a, target branch master) succeeded!

LGTM!

Thanks, @asi1024!

btw I think this should be backported.


Strax Wallet

Hi team,
I am experiencing two issues:

I've submitted my token swap csv a while ago and haven't received any confirmation
My Strax Wallet 1.1.0 (Using Mac 11.2.2) is not initialising. The error message keeps saying: "connected to API. Waiting for node to initialise"

Thanks

same here any ideas ?


pull request for e2e test at 01/04/2017 03:15:09

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


WebSSH on iPad OS

How to
First of thank you for the great app. I love a PRO version of it on my iPad. The question I have is about is there a way to establish a connection through a gateway using stdio forwarding like:
ProxyCommand ssh -W %h:%p ....
Thank you,
Julius

Hello @Julius-Lab 👋
Thank you a lot for your support!
Do you need to open a tunnel (local port forward) in order to establish another connection?

Hello Arnaud,
Thanks for your reply! Basically what I need is to find a way how to
trespass the interim server onto another one without having my private key
in the middle. In regular terminal I would do it lik:
ssh -i  -l  -J  zzz.zzz.zz.zzz xxx.xxx.xx.xxx
Thanks.
Julius
On Mon, 2 Nov 2020 at 21:16, Arnaud Mengus<EMAIL_ADDRESS>wrote:

Hello @Julius-Lab https://github.com/Julius-Lab 👋
Thank you a lot for your support!
Do you need to open a tunnel (local port forward) in order to establish
another connection?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/isontheline/pro.webssh.net/issues/95#issuecomment-720671897,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APV32TXINAO6CQHKKQW564TSN4ARVANCNFSM4THXHERA
.

--
Sincerely,
Julius
Julius Labintsev -- Head of Operations
Office: 1-402-337-8004|  Email<EMAIL_ADDRESS>PO Box 460849 Papillion, NE 68046 | http://www.ecomitize.com

@Julius-Lab
Yet WebSSH doesn't support "easy" jump.
So you need Port Forwarding to be setup.
Here xxx.xxx.xx.xxx will be your jump server.
Here zzz.zzz.zz.zzz will be your target server.
Please test these steps :

Add a Tunnel (inside WebSSH) to xxx.xxx.xx.xxx (with correct credentials)

Inside Port Forwarding put : 2222:zzz.zzz.zz.zzz:22

Add now a SSH connection

Inside port put : 2222
Inside host put : <IP_ADDRESS>

Could you try these steps?
Best Regards,

Hi Arnaud,
That did a trick! Thanks so much!
Sincerely,
Julius
On Mon, 2 Nov 2020 at 9:55 PM, Arnaud Mengus<EMAIL_ADDRESS>wrote:

@Julius-Lab https://github.com/Julius-Lab
Yet WebSSH doesn't support "easy" jump.
So you need Port Forwarding to be setup.
Here xxx.xxx.xx.xxx will be your jump server.
Here zzz.zzz.zz.zzz will be your target server.
Please test these steps :

Add a Tunnel (inside WebSSH) to xxx.xxx.xx.xxx (with correct
credentials)

Inside Port Forwarding put : 2222:zzz.zzz.zz.zzz:22

Add now a SSH connection

Inside port put : 2222
Inside host put : <IP_ADDRESS>

Could you try these steps?
Best Regards,
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/isontheline/pro.webssh.net/issues/95#issuecomment-720690515,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APV32TTCV5Q33EICIVK4MDLSN4FEHANCNFSM4THXHERA
.

--
Sincerely,
Julius
Julius Labintsev -- Head of Operations
Office: 1-402-337-8004|  Email<EMAIL_ADDRESS>PO Box 460849 Papillion, NE 68046 | http://www.ecomitize.com

@Julius-Lab You're Welcome!
You can also find Port Forwarding documentation right here if you need : https://webssh.net/documentation/help/networking/port_forwarding/
Have a nice day ☀

Hi Arnaud,
Please see the thread below for the initial request.
The setup you suggested worked pretty well for a long time but after the
update of the app it looks like it added VPN for tunneling and doesn't work
any longer. It fails with the error:
[image: image.png]
Can you suggest how to fix that issue?
Thank you!
Sincerely,
Julius
Julius Labintsev
On Mon, Nov 2, 2020 at 10:05 PM Julius Labintsev @.***>
wrote:

Hi Arnaud,
That did a trick! Thanks so much!
Sincerely,
Julius
On Mon, 2 Nov 2020 at 9:55 PM, Arnaud Mengus @.***>
wrote:

@Julius-Lab https://github.com/Julius-Lab
Yet WebSSH doesn't support "easy" jump.
So you need Port Forwarding to be setup.
Here xxx.xxx.xx.xxx will be your jump server.
Here zzz.zzz.zz.zzz will be your target server.
Please test these steps :

Add a Tunnel (inside WebSSH) to xxx.xxx.xx.xxx (with correct
credentials)

Inside Port Forwarding put : 2222:zzz.zzz.zz.zzz:22

Add now a SSH connection

Inside port put : 2222
Inside host put : <IP_ADDRESS>

Could you try these steps?
Best Regards,
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/isontheline/pro.webssh.net/issues/95#issuecomment-720690515,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APV32TTCV5Q33EICIVK4MDLSN4FEHANCNFSM4THXHERA
.

--
Sincerely,
Julius
Julius Labintsev -- Head of Operations
Office: 1-402-337-8004|  Email: @.***
PO Box 460849 Papillion, NE 68046 | http://www.ecomitize.com

Hello @Julius-Lab 👋
Thanks for your feedback!
VPN-Over-SSH exists since October 2020 :

So I don't understand your new issue.

Doesn't have you used WebSSH in the last months?
Since which version of WebSSH your trouble come from?
Could you post your image from GitHub and not from email? (It seems to be erased)

Have a nice day ☀


Fix the f16 implementation of Literal and LiteralUtil

Adjust the implementation of Literal to do the right thing for F16.   The new Literal class is nice, in that it is just a std::vector of half types, which is nice and simple.
The Proto version still has to have a bit of munging around due to protobuf limitations.

Can one of the admins verify this patch?

@tensorflow-jenkins test this please


modules: hal_nordic: nrfs: callback when connected

User can assign callback function to nrfs ip backend to be notified when connection is actually established. Callback register neeeds to be done before nrfs is initialized.

Considering there can be multiple consumers of the nrfs service, shouldn't we allow registering N callbacks? cc: @tmon-nordic
Added option to register multiple callbacks. N can be configured via Kconfig.


Flow / PA Connections and My Connections instructions outdated

Since the Power Automate rebrand, the Connections and My Connections links have been (re?)moved.
There is no longer a Connections menu item when the gear icon is clicked on. I've tried clicking on the gear icon when in the "My Flows" or "Shared Flows" views and even when editing a Flow but there's no Connections menu item.

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

ID: 97bf9b6c-5628-f18c-7027-45b21eb3b6bc
Version Independent ID: a4394ad5-9d46-2a6d-16d9-48b0c88fb401
Content: Learn to connect to your data using connections and on-premises data gateways - Power Automate
Content Source: articles/add-manage-connections.md
Service: flow
GitHub Login: @stepsic-microsoft-com
Microsoft Alias: stepsic

I faced the same issue, the settings menu on (at least) emea.flow.microsoft.com does not contain a section to manage existing data connections.
A quick workaround that I found, is to go to Power Apps (make.powerapps.com) (make sure you are in the same environment). On the left side, click on 'Data', and then click on 'Connections'. That page will allow you to add and delete connections.

Another workaround is to click on "My Flows" in the navigation pane and then change the end of the URL from /flows to /connections

Thanks @semopz! More than 4 months have elapsed since this issue was reported to Microsoft. It is about time the documentation is updated.

Updates made - changes pending publish.


CommonJS processing: Consider "module" scope

When rewriting a CommonJS module, only process module.exports when
module is not defined in current scope.
For example, if a function has a parameter module, references to module.exports should not be replaced with the new module name (e.g. module$foobar)
var foo = function (module) {
    module.exports = "foo";
};
module.exports = "bar";

https://groups.google.com/forum/#!topic/closure-compiler-discuss/AklSy5PNQ_I

Martin, does this conflict with these your proposed changes?

It might merge conflict due to the change from test(...) to testModules(...), but content wise it's fine.

LGTM.


Tracing error in 6.1.0

Bug description
There seems to be an intermittent tracing error in latest prisma version
How to reproduce
1.) Use prisma version 6.1.0
2.) Get this error
TypeError: this.getGlobalTracingHelper(...).dispatchEngineSpans is not a function
    at ho.dispatchEngineSpans (/web/node_modules/@prisma/client/runtime/library.js:121:1715)
    at Object.query (/web/node_modules/@prisma/client/runtime/library.js:111:11492)
    at async _r.request (/web/node_modules/@prisma/client/runtime/library.js:112:3726)

Expected behavior
Should not have any type error
Prisma information
N/A
Environment & setup

OS: Debian
Database: PostgreSQL
Node.js version: 22.10

Prisma Version
prisma                  : 6.1.0
@prisma/client          : 6.1.0
Computed binaryTarget   : linux-arm64-openssl-1.1.x
Operating System        : linux
Architecture            : arm64
Node.js                 : v22.10.0
Query Engine (Node-API) : libquery-engine 11f085a2012c0f4778414c8db2651556ee0ef959 (at<EMAIL_ADDRESS>Schema Engine           : schema-engine-cli 11f085a2012c0f4778414c8db2651556ee0ef959 (at<EMAIL_ADDRESS>Schema Wasm             : @prisma/prisma-schema-wasm 6.1.0-21.11f085a2012c0f4778414c8db2651556ee0ef959
Default Engines Hash    : 11f085a2012c0f4778414c8db2651556ee0ef959
Studio                  : 0.503.0
Preview Features        : fullTextSearchPostgres, tracing, views, relationJoins, omitApi

I am experiencing the same issue. Are you using observability tools that have a prisma integration? I believe this is due to those observability tools not yet supporting the latest version of the tracing feature.
We had this issue yesterday with Sentry, when Sentry tracing was turned off it would work fine, when turned on it would crash the prisma client. If this is indeed due to observability tools, I recommend downgrading back to 6.0.1 and waiting for your observability provider to release a version that supports this.

Yes, you are correct this is actually due to a clash with Sentry; I believe we just have to wait as you mentioned (as far as I cal tell):
https://github.com/getsentry/sentry-javascript/pull/14624

Obviously, this issue still exists. I used 6.1.0 without Sentry or other observability tools, but still encountered this error

As a +1, I'm getting this error when using Prisma's Optimize with v6.1.0. In case it's helpful, my schema.prisma:
generator client {
  provider        = "prisma-client-js"
  binaryTargets   = ["native", "debian-openssl-3.0.x", "linux-arm64-openssl-1.1.x", "rhel-openssl-3.0.x"]
  previewFeatures = ["tracing"]
}

datasource db {
  provider          = "postgresql"
  url               = env("DATABASE_URL")
  shadowDatabaseUrl = env("DATABASE_SHADOW_URL")
}


Won't Install

I've tried installing both through the installer and URL, and it says it installs, but it gives an error and the mod hasn't installed

Hi there,
Are you using foundry v10?

Hi!  Yes, it says it's v10 Stable - Patch 7 (Build 303)

I didn't test it on v10. it is compatible only to v11.


[release-4.12]: OCPBUGS-20855: bump library-go to include switch to HTTP/1.1

/label backport-risk-assessed
/lgtm
/approve

/jira refresh

/jira refresh

Pre-merge verified the associated bug, got the expected results, detail see https://issues.redhat.com/browse/OCPBUGS-20855?focusedId=23506594&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-23506594

/label qe-approved
/label cherry-pick-approved


Expose batch-swap-output-data getters to package consumers

Summary
It looks like the getters defined for BatchSwapOutputData are exported but never exposed in vite.config.ts for downstream users to access. This PR is a one line change to vite.config.ts that changes that.

Happy we are sharing these now :)


REBASED Nlx lost segments with lost samples

This is just a rebased version of #693
The previous PR became eventually broken when I had reset it and used rebase instead of merge.

Hello @sin-mike! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file neo/rawio/neuralynxrawio.py:

Line 447:27: E222 multiple spaces after operator
Line 462:66: E225 missing whitespace around operator
Line 470:13: E303 too many blank lines (2)
Line 473:1: W293 blank line contains whitespace
Line 479:57: E502 the backslash is redundant between brackets
Line 480:48: E226 missing whitespace around arithmetic operator
Line 480:62: E502 the backslash is redundant between brackets
Line 481:58: E261 at least two spaces before inline comment
Line 483:75: E261 at least two spaces before inline comment
Line 486:35: E261 at least two spaces before inline comment
Line 488:41: E261 at least two spaces before inline comment
Line 489:1: W293 blank line contains whitespace

In the file neo/test/iotest/test_neuralynxio.py:

Line 272:1: E302 expected 2 blank lines, found 1
Line 285:44: E241 multiple spaces after ','
Line 286:57: E231 missing whitespace after ','
Line 288:57: E231 missing whitespace after ','

@samuelgarcia it works!

Absolutly perfect.
Could youfix pep8 please ?

Thank you very much for this tedious pep8.
I will merge this as soon as test pass and so will be 0.8.

This close #693.


Geometry; transformed vertices could be stored when transform changes

This will allow things that need transformed vertices to perform significantly better, as well as the rendering of a single geometry repeatedly (across different batchers for example) to reuse the same cache, instead of recalculating the verts each time.
Obviously it has a memory cost, so maybe it can be optionized and on by default, 2D like games would benefit a lot from it but large meshes might not want that.

New renderer makes this specific listing incorrect/redundant.


queryRaw doesn't support dynamic tables names

Bug description
const values = await prisma.$queryRaw`SELECT type FROM ${collection};`; fails with the error
 Message: `db error: ERROR: syntax error at or near "$1"
However,
const values = await prisma.$queryRawUnsafe(`SELECT type FROM ${collection};`); works fine.
Does anyone know why this occurs? I need to be able to be use the safe version to prevent SQL injection in my app :/
How to reproduce
Raw query a postgres database with a dynamic table name.
Expected behavior
No response
Prisma information
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model spacebudz {
  type              String?
}

Environment & setup

OS: Mac OS
Database: PostgreSQL
Node v16.10.10

Prisma Version
3.2.1

Hello,
You will need to use the following if you want to do dynamic table names and manually write the prepared statement variables:
const values = await prisma.$queryRaw(`SELECT type FROM ${collection} WHERE id = $1;`, "my-id");

Please notice that I am calling $queryRaw as a function above instead of a tagged template variable. When using the tagged template variable version of this API any variables that you will provide in the template literal body will be converted into prepared statement variables like $1 or $2. SQL doesn't support naming tables as prepared variables so that throws the error. So in order to take control of these yourself, you will need to use the function version here.
Also, please avoid using $queryRawUnsafe, it doesn't escape anything and it is almost guaranteed that the resulting API would be vulnerable to SQL injection there if you don't manually escape variables.

Your solution doesn't work.
I get this error when I try it: Argument of type 'string' is not assignable to parameter of type 'TemplateStringsArray | Sql'.

Is it possible to use a variable container the order direction?
I'm trying to do something like this:
const order = 'DESC';
await prismaClient.$queryRaw`SELECT user.name FROM user ORDER BY user.name ${order}`

Hello,
You will need to use the following if you want to do dynamic table names and manually write the prepared statement variables:
const values = await prisma.$queryRaw(`SELECT type FROM ${collection} WHERE id = $1;`, "my-id");

Please notice that I am calling $queryRaw as a function above instead of a tagged template variable. When using the tagged template variable version of this API any variables that you will provide in the template literal body will be converted into prepared statement variables like $1 or $2. SQL doesn't support naming tables as prepared variables so that throws the error. So in order to take control of these yourself, you will need to use the function version here.
Also, please avoid using $queryRawUnsafe, it doesn't escape anything and it is almost guaranteed that the resulting API would be vulnerable to SQL injection there if you don't manually escape variables.

Your solution doesn't work. I get this error when I try it: Argument of type 'string' is not assignable to parameter of type 'TemplateStringsArray | Sql'.

If you remove the parens from the function call the type error shouldn't show up anymore. That said, I still got a syntax error at $1

I actually found a solution to this that's slightly safer imo than $queryRawUnsafe which is you can wrap the table name with const tableArg = Prisma.raw(tableName) and then use tableArg. This makes things slightly safer as its easier to validate the tableName than the entire string.

I found the solution to my original question. If you first save the query in a variable,
const query = `SELECT type FROM ${collection};`

Then evaluating this directly will work, as Prisma won't make any attempt to validate the arguments
const values = await prisma.$queryRawUnsafe(query);

Easy way to get SQL injected, but hey at least you can get your queries to work :)

@MilesConn

I actually found a solution to this that's slightly safer imo than $queryRawUnsafe which is you can wrap the table name with const tableArg = Prisma.raw(tableName) and then use tableArg. This makes things slightly safer as its easier to validate the tableName than the entire string.

This is a great and quick fix that actually worked for me:
Just wrap your inserted variable with Prisma.raw() and it should work.
In this context:
const values = await prisma.$queryRaw SELECT type FROM ${Prisma.raw(collection)};  should do the job!

${Prisma.raw(collection)}

Property 'raw' does not exist on type 'PrismaClient<PrismaClientOptions, never, RejectOnNotFound | RejectPerOperation>'.ts(2339)

@BlakeBrown there is some rules in queryRow that protected the database so you can use queryRawUnsafe, it will work fine

What queryRaw does is to avoid SQL injection by preventing you from just inserting arbitrary strings into your query. If you are 100% sure without a doubt that the string is a safe, valid SQL segment, you can use the Prisma.sql helper. Since it's a template string function, you will need to use it like this Prisma.sql([yourValidStringVariable]).
Here is a completely type-safe way to dynamically set table names and column names in your query, assuming that all your table names and columns names are exactly the same both in the schema and in the database (no %%maps).
import { Prisma } from '@prisma/client';

type ModelName = Prisma.ModelName;

type FieldName<T> = string & keyof T;

export const modelName = (model: ModelName) => Prisma.sql([`"${model}"`]);

export const fieldName = <T>(name: FieldName<T>) => Prisma.sql([`"${name}"`]);

export const manyToManyName = (a: ModelName, b: ModelName) => Prisma.sql([`"${a}To${b}"`]);

Then you can do things like this.
const User = modelName(Prisma.ModelName.User);
const Post = modelName(Prisma.ModelName.Post);

const Id = columnName<User | Post>("id");
const UserId = columnName<Post>("userId");
const Name = columnName<User>("name");
const Message = columnName<Post>("message");

const userName = "johndoe";

type YourType = {
  id: string;
  message: string;
  author: string;
}

prisma.queryRaw<YourType[]>`
SELECT
  ${Post}.${Id},
  ${Post}.${Message},
  ${User}.${Name} AS "author",
FROM ${Post}
JOIN ${User} ON ${Post}.${UserId} = ${User}.${Id}
WHERE ${User}.${Name} = ${userName};
`

Ran into the same issue today.
I am curious as to why is dynamically interpolating the name of a table from a tagged literal string not supported ? Are there any technical issues that prevent this ?
I tried out the solution provided by @pantharshit00 , but it doesn't work
What I am missing is the reason why this bug exists (if it is not then why this isn't considered a bug). The only reference I see in the official docs is the recommendation to use unsafe version of the API , which IMO is a bad recommendation that seems to skirt the actual fix to issue.

I ran into a similar problem upgrading to latest Prisma. For anyone arriving here from a search engine, this was what fixed it for me:
After
await db.$queryRawUnsafe<MyRow[]>(
	`
		SELECT *
		FROM "${myProperlyValidatedTableName}"
		WHERE "id" = $1
		AND "time" >= $2
		AND "time" < $3
		ORDER BY "time" ASC;
	`,
	'some-uuid',
	fromDate,
	toDate,
)

Before
await db.$queryRaw<MyRow[]>(`
	SELECT *
	FROM "${myProperlyValidatedTableName}"
	WHERE "id" = ${'some-uuid'}
	AND "time" >= ${fromDate
	AND "time" < ${toDate}
	ORDER BY "time" ASC;
`)


Type blacklist

Add support for blacklisting types. Fields and methods which have blacklisted types in their signatures should not be generated.

Implemented.


The distinction between single and double quotes makes no sense

Description
I don't really know if this is a suggestion or a bug, but the current way Typst treats quotes is weird.
In text mode, there are two ways to quote something: using single quotes ('single quotes'), or using double quotes ("double quotes"). In English, the former gets rendered as

while the latter is rendered as

This makes sense because both single and double quotes are used in English. Typically, double quotes are used first, and single quotes are used as “second level” quotes.
But this is arbitrary, and it does not make sense for some languages.
For example, in French, the usage is to use guillemets (« guillemets ») as top-level quotes and double quotes (“double quotes”) when nested. Single guillemets (‹ single guillemets ›) are never used in french.
So I guess my suggestion is to get rid of the single/double quotes distinction and instead have a list of quote kind per level for every language—which should also be customizable using the text function—and let the compiler infer the quote level (which I think it already somewhat does) to use the right kind of quotes.
Use Case
As explained above, the main use case is being able to properly quote stuff in languages other than English. The distinction between single and double quotes is used to differentiate between different levels, so let's make it work that way.
With this proposal, languages that have quotes for more than two levels can be supported.

Greetings,
Unless mistaken, I think this issue refers to the handling of "smart" quotes, right? That is, as currently done here:
https://github.com/typst/typst/blob/6af94be34ad1cb657194c788c07681b28d87fbaf/library/src/text/quotes.rs#L124

This makes sense because both single and double quotes are used in English. Typically, double quotes are used first, and single quotes are used as “second level” quotes.

There's a perhaps bit more than meets the eye... British English (or Welsh, and a few other language) use single quotes as primary quotation marks and double quotes as secondary marks, but US English normally uses double quotes as primary marks and single quotes as secondary marks.
The main issue, I believe, is therefore to propose a "decent" interpretation of non-typographical "straight" quotes to be replaced by appropriate typographic primary and secondary quotation marks in a given language, depending both on the expectation of the user and the typographic rules applying to that language.
For reference, you might possibly be interested to look at how I addressed it in smartquotes.sile - It's a package for the SILE typesetter (more precisely, a low-level package notably used for interpreting straight quotes in Markdown/Djot with "smart typography"), but the Lua code should be understandable and it mainly boils down to a big table of (primary, secondary) marks for a bunch of languages, derived from several sources.

With this proposal, languages that have quotes for more than two levels can be supported.

Note however that there are not many languages that have tertiary quotation marks or really use them nowadays; and the rules for using them are not always straightforward (I renounced addressing it in my SILE package -- It doesn't mean is not doable, but it might get trickier if one really wants them, unless it can be checked with native users knowledgeable about the topic).
(As a side note, regarding the above-mentioned current logic in quotes.rs, the use of a \u{00A0} space in French quotes is not really respecting the true typography, but that's a different topic.)

I wanted to add that because there are differences in American and British English, the csquotes (and babel) package in LaTeX does separate languages as american and british (see page 3).
This is why I was "shocked" by the double parameter in the smartquote function. It should go so, there is only one parameter left — enabled.
If it is not something desirable (one parameter function), then things like which quote at which level must be applied, but this implies that enabled must be equal to false (maybe set it to auto | boolean = auto).

With consideration of @Omikhleia's comment and the smartquote.quotes property available, is there still something left to change here?

I think this is an unsolvable issue in the sense that QWERTY keyboards have two kinds of quotes, and there is no perfect way to map them to quotes used in different languages.
I would say that smartquote.quotes is the only way to solve this problem (by giving the control to the user).


Refactor Message.Action UI for HS App

Jira Ticket
This refactors the way that Message.Action Chat items are display; center-aligning text and timestamp.
Before:

After:

Unread Message

Pull Request Test Coverage Report for Build 3024

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 3016:
0.0%

Covered Lines:
154

Relevant Lines:
154

💛  - Coveralls


Possible fix for LocalizedString not displaying in Release mode

Description of Change
Added Preserve to Localized property
Bugs Fixed

Fixes #1069

API Changes
None
Behavioral Changes
None
PR Checklist

[ ] Has tests (if omitted, state reason in description)
[ ] Has samples (if omitted, state reason in description)
[ ] Rebased on top of main at time of PR
[ ] Changes adhere to coding standard

[ ] Updated documentation

@jfversluis Could you please generate a NuGet from this branch, so I can validate the fix?
Everything works even without the fix with NuGet that I'm creating locally.

@maxkoshevoi a nuget package (artifact) is automatically produced, it has already been produced when azure CI checks finished Nuget.zip

Tested fix with NuGet from pipeline. It works.


fix(data-table): prevent selectable datatable with sticky header from jumping

This PR fixes a bug where selecting a datatable row will cause the page to scroll back to the top. It applies a fix suggested in #1230.
Sample code to repro:

Scroll down the page
Select a row
The page should scroll to the top

<script>
  import { DataTable } from "carbon-components-svelte";

  const headers = [
    { key: "name", value: "Name" },
    { key: "port", value: "Port" },
    { key: "rule", value: "Rule" },
  ];

  const rows = [
    { id: "a", name: "Load Balancer 3", port: 3000, rule: "Round robin" },
    { id: "b", name: "Load Balancer 1", port: 443, rule: "Round robin" },
    { id: "c", name: "Load Balancer 2", port: 80, rule: "DNS delegation" },
    { id: "d", name: "Load Balancer 6", port: 3000, rule: "Round robin" },
    { id: "e", name: "Load Balancer 4", port: 443, rule: "Round robin" },
    { id: "f", name: "Load Balancer 5", port: 80, rule: "DNS delegation" },
  ];
</script>

<div style="min-height: 200vh">
  <DataTable stickyHeader batchSelection {headers} {rows} />
</div>

Released in v0.63.0.
Note on upgrading: if using carbon-preprocess-svelte, upgrade to version 0.9.0.


fix codesandbox source on 02_dynamic_attributes

there was a duplicated code leading to a misleading example

Now the code is working as expected.


Label command for resource labeling

Motivation
SM supports labels on resources but the CLI does not support labeling.
Approach
This PR introduces new command for labeling resources.
smctl label [resource] [id] [operation] [key=value1,value2,...]
Where for now resource is one of the following:

platform
broker

And supported operations are:

add
remove
add-values
remove-values

Pull Request status

[x] Initial implementation
[ ] Refactoring
[ ] Unit tests

Coverage decreased (-3.3%) to 72.053% when pulling 4785a0ceceb87542a410b987fb9833ad1f1d3de8 on labels into a55e980cb3ed6965f4ad46038ccceca6e22f736e on master.


Shell script syntax highlighting error

VSCode Version: Code 1.15.1 (41abd21afdf7424c89319ee7cb0445cc6f376959, 2017-08-16T18:07:25.676Z)
OS Version: Windows_NT x64 6.1.7601
Extensions:

Extension
Author (truncated)
Version

Bookmarks
ale
0.15.2

xml
Dot
1.9.2

tortoise-svn
fan
0.1.1

rest-client
hum
0.15.2

AWK
lug
0.0.2

mssql
ms-
1.1.0

PowerShell
ms-
1.4.1

vs-keybindings
ms-
0.1.7

partial-diff
ryu
0.3.1

Steps to Reproduce:

Create a new file
Select Language shell script (Bash)
Enter the snippet

#!/bin/bash
CONT=`cat <<-END1 | wc -l
    line1
    line2
END1`
echo "$CONT"

4.- The last lime must be highlighted as a new statement

Reproduces without extensions: Yes

I don't know if this is really related, but a similar problem arises with herestrings (<<<) :
format() {
    name=$(awk '{print tolower($0)}' <<< $1)
    name=$(sed 's/\s+//g;s/[^a-z]//g'<<< $name)
    echo $name
}

With this snippet, the 2 last lines of the function are not highlighted properly.

VSCode Version: VSCode 1.15.1 (41abd21afdf7424c89319ee7cb0445cc6f376959)
OS Version: Fedora 26 x86_64

Why was this closed ? Has this been fixed ?...


Ability to modify outlink regexes on the fly

The problem
During a run with outlinks enabled, you sometimes discover links you don't want to save (for example, auth pages or infinitely different urls that point to the same content), that you previously weren't able to account for when putting in the initial regexes.
Same with unwanted matches of the outlink regex that the user didn't consider.
Stopping the save is not always an option and comes with it several difficulties (e.g. not saving urls multiple times, not discovering all etc.).
This calls for a way to modify the regex while the program is running.
Suggested solution (new feature)
Have files present in the data directory that contain regexes, and if modified load the new regexes into the program.
I took the functionality of https://github.com/ArchiveTeam/grab-site as an example: They generate an ignores file in the beginning, where you can add a new regex on each line and change old ones. On saving the file, they will be loaded into grab-site, and if one of them matches, the url will be ignored.
For your project, I suggested the following implementation:

In the data folder, generate two additional files:

includes.txt: Contains the regex specified in the -o option on its first line
excludes.txt: Contains the regex specified in the -x option on its first line

Monitor these files for changes (just as you already do with status_rate.txt and max_parallel_jobs.txt)
If a file was changed, load each line of the file as a regex. A match should occur once one of them matches.

This is a good idea. I would need to define behavior for what happens when you restart a session with the -r flag. It would seem to be an improvement on the current behavior if implemented, since currently the outlinks settings aren't kept when restarting.
The way that the existing .txt files are used is that they are just read every time they are used. In this way, the script already checks the files for modifications (by not keeping the data in memory in the first place), though it's perhaps not particularly efficient.
I think loading each line individually shouldn't be necessary, since you could just replace line breaks with the | character (assuming that each line forms a valid regex).

For restarting an aborted session, the script would need to be modified to check if includes.txt and excludes.txt exist; if either of them exist, they should be copied into the new directory, but these would still be overridden by usage of -o or -x in the restart command. Additionally, the completed URLs of the original index would have to be retained and appended to the new index, and the same check-if-exists behavior would have to be done for other settings for which it would make sense. I don't think any other changes would be needed.

Hi, thanks for responding. Detailed analysis, I agree with everything you said.
And yes, only loading one regex from the file is works, the alt character is perfectly fine for that. Only benefit of multiple lines I see is that the regex won't get too long to edit in the file, and because I was used to it from the other program, grab-site.
Depends very much on what you think makes more sense, and what is better to implement.
Keeping outlink settings when resuming would definitely be expected behaviour.
Don't think I have anything else to add, except maybe a thank you for you sharing these useful scripts :-)

I have now implemented the suggested behavior; the files are called include_pattern.txt and exclude_pattern.txt instead of the suggested names, newlines are not treated specially, and I didn't modify the behavior of any flags other than -o, -x and -r.


[BUG] Empty query params are discarded

Investigative information

Timestamp:<PHONE_NUMBER>
Function App name:
Function name(s) (as appropriate):
Core Tools version: 3.2.0-0 Commit hash: 5ffe001695be89a9b33cb569c875aef15938830b

Repro steps
Provide the steps required to reproduce the problem:

Create simple function:
__init__.pyimport azure.functions

def main(req: azure.functions.HttpRequest):
    return str(req.params)

function.json{
    "scriptFile": "__init__.py",
    "bindings": [
        {
            "authLevel": "anonymous",
            "type": "httpTrigger",
            "direction": "in",
            "name": "req",
            "methods": [
                "get",
                "post"
            ]
        },
        {
            "type": "http",
            "direction": "out",
            "name": "$return"
        }
    ]
}

Access function URL with query params ?paramwithvalue=foo&paramwithoutvalue
{"paramwithvalue": "foo"} is returned

Expected behavior
I would expect the HttpRequest.params to contain all query params, defaulting to either a value of None or an empty string:
{
    "paramwithvalue": "foo",
    "paramwithoutvalue": ""
}

Actual behavior
The query parameter is silently discarded:
{
    "paramwithvalue": "foo"
}

Known workarounds
The query param can be retrieved via urllib.parse.parse_qs from the HttpRequest.urlobject:
__init__.py
from urllib.parse import parse_qs, urlparse

import azure.functions

def main(req: azure.functions.HttpRequest):
    return str(parse_qs(urlparse(req.url).query, keep_blank_values=True))

This will return the full set of params:
"{'paramwithvalue': ['foo'], 'paramwithoutvalue': ['']}"

Contents of the requirements.txt file:
azure-functions==1.7.2

Related information
This seems to be an underlying issue in the protobuf implementation and was already fixed in https://github.com/Azure/azure-functions-language-worker-protobuf/issues/49

https://github.com/Azure/azure-functions-language-worker-protobuf/issues/49
https://github.com/Azure/azure-functions-nodejs-worker/pull/326
https://github.com/Azure/azure-functions-nodejs-worker/issues/253

Hi @nathanhi, are you still facing this issue?

Hello, I am still seeing this issue. Are there plans to fix this? There is a fix using UseNullableValueDictionaryForHttp mentioned in the PowerShell worker regarding the same issue https://github.com/Azure/azure-functions-powershell-worker/issues/895.


Feature/BE-9

Implemented login/logout APIs.
Added some options for AUTH_PASSWORD_VALIDATORS to the settings. This will enable us to reject some passwords (common passwords or passwords that contain only numeric characters - easy stuff actually, it's provided by Django).
Updated the Login API so that it can work for both email and username.
These implementations use Knox tokenization, which have serious questions for this: Firstly, how can we use tokenization system? Should we return the token to frontend and should they store it in cache or something? (I believe we will answer this question in a couple of days) Secondly, should we use Knox? Can we use Django authentication or Django Rest Framework authentication systems? Or maybe another third-party tool like JWT? I looked at the previous groups and saw very different practices:

This group seems to have implemented their own authentication system or something that inherits from rest_framework.authentication import BaseAuthentication (wow).
This group seems to have used rest_framework.authentication.TokenAuthentication.
There are some other groups as well using different strategies.

There was no password checking in the registration. I fixed that. Please review carefully folk, I might have missed something. With this PR, api/v1/auth/register/,  api/v1/auth/login/,  api/v1/auth/logout/ should work properly. Don't forget to give Authorization token while trying out the logout functionality. Also name of the parameter should "credential", not "username" or "email" for login - keep that in mind.
In a way this PR is related to #199, #195, #194.

Additionally:

Implemented registeration API. You can test it using http://<IP_ADDRESS>:8000/api/v1/auth/register/ and providing raw data in the following format:

{
    "password": "justification",
    "username": "on_existentialism",
    "email"<EMAIL_ADDRESS>    "password_confirm": "justification"
}

Implemented a unittest regarding the username validation. (Not so important, I was just trying to remember unittests and making sure that my function is working properly).
Please notice that in backend/urls.py, I added path('api/v1/', include('api.urls')). This will include all references to our APIs. I think we won't need to add anything more here. We will be collecting API urls in api/urls.py. Therefore you need to add the route of your API to there after implementation. In practice app, we were adding website routes to django_app/urls, it's because we were trying to render the HTMLs from Django - now we won't do it.

Ran the unit tests, they seem OK.

Registration API

When I tried to give a token to the registration api (In the headers as Authorization, like we did in login api), it gives invalid token error.
This is not necessarily a problem but when the email already exists, it doesn't display other errors such as username being too short. And in some other cases it prioritizes certain errors over others and doesn't display them all.

For login api:

Given {
"password": "justification",
"username": "..on_w"
}
Received:
{
"credential": [
"This field is required."
]
}
Don't know if this was expected behaviour.
And with values expected to exist in database (double checked to see they gave error in the registration phase), received the same result.
When I tried giving the token via Authorization in the headers, received:
{
"detail": "Invalid token."
}
Another thing to consider here is that with admin (superuser) we have the right to override password restrictions, do the checks prevent api from logging the admin in ?

Logout api returns:
{
"detail": "Authentication credentials were not provided."
}

Again don't know if I should have supplied some sort of parameter or token, since the API documentation is not complete as of now.

Other than that Registration API seems to be working, login and logout were working the other they when we tried over online call, I am thinking I was possibly giving the parameters or the token wrong?

Haven't tested the dockerized version of the API's yet.

For Login API:
The parameter name is changed to "credential" in order to support login with both email and username

I updated the API documentation you can check your inputs and outputs from there.

I tested all endpoints they are working without any errors. You can merge the PR @KarahanS .

Another thing to consider here is that with admin (superuser) we have the right to override password restrictions, do the checks prevent api from logging the admin in ?

Created a super user and tested the aut/login/ with the following information:

{
    "password": "admin",
    "credential"<EMAIL_ADDRESS>}

It worked without any problem:


Fix prometheus agent alerts

Before adding a new alerting rule into this repository you should consider creating an SLO rules instead.
SLO helps you both increase the quality of your monitoring and reduce the alert noise.

How to create a SLO rule: https://github.com/giantswarm/sloth-rules#how-to-create-a-slo
Documentation: https://intranet.giantswarm.io/docs/monitoring/slo-alerting/

Towards: https://github.com/giantswarm/...
This PR removes the outside business hours inhibition from the PrometheusAgent inhibiting alerts.
Checklist

[x] Update CHANGELOG.md
[ ] Add Unit tests
[ ] Follow Alert structure
[ ] Consider creating a dashboard (guidelines) (if it does not exist already) to help oncallers monitor the status of the issue.
[x] Request review from oncall area, as well as team (e.g: oncall-kaas-cloud GitHub group).

Is the default value for cancel_if_outside_working_hours false ? Otherwise instead of removing the label we should keep it and set it to false right ?

The default value is that it is not set. I'd rather we remove it altogether to clean up the alert and avoid possible mistakes in changing that value


Adds Jinja macro for email responses

What is the context of this PR?
Adds Jinja Macro to email address
How to review
As Email address is used in several places, A new macro has been added to helpers.html, so that changes to the email address only be made in one place.
To test run the app and check the introduction page, contact us and confirm that email address is a link and inspect.

squishy squashy ?


Fine-tuned checkpoints for visual grounding

Thanks for the amazing effect in organizing such a great open-sourced project.
Just curious is the tiny/huge version of the fine-tuned mode for refcoco available anywhere, which can reproduce the result in Table 4 of the paper?

Tiny and Huge finetuned models are not yet released, but they are on the release schedule.

Got it. Thank you!

Greetings,
Are there any updates regarding the tiny and small finetined models?


[FEATURE] Record the kyuubi server ip address in event log

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Search before asking

[X] I have searched in the issues and found no similar issues.

Describe the feature
Record the kyuubi server ip address in event log. Related discussion: https://github.com/apache/incubator-kyuubi/pull/1524#discussion_r764484736 .
Motivation
No response
Describe the solution
No response
Additional context
No response
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Screenshots after repair:


Seletected Items Should Show More Distinctions

Is your feature request related to a problem?
A clear description of what the problem is.

Selecting folder or/and files should be more distinctive, in light mode, grey shades almost doesn't have contrast background

Describe the solution
A clear description of what you want.

Using Windows accent color would be a good solution similar to native file manager

Describe alternatives you've considered
A clear description of any alternative solutions or features you've considered.
Scope

Capability
Priority

This proposal will allow end users to accomplish better UX
Could

System Information
- OS Version: [Windows 10 21H1 19043.1052]
- App version: [1.5.46]

Yes, a border would be great.

I think this is a bug. In last release it's fine. I think it's showing the dark colour instead the light colour.
This is the colour for selected items in the last release:

I try to find the cause of this bug, but I didn't have luck.
However I found that column view is working as expected on the Column View:

All the others view are facing this issue.

They talked about this on #4643 , so it's something they are aware off.

This issue should be resolved with #5844.


Remove Ory maester dependency from Oathkeeper

Removes Ory Maester Chart dependency from Oathkeeper. Required for Redhat certification as it includes CRDs
Ran helm template asdf helm/charts/oathkeeper | grep maester to check everything was removed
Pulled in updates from ory/k8s and rebased this branch to 0.26.5, the version we are using in controller

I updated this branch to restore the missing Deployments from Oathkeeper, whose templates had been removed. It is also based on the commit for v0.27.1 now.
I don't think we should be merging this into master.


Dynamic Links not passed at first launch

I've integrated dynamic links for iOS as described in docs (https://firebase.google.com/docs/dynamic-links/ios/receive). Everything works as expected except the first launch of the app. This is critical for us as we rely on deeplinks to properly onboard first-time app users from our website.
Steps:
0. The app is not installed.

Click link  from Notes app on iPhone.
Link opened in Safari. The preview page appeared. Then click Open on preview page and redirected to AppStore with our app page opened
Build and install app on device via Visual Studio for Mac.
Run app and receive in openUrl method link as //google/link/?dismiss=1&is_weak_match=1
Expected result - deep link passed to the app. Actual - deep link not passed.

Conditions:

Language set on iPhone is English.
Xcode version: 9.2
Dynamic links diagnostic output:
---- Firebase Dynamic Links diagnostic output start ----
Firebase Dynamic Links framework version 2.3.1
System information: OS iPhone OS, OS version 9.3.5, model iPhone
Current date 2018-07-26 09:19:10 +0000
Device locale en-US (raw en_US), timezone Europe/Kiev
Specified custom URL scheme is  and Info.plist contains such scheme in CFBundleURLTypes key.
AppID Prefix: , Team ID: , AppId Prefix equal to Team ID: YES
performDiagnostic completed successfully! No errors found.
---- Firebase Dynamic Links diagnostic output end ----

I've reported to firebase support and they asked "Could you also try to update your Firebase SDK to the latest version?" As I can see from diagnostic log the latest version from nuget is 2.3.1 and actual for now is 3.0.1. Note that sample project in XCode with latest Firebase/DynamicLinks framework works as expected so I rely on old Xamarin binding library version in this case.
When we can get updated version of Firebase DynamicLinks for iOS on nuget?

@victor-zuev I believe a new version of Firebase for iOS is pending approval and should be available sooon


Clarification regarding a schema containing both oneOf and required types

I have a schema definition as follows.
    RenderRequest:
      oneOf:
        - required:
            - url
        - required:
            - html
      properties:
        block_ads:
          type: boolean
        click_accept:
          type: boolean
        html:
          type: string
        thumb_width:
          type: integer
        url:
          description: The URL to render as an image or video
          type: string
      type: object

I need to understand what is meant by here. First of all, is this a valid schema definition? If so, does this mean that in the RenderRequest, one of url or html is mandatory?

@dilanSachi yes, that's a valid schema.  It means that either url or html, but not both, must be present.
If both are present, then both branches of the oneOf are valid, and since oneOf requires exactly one of its branches to be valid, then the oneOf will fail validation.
If url is present but html is not, then only the first branch is valid, so the oneOf is valid.  Likewise if url is absent but html is present, only the second branch is valid, so the oneOf is valid.  And if neither are present, both branches are invald and the oneOf is invalid.
Does that answer your question?  If so, please go ahead and close this.

Thanks for the informative answer @handrews. This cleared up my confusion.

@handrews a side question. When we have either url or html as a required field, i.e. we should have at least one of these fields and having both is also valid, how to represent this in the schema definition?

Trasferencia bancaria
Mi cuenta _ Cyberpuerta.mx.pdf
3-A-RELACION-CTAS.-BANCARIAS-18.xls

0x4f5f47c2ac7522e2062f246e5cdaf908535aa7b1cff1a9051ba41e0daa81b4f3_en_usd.pdf

@TharmiganK for that just change oneOf to anyOf.


Update README.md

party like it's 2007

Ha. You were serious about the PR.  I've already patched it, but thank you!