Spec: About propagation of active context

The following is defined in the spec.

The implementation MUST propagate the active context on outgoing JAX-RS
requests.

If an LRA is propagated to a resource that is not annotated with any of the
annotations defined in this specification then the LRA will not be made
available to the invoked method. However, any outgoing JAX-RS invocations
made during the execution of the method will still carry the original context.

The above two snippets seems to contradict.
In the first case, we say that only an active context is propagated, but in the second that the header must always (which is probably not wanted) be forwarded and thus also the not active context.
So I propose to remove the sentence

However, any outgoing JAX-RS invocations
made during the execution of the method will still carry the original context.

which means that any JAX-RS resource annotated with @LRA (except @LRA.TYPE.NOT_SUPPORTED) MUST propagate the header.
And thus when we have a call sequence
A -> B -> C
and B is not a participant, @LRA(SUPPORTED) must be specified in order to make the chain complete.
This also allows the developer to have explicitly control when and how the LRA context is passed on and makes it clear when LRA spec comes into play and when not (every time a resource has the @LRA annotation).

This behaviour was requested by a community member (@Emily-Jiang ) in issue #7 so we would need to get her input before making any changes.

I do not agree that the context header needs to be propagated in all circumstances. because

As already mentioned, the developer should be in control. And this is also what you @mmusgrov think (see comment on PR https://github.com/eclipse/microprofile-lra/pull/205/files#r309632890)
It will be much harder to call the LRA.Type.NEVER as you have NO means of removing the context header.
When a regular JAX-RS application (so not using any LRA features) is deployed on an implementation which contains the LRA implementation, this means that the header will be propagated. This is totally unexpected for the developer.

If this always propagate content header is required, we can foresee a config parameter to activate it explicitly.

I think you are arguing against what was agreed in issue #7 so you need to reopen that issue for it to be discussed again.

As already mentioned, the developer should be in control. And this is also what you @mmusgrov think (see comment on PR https://github.com/eclipse/microprofile-lra/pull/205/files#r309632890)

My comment is applicable to any business resource that is in possession of an LRA id. Issue #7 applies to business resources that are not LRA aware. So it is different.

It will be much harder to call the LRA.Type.NEVER as you have NO means of removing the context header.

The business method is in full control of the outgoing JAX-RS headers so, with the exception of LRA_HTTP_RECOVERY_HEADER, he can add and remove them as he sees fit.

When a regular JAX-RS application (so not using any LRA features) is deployed on an implementation which contains the LRA implementation, this means that the header will be propagated. This is totally unexpected for the developer.

But that is exactly what was requested in issue #7 - note that I did not necessarily agree with issue 7 but it was what the community asked for. There is other stuff in the spec that I do not agree with but we use majority voting to decide what goes in and what doesn't.

The business method is in full control of the outgoing JAX-RS headers so, with the exception of LRA_HTTP_RECOVERY_HEADER, he can add and remove them as he sees fit.

Not correct as the implementation MUST always add the Context Header. You as a developer have no means of using the RestClientBuilder to call an endpoint which has no Context Header

There is other stuff in the spec that I do not agree
There is a difference between not agreeing about something which is in the spec but which can be used properly, and things which are in the spec which makes the spec less useable.

Payara will have a config property to switch the automatic context propagation off outside an LRA context.
But it is best to have this config property in the spec, otherwise we can never undo this (unless with a breaking change)

The business method is in full control of the outgoing JAX-RS headers so, with the exception of LRA_HTTP_RECOVERY_HEADER, he can add and remove them as he sees fit.

Not correct as the implementation MUST always add the Context Header. You as a developer have no means of using the RestClientBuilder to call an endpoint which has no Context Header

I do not understand what you are saying here but I will say that the application is allowed to do the following:
                ClientBuilder.newClient()
                .target(baseUri)
                .path(resource)
                .request()
                .header(LRA_HTTP_CONTEXT_HEADER, lraURI)
                .get();

There is other stuff in the spec that I do not agree

There is a difference between not agreeing about something which is in the spec but which can be used properly, and things which are in the spec which makes the spec less useable.

I was responding to your statement:

And this is also what you @mmusgrov think  ...

Anyway my main point is that what you are asking for has already been decided in issue #7 and you need to reopen that issue since your proposal is at odds to what we agreed on issue 7

Question is, how can you call an endpoint with ClientBuilder which does not have LRA_HTTP_CONTEXT_HEADER. set (when the header is present in the incoming call) ?
ClientBuilder.newClient()
            .target(baseUri)
            .path(resource)
            .request()
            .get();

The above solution doesn't works as the implementation MUST add the header as it is defined currently in the spec.

The client is setting the context on the request explicitly:
.header(LRA_HTTP_CONTEXT_HEADER, lraURI)

I will respond here and cross-post if necessary into issue 7.
I remember that I was against the propagation of the LRA context in non-LRA-aware resources back when we discussed it for issue 7 but because of slightly different reasons. I agree with Rudy that users should be aware of where the context is propagated and they should explicitly set it on outgoing requests when they want to propagate it.
Config property seems like a good compromise but I would make the default not propagate and allow to enable automatic propagation on all outgoing requests through config property.
Another option which we discussed back in issue 7 was adding a factory method to LRAClient which would return RestClientBuilder with the LRA header set. I just want to mention it, I know it's out of scope now but it may influence the decision made for 1.0.

No Consensus

@rdebusscher @xstefank and others - can we continue the discussion on this issue. The penultimate comment on the PR was
https://github.com/eclipse/microprofile-lra/pull/226#issuecomment-528285629
Do we want to reopen the issue? There were four options but closing the issue means we have defaulted to option 1  which is the current behaviour. The 4th option was what was proposed in the PR in itself.

I personally think the default should be to propagate and I would support some MP config compatible way to override the default if that helps. I think that by having deploying into an LRA implementation aware container the application implicitly accepts it is in an LRA environment but it should be possible to disable this if it is useful.
+1 to reopen

Using @LRA(propagate=true) will break solution of issue 7 since when there is no @LRA, the headers aren't propagated.

I agree with @tomjenkinson. As a compromise let's go with Rudy's solution of MP Config property but the default will be true. Hopefully, this is a reasonable compromise.

+1

I think the PR could then be reopened and the clarification just changed that the default is true.

Using @lra(propagate=true) will break solution of issue 7 since when there is no @lra, the headers aren't propagated.

@lra(propagate=true) is equivalent to the current behaviour, ie the headers are propagated since that is what the specification currently requires.
In detail, with this new LRA annotation attribute, in order to not propagate the context, the implementation would need to do the following:
Let the call sequence be A->B->C where A and B carry the LRA annotation and C does not.
The implementation will set the header on the outgoing call from A to B:
requestHeaders.put(LRA_HTTP_CONTEXT_HEADER, scheme:[//authority]path?propagate=false)

The implementation at B will see that it should not propagate the context so when B invokes C it knows not to set the context header.

I think the PR could then be reopened and the clarification just changed that the default is true.

@tomjenkinson the reason we are discussing this issue is that asked for changes to the PR where I said the following:

This behaviour should be part of the LRA model and the API, not in config settings. I would advise choosing one of the following three options:

In other words it not just a case of changing the default value.

The implementation at B will see that it should not propagate the context so when B invokes C it knows not to set the context header.

@mmusgrov  Is the above a proposal or the current functionality?
Because this is not how it works today. This is in the spec:

If an LRA is propagated to a resource that is not annotated with any of the
annotations defined in this specification then the LRA will not be made
available to the invoked method. However, any outgoing JAX-RS invocations
made during the execution of the method will still carry the original context.

So In the call from B to C, the headers are propagated.

I would say to override a default behaviour in a system a config option would be the right approach? I think we are saying that service B does not want to propagate by default, in which case service A cannot know that is the case?
One other option is to provide some way in @LRA to set a default of NEVER which could be done in service B somehow - if we want to use API rather than MP config for some reason

The implementation at B will see that it should not propagate the context so when B invokes C it knows not to set the context header.

@mmusgrov Is the above a proposal or the current functionality?

My response quoted your objection:

Using @lra(propagate=true) will break solution of issue 7 since when there is no @lra, the headers aren't propagated.

and my response is my explanation of why option 3 does not break issue 7.

I would say to override a default behaviour in a system a config option would be the right approach? I think we are saying that service B does not want to propagate by default, in which case service A cannot know that is the case?

That is the new functionality in Rudy's PR. I reviewed it and proposed 3 alternative options.
Why does my proposed option 3 not solve the requirement. I have not had any feedback of why it is not practical (Rudy's object does not seem to correspond to what I proposed).

@rdebusscher

In detail, with this new LRA annotation attribute, in order to not propagate the context, the implementation would need to do the following:
Let the call sequence be A->B->C where A and C carry the LRA annotation and B does not.
The implementation will set the header on the outgoing call from A to B:
requestHeaders.put(LRA_HTTP_CONTEXT_HEADER, scheme:[//authority]path?propagate=false)

The implementation at B will see that it should not propagate the context so when B invokes C it knows not to set the context header.

I misunderstood what the exact meaning of propagate=true was.
It doesn't affect the current context (service A), LRA header is present,  but the next endpoint which receives it (Service B)

One more thing about that solution @mmusgrov
A [@LRA(propagate=false] -> B(@LRA(Required, propagate=true)] -> C(whatever)
I assume that the propagate=false doesn't affect Service B and thus it joins the same LRA as service A.
But what does C receive as header?
I guess the 'active context' rule has precedence over propagate=false and thus C will receive a Request with a LRA_HTTP_CONTEXT_HEADER header.

A [@lra(propagate=false] -> B(@lra(Required, propagate=true)] -> C(whatever)
I assume that the propagate=false doesn't affect Service B and thus it joins the same LRA as service A.

My proposal of a propagate attribute is purely to solve your use case for propagation across unannotated resources. So we would need a better name if we go with the solution.
So in your example, since both A and B are annotated, the context propagates to C.
Note that since the default value for this new propagate attribute is true my proposal does not fully satisfy your needs. On the PR I asked the question about this.:

What about the name 'Sticky LRA context'

@lra(sticky=true)

Which results in following code performed by implementation

requestHeaders.put(LRA_HTTP_CONTEXT_HEADER, scheme:[//authority]path?sticky=true)

or sticky=false when not sticky. sticky=true is the default.
When no LRA annotation present for a JAX-RS method, the stickyness determines if the header will be propagated or not.
Examples

A [@LRA(sticky=false)] -> B[] -> C[]

C receives no LRA headers

A [@LRA(sticky=false)] -> B[@LRA(required=true,sticky=false)] -> C[]

C Receives LRA headers.

My interpretation of this is that the 1st sentence in the 2nd paragraph is probably wrong. I think that when we added issue #7 the default LRA type became @LRA(type=SUPPORTS)
This sentence would then evaluate as: "If an LRA is propagated to a resource that is not annotated with any of the annotations defined in this specification then the default LRA type of SUPPORTS will apply"
If there is some reason B would want to suppress this default behaviour then some MP config setting could be investigated.

I never considered changing the default in this way (NOT_SUPPORTED -> SUPPORTED) but I agree that it seems consistent and satisfies Rudy's and Martin's requirements.
I am okay with using config to change default values for annotation attribute values.

@mmusgrov @ochaloup @rdebusscher @xstefank are we OK to vote on this proposal. If so I +1 it

@tomjenkinson What exactly is the proposal? The change of that sentence in the spec? And what is the MP Config setting then?

The change of the default @LRA type to be SUPPORTED (and the corresponding text change) plus the addition of a config property to change that default (it would be set in the "B" microservice container in the example we were using). So long as we all agree that is a good way to address it the actual property name would follow naturally. For example whatever the mp config prefix is ".rs.ws.LRA.Type.default.set" - values can be "REQUIRED|REQUIRES_NEW|MANDATORY|SUPPORTS|NOT_SUPPORTED|NEVER|NESTED" (perhaps a subset of those - e.g. default of NESTED might not be right, I just list the types under https://github.com/eclipse/microprofile-lra/blob/master/api/src/main/java/org/eclipse/microprofile/lra/annotation/ws/rs/LRA.java#L171

TBH this can work to the extent but it still does not cover the original proposal. The idea is to disable the interception of outgoing JAX-RS calls by the LRA implementation when it's not needed which was also the proposal in the PR.

It doesn't allow for the same fine granularity as the 'sticky LRA Context' proposal, but can be used as alternative for initial proposal in issue 201. It allows to keep functionality defined in issue 7 and it is possible to disable the propagation through a config property on JAX_RS resources which doesn't have any LRA annotation.
Only drawback is that developers always need to specify an LRA type in the code since the default SUPPORTED will not start an LRA any longer.

and it is possible to disable the propagation through a config property on JAX_RS resources which doesn't have any LRA annotation.

@rdebusscher I think this is not true because default value of the type will be used if the user doesn't specify any @LRA annotations thus it's either (omitting types that start new LRA) SUPPORTS (like issue 7), NOT_SUPPORTED (412), or NEVER (exception). This is missing the original "ignore LRA header and continue without any LRA information" behavior.

    /**
     * <p>
     *     The resource method is executed without an LRA context.
     * </p>
     */
    NOT_SUPPORTED,

NOT_SUPPORTED doesn't return 412.
When NOT_SUPPORTED set as config value, no context and thus also no propagation when no @LRA.

Sorry, that was my misinterpretation of the spec then. But The resource method is executed without an LRA context. means that method will be executed without LRA (thus it would be suspended) but if any outgoing JAX-RS call is made inside of this method it will still contain the active context. Or is it defined somewhere already that don't propagate is the default behavior for NOT_SUPPORTED?

It can only work if no headers are added to outgoing requests if type NOT_SUPPORTED is defined of course.
But that is how I interprete the spec today and current Payara implementation does not propagate it in this case since it is not active but suspended.

The implementation MUST propagate the active context on outgoing JAX-RS
requests.

Narayana does propagate the header even in this case. @mmusgrov what is the correct behavior, please?

TBH this can work to the extent but it still does not cover the original proposal.

I think the original statement in this issue is about clarifying the ambiguity. IMO the spec should have been updated to state that the default was supports as that really did become the default when #7 was added and it was a bug not to do that.
In other words, since #7 was merged think:

If an LRA is propagated to a resource that is not annotated with any of the
annotations defined in this specification then the LRA will not be made
available to the invoked method.

Should have been stated as:

If an LRA is propagated to a resource that is not annotated with any of the
annotations defined in this specification then the default LRA type of SUPPORTS will be applied.

It would also need this changing: https://github.com/eclipse/microprofile-lra/blob/master/api/src/main/java/org/eclipse/microprofile/lra/annotation/ws/rs/LRA.java#L169

The idea is to disable the interception of outgoing JAX-RS calls by the LRA implementation when it's not needed which was also the proposal in the PR.

To address this I think we add the MP config property to allow the default of SUPPORTS to be overriden. In the example of ABC that setting would be set in "B"s JVM.

The idea is to disable the interception of outgoing JAX-RS calls by the LRA implementation when it's not needed which was also the proposal in the PR.
To address this I think we add the MP config property to allow the default of SUPPORTS to be overriden. In the example of ABC that setting would be set in "B"s JVM.

As an aside, with loose coupling I do not think that A can know that B does not want to propagate the TX hence why I think the MP config option is the MSA compliant way to do stop B propagating the LRA.

Narayana does propagate the header even in this case. @mmusgrov what is the correct behavior, please?

My interpretation is that to be consistent with #7 we should always propagate the suspended context. The receiving service can then decide whether or not it wants to join the suspended context.

Service A starts a long running action involving loosely coupled services B and C. B may not want to join the action but B should not prohibit C from joining it.

Narayana does propagate the header even in this case. @mmusgrov what is the correct behavior, please?

My interpretation is that to be consistent with #7 we should always propagate the suspended context. The receiving service can then decide whether or not it wants to join the suspended context.
[Edit] Of course this statement depends on the outcome of this current discussion.

I think A must propagate to B but if B somehow suspends the LRA (in some manner as yet TBD) it will not be propagated to C.
I think the way to suspend it would be clarify in the Javadoc the semantics of NOT_SUPPORTED to state that if an LRA reaches a method where @LRA(type=NOT_SUPPORTED) (which in the way I have been talking would be by changing the default to this using some MP config setting). Then it will suspend the LRA and prevent propagation to other web targets. I think this aligns with what Rudy was saying earlier.

Aren't we mixing two different concepts here? How does JTA's NOT_SUPPORTED behave? My understanding was that the transaction is just suspended and then reinstated after the method ends. Isn't this kind of use-case something users do and will expect from LRA?
But I agree, the config property is the cleanest solution. But I am still thinking in the manner that was originally proposed in the PR (which I think should be reopened). If we decide we want to change the semantics of NOT_SUPPORTED I just want to be clear on the expectations.

@xstefank I don't think we need to consider JTA in this, I am just saying that we should make the definition of NOT_SUPPORTED explicitly say that the LRA is suspended.

@xstefank I don't think we need to consider JTA in this, I am just saying that we should make the definition of NOT_SUPPORTED explicitly say that the LRA is suspended.

Don't take me wrong, I am just having problem myself to understand whether we all talk about the same thing. So in an example:
A[LRA(type = REQUIRED, end = false)] -> B -> C[LRA(type = SUPPORTS, end = true)]
where B has a config.default=NOT_SUPPORTED. Will

LRA from A be suspended at B and not propagated to C (IIUC Payara)
1a. will the LRA be ended at B? (The default value of end is true. In other words, will non-LRA annotated method at B behave as it was annotated with LRA(type = NOT_SUPPORTED)?)
LRA from A be suspended at B and propagated to C (thus ended at C) (IIUC Narayana)

IIUC we all agree to go with option 1.?

I think should be made to happen.
1a. I am not sure about regarding the end, hopefully @mmusgrov  can confirm
is not what would happen once Narayana implemented the config option.

Can we change the order of the last two parts into mp.lra.annotation.LRA.default.* also would include mp.lra.annotation.LRA.default.value?

Okay.
Are these new config overrides only going apply to methods that do not have any @LRA annotation or is the proposal to apply them more generally? Allowing the defaults for annotated methods to be overridden in the config would mean that we cannot just look at the resource definition and understand what the behaviour will be.
Thinking more about the default for unannotated methods, SUPPORTS versus NOT_SUPPORTED makes sense. But by default I think the incoming context should never be modified by the implementation (ie the end attribute must be false and the cancelOn/ cancelOnFamily attributes empty and the tiimeLimit set to 0).

Are these new config overrides only going apply to methods that do not have any @LRA annotation or is the proposal to apply them more generally? Allowing the defaults for annotated methods to be overridden in the config would mean that we cannot just look at the resource definition and understand what the behaviour will be.

For 1.0 let's go only with default LRA configuration when no @LRA is present on the method. In the later version of the spec, we can discuss whether config overrides for LRA annotation make sense.

Thinking more about the default for unannotated methods, SUPPORTS versus NOT_SUPPORTED makes sense. But by default I think the incoming context should never be modified by the implementation (ie the end attribute must be false and the cancelOn/ cancelOnFamily attributes empty and the tiimeLimit set to 0).

Agreed. But whoever will be doing the PR this should be clearly stated what values are used in the defualt case.

Regarding the property name the reason I suggested the suffix ".rs.ws.LRA.Type.default.set" in this comment was because the LRA annotation lives in the rs.ws package.
Based on what I am reading it would end up as:
mp.lra.annotation.rs.ws.LRA.Type.default=SUPPORTS
mp.lra.annotation.rs.ws.LRA.end.default=true

I'm not sure about the default in the config property. Since that could give the impression that it is the default when the developer doesn't define any value on the LRA. But it is the 'default' when no annotation is defined.
I do not have a better alternative for the moment, I'll think about one.

I actually had .set in there too in my initial comment. Does this look better:
mp.lra.annotation.rs.ws.LRA.Type.default.set=SUPPORTS
mp.lra.annotation.rs.ws.LRA.end.default.set=true

That syntax is mixing namespaces. How about simply:
mp.lra.LRA.value=SUPPORTS
where mp.lra picks out the project name and LRA.value is unambiguous since we only have one LRA annotation and only one value attribute.
Or the uglier long winded version:
mp.lra.org.eclipse.microprofile.lra.annotation.ws.rs.LRA.value=SUPPORTS
I also cannot suggest any wording that says the override only applies to unannotated methods (but I'd imagine that the documentation will suffice).

Sorry, yes I mean "value" not "type", leading to:
mp.lra.org.eclipse.microprofile.lra.annotation.ws.rs.LRA.value=SUPPORTS
I think that adding .default or .overrideUnSetDefaultTo or something is fine because normally the value will not be present and in order that someone uses it they have to have read our spec so it should be clear there that SUPPORTS is the default and this property overrides the default in the unset case
mp.lra.org.eclipse.microprofile.lra.annotation.ws.rs.LRA.value.overrideUnSetDefaultTo=SUPPORTS

+1 to Mike's proposal. Longer config values typically lead to more typos which are hard to find.
@tomjenkinson In my experience, config value keys do not contain operations like set or override*. I may be wrong, but we can always change the config name in the breaking release of the spec. I would personally favor shorter name.

@xstefank I am inclined to agree with your second statement. Taking that into account I +1:
mp.lra.org.eclipse.microprofile.lra.annotation.ws.rs.LRA.value=SUPPORTS
It is conceivable that a different LRA annotation type would be created, although it would be likely to have the same structure as the REST ones can we be certain?
I would expect we can transmute the property to any conceivable LRA configuration option and in cases where that was not possible for some reason I suppose it would just lead to further docs. That makes me +0 on:
mp.lra.LRA.value=SUPPORTS

I want to propose a PR related to this issue and I have a question about it @mmusgrov @xstefank @tomjenkinson.
We agreed on config parameter mp.lra.LRA.value.  So i'll describe that.
But what effect will it have exactly on a NON annotated JAX-RS method?
For example, the default config value mp.lra.LRA.value=SUPPORTS mean that when a not annotated (running on a MP LRA compliant implementation) JAX-RS endpoint, performing a call to another endpoint, the header values will be propagated (if present).
But is only the propagation logic applied or is all LRA related functionality performed? (also starting a new LRA if needed and when the corresponding LRA.Type is defined as config value)
So, for example mp.lra.LRA.value=REQUIRED, will it then also start a new LRA and define the header parameters?
In my opinion, having only the propagation part will confuse users. They define the same LRA.Type annotation as config parameter, but is doesn't have the same effect when they actually use that same value as annotation on the JAX-RS method.
So mp.lra.LRA.value=REQUIRED will start a new LRA (which is ended by default when return is send back due to end=true) in my proposal. OK?

That would be my assumption. For each of the types they should follow the precise definition from the spec.

Yes, I agree. If this will run into pushback from users, we can add a property that will specify resources to which default policy applies (or doesn't apply) -- so something like blacklist/whitelist. But for the start let's go with the behavior you've proposed.

When updating the spec for this, I came across another 'problem'.
I wanted to write that when a JAX-RS endpoint is not annotated, the system behaves as if there is a @LRA annotation defined, with de default values for the members and the type value from the parameter mp.lra.LRA.value.
But that means that a LRA which passes a not annotated endpoint, it is closed by default (which is not what we want).
So I need to say that the default values for the members are used expect for end which is false in this case.
Remarks about this solution?

@rdebusscher Yes, just include please a paragraph specifying the default values. We shouldn't close LRA by default.

I thought this feature was to control whether or not the context gets propagated to other services. So the only valid values for this new property are SUPPORTS and NOT_SUPPORTED. We cannot control all the annotation attributes from the config properties since that would make it a nightmare trying to figure out how the system will behave. There is a lot to read in the comment history above and I may have missed some conversation but this is my understanding of the requirement.

Ok, I'll limit the config value to SUPPORTS and NOT_SUPPORTED.

Based on the remarks on the initial PR, we decided to use a boolean type for the configuration value mp.lra.propagation.active.


Change the csv export gcs bucket's location to match cloudsql deployment

Currently oso-csv-exports is being used as the transitory GCS bucket for bq2cloudsql. However, we seem to be incurring transfer charges (not large) between it's multi-region us and us-central1 (CloudSQL's location). In theory we should be able to save money by having that bucket match the cloudsql location.

From what I can tell in our June bill
BigQuery network costs were $0.70.
GCS netwwork costs were $107

Ah ya. This is probably not all the important then. That almost seems more like it’s just normal usage as opposed to cost of transfer for all that data


Quest Typo - Fallen But Not Forgotten

Should be "A newly opened crypt stands open before you, do you (dare?) enter?"

Dare is not needed, Only thing I would, and will, change is the second open.


CHORE - Remove Trailing Spaces

Remove trailing spaces.
Saves 0.010529 megabytes.

Thanks. It seems even React Native original source codebase has these. And I certainly need to setup some sort of the linter for that.


[NNPA] Add stickify and enable constant propagation for zhigh ops

This patch makes stickify code open-sourced and enable constant propagation for zhigh ops including stick/unstick ops. This is the last piece of code we would like to open to make sure that all optimization and lowering passes functionally work well in onnx-mlir.
The old convert.c that converts fp32 to dlf16 is replaced by a new code in DLFf16Conversion.hpp that supports both fp32-to-dlf16 and dlf16-to-fp32.
Signed-off-by: Tung D. Le<EMAIL_ADDRESS>

To my understanding, we added a separate pass for zhigh ops. Can we just add the rules to our constant propagation? The benefits are 1) no need to iterate over the passes if the folding interferes each other 2) avoid redundant code is utility functions.

To my understanding, we added a separate pass for zhigh ops. Can we just add the rules to our constant propagation? The benefits are 1) no need to iterate over the passes if the folding interferes each other 2) avoid redundant code is utility functions.

Yes, I think it would be our ultimate goal to support constant propagation for accelerators in an optimal way. However, it is still debating how to mix code among onnx-mlir and accelerators given that accelerator code is only loaded/compiled when necessary.
This patch is only to enable our existing constant propagation for zhigh as it is to make sure it functionally works in onnx-mlir.

Jenkins Linux amd64 Build #4377 [push] [NNPA] Add stickify and ... started at 21:46

Jenkins Linux s390x Build #4389 [push] [NNPA] Add stickify and ... started at 22:46

Jenkins Linux ppc64le Build #3505 [push] [NNPA] Add stickify and ... started at 22:49

Jenkins Linux s390x Build #4389 [push] [NNPA] Add stickify and ... passed after 46 min

Jenkins Linux ppc64le Build #3505 [push] [NNPA] Add stickify and ... passed after 51 min

Jenkins Linux amd64 Build #4377 [push] [NNPA] Add stickify and ... passed after 58 min


How to create a Host instance?

I'm trying to make an ioc container by myself,but having problems with creating an instance of Microsoft.Extensions.Hosting.Internal.Host .
I can't create an instance of OptionsFactory
Here's the call chain IHost->Host->IHostLifetime->ConsoleLifetime->IOptions<ConsoleLifetimeOptions>->OptionsManager<ConsoleLifetimeOptions>->IOptionsFactory<ConsoleLifetimeOptions>->OptionsFactory<ConsoleLifetimeOptions>.
But there's no ImplementationType for params in OptionFactory's constructor(like IConfigureOptions<ConsoleLifetimeOptions>),I tried using null to  replace params but it doesn't work:(
So how to solve it?
Thanks a lot~

See
https://github.com/aspnet/Extensions/blob/f0bbe1da7dcd1fe28ac1bfbb6cfb89fb99e18f60/src/Options/Options/src/OptionsServiceCollectionExtensions.cs#L33
https://github.com/aspnet/Extensions/blob/f0bbe1da7dcd1fe28ac1bfbb6cfb89fb99e18f60/src/Options/Options/src/OptionsFactory.cs
Does your container handle open generics?

See
https://github.com/aspnet/Extensions/blob/f0bbe1da7dcd1fe28ac1bfbb6cfb89fb99e18f60/src/Options/Options/src/OptionsServiceCollectionExtensions.cs#L33
https://github.com/aspnet/Extensions/blob/f0bbe1da7dcd1fe28ac1bfbb6cfb89fb99e18f60/src/Options/Options/src/OptionsFactory.cs
Does your container handle open generics?

I handled IOptionsFactory<> to OptionsFactory<>.
The problem is that I can't create a instance of  OptionsFactory<ConsoleLifetimeOptions>.
Like
https://github.com/aspnet/Extensions/blob/f0bbe1da7dcd1fe28ac1bfbb6cfb89fb99e18f60/src/Options/Options/src/OptionsFactory.cs#L24
or
https://github.com/aspnet/Extensions/blob/f0bbe1da7dcd1fe28ac1bfbb6cfb89fb99e18f60/src/Options/Options/src/OptionsFactory.cs#L33
They both need a IEnumerable<IConfigureOptions<TOptions>> and I try to make it List<IConfigureOptions<TOptions>> but there's no ImplementationType for IConfigureOptions<TOptions> is serviceDescriptors.

https://github.com/aspnet/Extensions/blob/f0bbe1da7dcd1fe28ac1bfbb6cfb89fb99e18f60/src/Options/Options/src/OptionsServiceCollectionExtensions.cs#L72

https://github.com/aspnet/Extensions/blob/f0bbe1da7dcd1fe28ac1bfbb6cfb89fb99e18f60/src/Options/Options/src/OptionsServiceCollectionExtensions.cs#L72
https://github.com/aspnet/Extensions/blob/256db1159910527cbe5d7e72623953fb5f6258b0/src/Options/Options/src/OptionsBuilder.cs#L56
https://github.com/aspnet/Extensions/blob/256db1159910527cbe5d7e72623953fb5f6258b0/src/Options/Options/src/ConfigureOptions.cs#L12

I call them manually and it finally works...
I checked Extenssion.DependcyInjection and Autofac but neither of them call those extenssion methods so I thought it was called automatically :(
How does Asp.Net Core DependencyInjection handle this?

Are you running a full web app or a minimal console app? It may just be a coincidence that these are always called by web app components or CreateDefaultBuilder.
https://github.com/aspnet/Extensions/blob/026865e0bd62db73dc71fc72ec8cc91904cd1995/src/Hosting/Hosting/src/Host.cs#L56

Are you running a full web app or a minimal console app? It may just be a coincidence that these are always called by web app components or CreateDefaultBuilder.
https://github.com/aspnet/Extensions/blob/026865e0bd62db73dc71fc72ec8cc91904cd1995/src/Hosting/Hosting/src/Host.cs#L56

I'm using asp.net core web api demo created by visual studio(WeatherForecast).
Here is my Program.cs(I added list line UseServiceProviderFactory)
    public class Program
    {
        public static void Main(string[] args)
        {
            CreateHostBuilder(args).Build().Run();
        }

        public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>();
                }).UseServiceProviderFactory(new ServiceProviderFactory());
    }

Here's my Startup.cs (I didn't change it)
    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }
        public IConfiguration Configuration { get; }
        // This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddControllers();
        }
        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            app.UseRouting();
            app.UseAuthorization();
            app.UseEndpoints(endpoints =>
            {
                endpoints.MapControllers();
            });
        }
    }

.UseServiceProviderFactory(new ServiceProviderFactory()) is my container,if I remove this line, app works perfectly,if I replace it with .UseServiceProviderFactory(new Autofac.Extensions.DependencyInjection.AutofacServiceProviderFactory()),it alse works(I only add this line when I'm using Autofac)
But when I use my container,I can't find a ImplementationType  for IConfigureOptions<ConsoleLifetimeOptions> or 'IPostConfigureOptions'  in the ServiceCollection passed by
https://github.com/aspnet/Extensions/blob/026865e0bd62db73dc71fc72ec8cc91904cd1995/src/Hosting/Hosting/src/HostBuilder.cs#L226
I output them to a txt file https://github.com/DaemonWalker/Daem0n/blob/master/Daem0n.SimIoc/ServicedDescriptors.txt
I  modified Startup.ConfigureServices like this and it worked
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddControllers();

            services.Configure<ConsoleLifetimeOptions>(_ => { });
            services.PostConfigure<ConsoleLifetimeOptions>(_ => { });
            services.Configure<HostOptions>(_ => { });
            services.PostConfigure<HostOptions>(_ => { });
            services.Configure<SocketTransportOptions>(_ => { });
            services.PostConfigure<SocketTransportOptions>(_ => { });
            services.Configure<KestrelServerOptions>(_ => { });
            services.PostConfigure<KestrelServerOptions>(_ => { });
            services.Configure<FormOptions>(_ => { });
            services.PostConfigure<FormOptions>(_ => { });
        }

Do I miss some functions to call? I don't think this is a good way to get ImplementationTypes😂

It sounds like your open generics implementation isn't working right. @halter73 may have more context on that.

They both need a IEnumerable<IConfigureOptions<ConsoleLifetimeOptions>> and I try to make it List<IConfigureOptions<ConsoleLifetimeOptions>> but there's no ImplementationType for IConfigureOptions<ConsoleLifetimeOptions> in serviceDescriptors.

I think this is your main issue. IoC Containers used by ASP.NET Core are expected to return an empty IEnumerable if there is no service definition for the contained type. So in this case, if theres no definition for IConfigureOptions<ConsoleLifetimeOptions> or IConfigureOptions<> , the container should simply inject an empty IEnumerable<IConfigureOptions<ConsoleLifetimeOptions>>.
We have specification tests that verify IoC containers meet the minimum requirements for ASP.NET Core. The specific test to verify this behavior is called NonexistentServiceCanBeIEnumerableResolved. You can test your own container by deriving from the DependencyInjectionSpecificationTests test class and overriding the CreateServiceProvider.

They both need a IEnumerable<IConfigureOptions<ConsoleLifetimeOptions>> and I try to make it List<IConfigureOptions<ConsoleLifetimeOptions>> but there's no ImplementationType for IConfigureOptions<ConsoleLifetimeOptions> in serviceDescriptors.

I think this is your main issue. IoC Containers used by ASP.NET Core are expected to return an empty IEnumerable if there is no service definition for the contained type. So in this case, if theres no definition for IConfigureOptions<ConsoleLifetimeOptions> or IConfigureOptions<> , the container should simply inject an empty IEnumerable<IConfigureOptions<ConsoleLifetimeOptions>>.
We have specification tests that verify IoC containers meet the minimum requirements for ASP.NET Core. The specific test to verify this behavior is called NonexistentServiceCanBeIEnumerableResolved. You can test your own container by deriving from the DependencyInjectionSpecificationTests test class and overriding the CreateServiceProvider.

Uh, I get it~
Appreciate to you and @Tratcher's help~

@DaemonWalker BTW, if you want to add the specification tests to your own test project, you can reference the Microsoft.Extensions.DependencyInjection.Specification.Tests NuGet Package. This package includes the DependencyInjectionSpecificationTests abstract base class that your own test project can derive from. These are xUnit tests FWIW.


Add ability to specify proxy address (proxies)

Scenario which you are working on
(https://github.com/microsoft/azure_arc/tree/main/docs/azure_arc_jumpstart/azure_arc_servers/scaled_deployment/vmware_scaled_powercli_win)
Describe the bug
The scenario does not take into consideration customers who require proxies to connect externally.
Expected behavior
Ability to add proxy addresses to the script, and the script should configure the Hybrid Instance Metadata service (HIMDS) with the correct proxy configuration.

Hey @Msftblue, we will not be working on this specific scenario for now but we are working on an end-to-end Azure Arc-enabled servers behind proxy configurations.
If you would like to update this current issue, more then happy to review it.


42Berlin

42Berlin

@irrivero First stage of verification passed, official domain is 42berlin.de as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

Hi @philipto ! Thanks for the update!
The official students domain is student.berlin42.de
Is this correct?

@irrivero Pull request merged. Yes, you are right. Thank you.


We. need. faster. builds.

Currently the Benchmarks are also tested when unit tests run (both, on CI Server and on a local machine).
When cherry picking for a release, many builds are involved (after each cherry-picked commit). For 2.0.4 it were 47 commits.
In 2.0.3 one mvn clear test ran 01:29 min on my machine. On current master it runs 07:40 min.
That. is. too. long.
Overall build time

47 commits * 01:29 min = < 1 hour
47 commits * 07:40 min = 6 hours

The next release has nearly 700 commits.

Goal: Create faster builds
Non-Goals: Remove tests completely

Suggested solution:

Locally run only non-benchmark unit-tests (by default). By switch (e.g. Maven profile) the benchmark tests can also be run locally
On the CI server the benchmark unit tests should run by default to ensure nothing broke.

Note: Next week I meet Stefan Oehme (Gradle Gmbh) in Kiel to create a Gradle build for Javaslang.

+1 for a Gradle build, though that's not the source of slowdown.
Our build is not very complicated, should be doable in a few days :) (I've done more Maven to Gradle transitions that I'm proud to admit ...).
Also, if you cherrypick locally and commit the result only once, resulting in a single build.

We will move to Gradle and optimize the build #1277

@danieldietrich, why do you think Gradle will make the tests run faster?

@paplorinc The travis CI build time does not matter to me. It is the local build time that matters when I cherry-pick commits for a release.
When switching to Gradle I will add options to disable GWT tests and Benchmarks. I will run these once before pushing.

As mentioned previously, you can do that today also, by cherrypicking everything locally, and push only at the end.
I don't think Gradle will do anything differently here.
If Travis supports it, we may try parallel tests, however :) (probably possible in Maven also)

I think it can be configured with Maven Surefire Fork option


chore(main): release 0.34.3

:robot: I have created a release beep boop
0.34.3 (2023-06-22)
Bug Fixes

main (7a0cf0d)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/samuele-cozzi/obsidian-marp-slides/releases/tag/0.34.3 :sunflower:


⚠ Bofrost.nl has degraded performance

In 8600493, Bofrost.nl (https://www.bofrost.nl) experienced degraded performance:

HTTP code: 200
Response time: 1262 ms

Resolved: Bofrost.nl performance has improved in 175e516.


Update frontend flow for primary characters

i made a new endpoint
PUT characters/primary
this is how we shouldset primary characters from now on
instead of adding a token for them / replacing the existing token
it's problematic because when you add a new token it replaces the old one
and we need to have CEO tokens
but CEOs are often mains
so that flow is just fucked
but new endpoint will fix this
https://api.minmatar.org/api/docs#/Characters/eveonline_routers_characters_set_primary_character
use this instead of https://api.minmatar.org/api/docs#/Characters/eveonline_routers_characters_add_primary_character pls
<3
i have a lot of tickets to do for actual work today
but i want to get a lot of the notification logic in

Implemented with #214


MNT: Re-rendered with conda-smithy 3.1.12 and pinning 2018.09.11

Add Python 3.7

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

Whenever possible python packages should use pip. See https://conda-forge.org/docs/meta.html#use-pip

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


golang driver for oracle timesten

https://github.com/golang/go/wiki/SQLDrivers
please help me, i want golang driver for oracle timesten,

Please see https://github.com/golang/go/wiki/Questions. Closing, not a Go project issue.

@chuongnx , Hi, have you found such driver? I found goracle that support OCI/ODPI-C, It is ok to connect to traditional oracle database using goracle, but I failed to connect to TimesTen though timesten support OCI/ODPI-C.
If you find some method or lib, can you share me ?

Hi sinylei, I have not yet find it


[firebase_auth] inconsistency in reporting user metadata

The firebase user data that I get from FirebaseAuth.instance.currentUser() is inconsistent. Here is the result that I get:
{
  "android": {
    "uid": "ZyGkKQalyleXQiNqDyNMjlk8E4U2",
    "isAnonymous": false,
    "phoneNumber": "+498531790054",
    "providerData": [
      {
        "uid": "ZyGkKQalyleXQiNqDyNMjlk8E4U2",
        "phoneNumber": "+498531790054",
        "providerId": "firebase",
        "displayName": "Răzvan Lung"
      }
    ],
    "providerId": "firebase",
    "displayName": "Răzvan Lung",
    "creationTimestamp":<PHONE_NUMBER>352,
    "lastSignInTimestamp":<PHONE_NUMBER>352,
    "isEmailVerified": false
  },
  "ios": {
    "uid": "ZyGkKQalyleXQiNqDyNMjlk8E4U2",
    "isAnonymous": false,
    "phoneNumber": "+498531790054",
    "providerData": [
      {
        "email": null,
        "providerId": "phone",
        "photoUrl": null,
        "displayName": null,
        "uid": null,
        "phoneNumber": "+498531790054"
      }
    ],
    "providerId": "Firebase",
    "displayName": "Răzvan Lung",
    "email"<EMAIL_ADDRESS>    "photoUrl": null,
    "lastSignInTimestamp":<PHONE_NUMBER>,
    "creationTimestamp":<PHONE_NUMBER>,
    "isEmailVerified": false
  }
}

The timestamps are a big issue. Also on android the provider is different.

With inconsistent you mean different between iOS and Android?

yes

I second this... Timestamp values are different on each platform and the providerId character case.

Yes, I can confirm this behaviour. On iOS, timestamps are returned as seconds, while on Android they're returned as miliseconds. Any chance this can be fixed?

In the javascript API, the photoUrl is retrieved as "photoURL" and in the firebase_auth it is "photoUrl".  Separate issue?

I don't think this is an inconsistency. If you look at the C++ SDK you will
see the name is different there also. Then naming can follow the
conversation of the  language. The issue here is the value it contains.
On Sat, 13 Jul 2019 at 01:59, dcoleyoung<EMAIL_ADDRESS>wrote:

In the javascript API, the photoUrl is retrieved as "photoURL" and in the
firebase_auth it is "photoUrl". Separate issue?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/27986?email_source=notifications&email_token=ACG2OVQZ6QZAIUVUHIHUKH3P7EEEPA5CNFSM4GXT36S2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ3B5AQ#issuecomment-511057538,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACG2OVWMS2CNOQ4XE7IOMLLP7EEEPANCNFSM4GXT36SQ
.

Got it; thanks for the clarification.  I guess when I google firebase docs JavaScript is the first result and I should rely on dart and flutter official.

@collinjackson Can you please assign this to me?

@long1eu
This issue has been moved to https://github.com/FirebaseExtended/flutterfire/issues/440. Any further collaboration will be done there.


the action sheets cover the explorerWindow

The action sheets cover the explorerWindow, So I can't touch the explorerWindow.

I think it should be
  self.explorerWindow.windowLevel = UIWindowLevelAlert * 2;

Thanks.

There's a tradeoff here that I think we'll have to live with. The FLEX modals need to present alerts and action sheets, so having the FLEX window above the alert level is not an option. If you're interested in exploring alerts, you can temporarily raise the FLEX window level.


Show All Objects

Show all objects doesn't work for private collections

Fixed for a while. Checked and working correctly with #576


[hmac,dv] FIFO empty interrupt and test mode pins

Verify FIFO empty interrupt register to tackle issue #21815
Add checks on interrupt pins when test mode is triggered via the dedicated register INTR_TEST

I still need to run a full regression to be sure nothing is broken, but you could start to review it

@vogelpi I have added a temporary workaround to be able to merge without taking the related RTL fix from this PR https://github.com/lowRISC/opentitan/pull/23739.
Now, this PR could be merged into the master and won't break anything.

@vogelpi, as it has been decided to merge the RTL fix from this PR #23739 , I have reverted the proposed workaround mentioned above.
If needed, it could be reestablished, see this commit: https://github.com/lowRISC/opentitan/commit/55e20274ed386a1ad7ff6aa453ea9440ff39f49b

Hi @martin-velay! Would you mind rebasing this over recently merged changes?

Sorry, I jumped the gun! It turns out that the rebasing wasn't too hard. Happy for either of us to merge, but maybe it makes sense to wait long enough to check that I didn't accidentally break the compile.

Thanks @rswarbrick . The DV checks passed already. What's left are the FPGA tests which are not affected by this. I am thus merging the PR now.


feat: support the new eslint config.

eslint has introduced a new format config(eslint.config.js): https://eslint.org/docs/latest/use/configure/configuration-files-new
ideally, we could support both formats: eslintrc/flat.

I'm preparing the v16 release, and I have merged a few breaking changes that dropped node.js < 16 supports.
Do you think it's worthy to port this to v15, so that it can be used in eslint repo (as of now it support node v12)? @mdjermanovic

Preparing the v16 release, and I have merged a few breaking changes that dropped node.js < 16 supports.
Do you think it's worth porting this to v15, so that it can be used in eslint repo (as of now it supports node v12)? @mdjermanovic

I think it isn't necessary to port this to v15. CI linting in the eslint repo runs on Node 18 so that will be okay. We don't have official requirements for local development environments but I think it's reasonable to assume that a non-eol version of Node.js should be used. I believe we're already using some scripts and dev dependencies that don't work in all Node.js versions that eslint supports.


[core-http] fix systemErrorRetryPolicy issue of not retrying at all

Oh, one more thing, can you add a changelog entry?

Updated CHANGELOG


FHIR Proxy reference links broken

The following file : https://github.com/microsoft/health-architectures/blob/master/HL7Conversion/README.md also contains broken links due to FHIR Proxy being moved in its own repo.

Thanks for catching that - we've asked the document writer to correct this.


Need SQLCipher and ForestDB + Encryption LiteServ .apks in latestbuilds

Duplicated with #1266. I think we don't have enough time to do this for 1.3 release? What do you think?

@hideki I really think we should if it is fairly quick to do.


feat: translate Rust method comments

Changes
Part of #960. (Please don't release immediately, there are more changes left in the series)
Checklist

[x] An issue to be fixed by this PR is listed above.
[x] New tests are added to ensure new features are working. End-to-end tests are usually in the ./frb_example/pure_dart example, more specifically, rust/src/api.rs and dart/lib/main.dart.
[x] The code generator is run and the code is formatted (via just precommit).
[ ] If this PR adds/changes features, documentations (in the ./book folder) are updated.
[ ] CI is passing.

Remark for PR creator

Justfile is a task runner for the command line interface that allows you to run shell commands from a file named justfile in your project directory. You can use Justfile after installing it. Note that commands written in justfile of this repository are expected to be run in bash, not cmd or powershell. Running just ... commands in cmd or powershell will produce errors as the syntax is not compatible. On Windows, you can use git bash if you have Git installed.
If fzyzcjy does not reply for a few days, maybe he just did not see it, so please ping him.

Good job!

Please don't release immediately, there are more changes left in the series

Do you mean do not merge the PR, or merge it but do not publish a new version?

Do you mean do not merge the PR, or merge it but do not publish a new version?

The latter, maybe the cutoff point will be the next PR.

I see. Sure! (If I remember ;) )

@fzyzcjy Should be good to merge.


Support functions with string inputs in 2.2.0, fixes #10459

It turns out the utility function is already in TF: you can use dtypes_module.as_dtype(tensor.dtype).as_numpy_dtype (a property of the DType class).

Thanks François, I did not know about this as_numpy_type property. I removed the _numpy_dtype() method and used as_numpy_dtype instead.
Just out of curiosity, why do you recommend tf.as_dtype(tensor.dtype).as_numpy_dtype rather than simply tensor.dtype.as_numpy_dtype? Can tensor.dtype sometimes be anything else than a DType object? Perhaps it's best to err on the safe side.

Can tensor.dtype sometimes be anything else than a DType object? Is it just to err on the safe side?

You're probably right. But better to avoid surprises...


refactor: add "types" to package.json

TypeScript can't pick up the type definitions if they aren't in a "files" or "types" field

This should be merged ASAP :) can the maintainers approve this MR?


[Feature] Update translation file for esperanto

Describe the changes you have made in this PR
A clear and concise description of what you want to happen
I have added translation to the missing keys in the esperanto language.
Link this PR to an issue [optional]
Fixes https://github.com/getAlby/lightning-browser-extension/issues/2344
Type of change
(Remove other not matching type)

feat:  Update translation file for esperanto (non-breaking change which adds functionality)

Screenshots of the changes [optional]

How has this been tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist

[x] My code follows the style guidelines of this project and performed a self-review of my own code
[x] New and existing tests pass locally with my changes
[x] I checked if I need to make corresponding changes to the documentation (and made those changes if needed)

No, I didnt know about that . Thanks for the info 🤝🏻.

Is this in sync with weblate? did we add it to weblate or shall we merge these updates?


[asyncio] ERROR: Task was destroyed but it is pending!

Running the following MRE scraper I intermittently get the error from the title part way through the URLs being processed:
import logging

from scrapy import Request, Spider
from scrapy.crawler import CrawlerProcess

class FlashscoreSpider(Spider):
    name = "flashscore"
    custom_settings = {
        "DOWNLOAD_HANDLERS": {
            "http": "scrapy_playwright.handler.ScrapyPlaywrightDownloadHandler",
            "https": "scrapy_playwright.handler.ScrapyPlaywrightDownloadHandler",
        },
        "TWISTED_REACTOR": "twisted.internet.asyncioreactor.AsyncioSelectorReactor",
        "REQUEST_FINGERPRINTER_IMPLEMENTATION": "2.7",
        "LOG_LEVEL": logging.ERROR,
    }

    start_urls = [
        "https://www.flashscore.com/match/WKM03Vff/#/match-summary/match-summary",
        "https://www.flashscore.com/match/6go7eBHA/#/match-summary/match-summary",
        "https://www.flashscore.com/match/W0rJh91T/#/match-summary/match-summary",
        "https://www.flashscore.com/match/4lDXBW1i/#/match-summary/match-summary",
        "https://www.flashscore.com/match/v75p9UoA/#/match-summary/match-summary",
        "https://www.flashscore.com/match/4EjNNOJF/#/match-summary/match-summary",
        "https://www.flashscore.com/match/rT3yPgsm/#/match-summary/match-summary",
        "https://www.flashscore.com/match/hbHHSeqM/#/match-summary/match-summary",
        "https://www.flashscore.com/match/pjiBe6zN/#/match-summary/match-summary",
        "https://www.flashscore.com/match/KOs4lXMu/#/match-summary/match-summary",
        "https://www.flashscore.com/match/UswTO2Nc/#/match-summary/match-summary",
        "https://www.flashscore.com/match/OtjFfQkT/#/match-summary/match-summary",
    ]

    def start_requests(self):
        for url in self.start_urls:
            yield Request(
                url=url,
                meta=dict(dont_redirect=True, playwright=True),
                callback=self.parse,
            )

    def parse(self, response):
        print(f"Parsing {response.url}")

if __name__ == "__main__":
    process = CrawlerProcess()
    process.crawl(FlashscoreSpider)
    process.start()

Doesn't happen every time but when it does it usually repeats. Here's the terminal output:
Parsing https://www.flashscore.com/match/4EjNNOJF/#/match-summary/match-summary
Parsing https://www.flashscore.com/match/6go7eBHA/#/match-summary/match-summary
Parsing https://www.flashscore.com/match/v75p9UoA/#/match-summary/match-summary
Parsing https://www.flashscore.com/match/4lDXBW1i/#/match-summary/match-summary
Parsing https://www.flashscore.com/match/W0rJh91T/#/match-summary/match-summary
Parsing https://www.flashscore.com/match/hbHHSeqM/#/match-summary/match-summary
Parsing https://www.flashscore.com/match/rT3yPgsm/#/match-summary/match-summary
Parsing https://www.flashscore.com/match/WKM03Vff/#/match-summary/match-summary
Parsing https://www.flashscore.com/match/KOs4lXMu/#/match-summary/match-summary
Parsing https://www.flashscore.com/match/UswTO2Nc/#/match-summary/match-summary
Parsing https://www.flashscore.com/match/OtjFfQkT/#/match-summary/match-summary
Parsing https://www.flashscore.com/match/pjiBe6zN/#/match-summary/match-summary
2023-09-12 00:09:20 [asyncio] ERROR: Task was destroyed but it is pending!
task: <Task pending name='Task-4858' coro=<ScrapyPlaywrightDownloadHandler._make_request_handler.<locals>._request_handler() running at /Users/<me>/opt/miniconda3/envs/capra_production/lib/python3.10/site-packages/scrapy_playwright/handler.py:529> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[gather.<locals>._done_callback() at /Users/<me>/opt/miniconda3/envs/capra_production/lib/python3.10/asyncio/tasks.py:720]>
2023-09-12 00:09:20 [asyncio] ERROR: Task was destroyed but it is pending!
task: <Task pending name='Task-4857' coro=<Page._on_route() running at /Users/<me>/opt/miniconda3/envs/capra_production/lib/python3.10/site-packages/playwright/_impl/_page.py:249> wait_for=<_GatheringFuture pending cb=[Task.task_wakeup()]> cb=[AsyncIOEventEmitter._emit_run.<locals>.callback() at /Users/<me>/opt/miniconda3/envs/capra_production/lib/python3.10/site-packages/pyee/asyncio.py:65]>

In running a longer sequence of URLs the errors appear intermittently and usually in blocks of quite a few together.
It doesn't affect further processing though - when I create items they flow into pipelines and are successfully processed there despite there being errors all over the place.
Am I doing something wrong here?
python: 3.10.8
scrapy: 2.8.0
scrapy-playwright: 0.0.32
MacOS: 13.5.1

Indeed, I can reproduce. This was already reported at #188 but it was lacking a reproducible example, let's continue the discussion at #188.


Proofread section on why to use Git

@doabell  Can you proofread and suggest any important revisions to the provocation chapter section on why to use Git?
Also, in case people do run into situations where they have to manage merge conflicts, can you suggest a good reference or tutorial on doing that?

I added this in the Provocation bullet points:

conflicts

Command line: Happy Git with R
GitHub Desktop will tell you to open your editor, e.g. Merge conflicts in VS Code
Other Git GUIs may have built-in resolution strategies.


Helidon DBClient does not trigger an Exception when no sane DB connection can be obtained , post application initialization

In case the database server was up during the application initialization and for some reason the server went down ,and then when the application tries to insert a row , we expect a DBClientException to be thrown after the connection timeout , which does not seem to happen .
Environment Details

Helidon Version: 2.5.1
Helidon SE
JDK version: java 17
OS: Oracle Linux 7
Docker version (if applicable): NA

Problem Description
We are using DBClient in our Helidon SE project with the below configurations
url: jdbc:mysql://<IP_ADDRESS>:3306/dbName?failOverReadOnly=false&characterEncoding=utf-8&useSSL=false&allowPublicKeyRetrieval=true
username: root
password: passwd
poolName: mysql
initializationFailTimeout: -1
connectionTimeout: 2000
So if the MySql server is up and running , we see no issues as such . But in case the database server was up during the application initialization and for some reason the server went down ,and then when the application tries to insert a row , we expect a DBClientException to be thrown after the connection timeout of 2000 ms , which does not seem to happen .
Snippet of the thread dump of the helidon application
"helidon-jdbc-dbclient-thread-pool-5" #23 daemon prio=5 os_prio=0 cpu=0.74ms elapsed=1453.67s tid=0x00007f90ecd635b0 nid=0x32c2 waiting on condition  [0x00007f90b58f7000]
java.lang.Thread.State: TIMED_WAITING (parking)
at<EMAIL_ADDRESS>Method)
- parking to wait for  <0x00000007198b57c0> (a java.util.concurrent.SynchronousQueue$TransferQueue)
at java.util.concurrent.locks.LockSupport.parkNanos(java.base@17.0.2/LockSupport.java:252)
at java.util.concurrent.SynchronousQueue$TransferQueue.transfer(java.base@17.0.2/SynchronousQueue.java:704)
at java.util.concurrent.SynchronousQueue.poll(java.base@17.0.2/SynchronousQueue.java:903)
at com.zaxxer.hikari.util.ConcurrentBag.borrow(ConcurrentBag.java:151)
at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:164)
at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:146)
at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:100)
at io.helidon.dbclient.jdbc.HikariConnectionPool.connection(HikariConnectionPool.java:53)
at io.helidon.dbclient.jdbc.JdbcDbClient$JdbcExecute$$Lambda$647/0x0000000800e9f790.get(Unknown Source)
7:48
"mysql connection adder" #59 daemon prio=5 os_prio=0 cpu=639.77ms elapsed=1127.21s tid=0x0000556c94ef3f50 nid=0x3f02 waiting on condition  [0x00007f908b4fb000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at<EMAIL_ADDRESS>Method)
at com.zaxxer.hikari.util.UtilityElf.quietlySleep(UtilityElf.java:53)
at com.zaxxer.hikari.pool.HikariPool$PoolEntryCreator.call(HikariPool.java:745)
at com.zaxxer.hikari.pool.HikariPool$PoolEntryCreator.call(HikariPool.java:712)
at java.util.concurrent.FutureTask.run(java.base@17.0.2/FutureTask.java:264)
at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@17.0.2/ThreadPoolExecutor.java:1136)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@17.0.2/ThreadPoolExecutor.java:635)
at java.lang.Thread.run(java.base@17.0.2/Thread.java:833)
Steps to reproduce
[//]: 1 Database server must be up and running when the application starts . Bring down or make the db server non-reachable .
[//]: 2 Make your helidon application to do some operation on the table (insert) and then you will observe that the operation "execute" just hangs .
dbClient
.execute(
exec ->
exec.createNamedInsert("insert")
.indexedParam(entity )
.execute())
.thenApply(e -> entity )
.exceptionally(throwable -> {
logger.atWarning().log( "Failed to insert : %s", throwable);
return null;
});

Update from customer:
createNamedGet is throwing a DBClient Exception whereas other apis like createNamedInsert / update and delete are not .

Hi Helidon Experts, Thanks for clarification on impact. We would like to have this fix/patch in Helidon 2.5.1/2.52. Is there an ETA on this story? Currently we are blocking our story until a fix/workaround is provided, does this sound reasonable?
Thanks
Chandra

namedDml api as well has the same issue . It does not seem to throw a DBClientException if a query (in our case it was create table) is executed when the DB server is unavailable .

Tested similar scenario with my old Pokemon example.
Running curl -i -X POST -d '{"id":8,"name":"Raticate","idType":2}' http://localhost:8079/db/pokemon caused some warnings to be logged:
2022.08.23 13:45:21 WARNING com.zaxxer.hikari.pool.PoolBase Thread[helidon-jdbc-dbclient-thread-pool-4,5,jdbc-dbclient-thread-pool]: mysql - Failed to validate connection com.mysql.cj.jdbc.ConnectionImpl@4b83f76 (No operations allowed after connection closed.). Possibly consider using a shorter maxLifetime value.
2022.08.23 13:45:21 WARNING com.zaxxer.hikari.pool.PoolBase Thread[helidon-jdbc-dbclient-thread-pool-4,5,jdbc-dbclient-thread-pool]: mysql - Failed to validate connection com.mysql.cj.jdbc.ConnectionImpl@372ace49 (No operations allowed after connection closed.). Possibly consider using a shorter maxLifetime value.

But example insert code
        dbClient.execute(exec -> exec
                .createNamedInsert("insert-pokemon")
                .indexedParam(pokemon)
                .execute())
                .thenAccept(count -> response.send("Inserted: " + count + " values\n"))
                .exceptionally(throwable -> sendError(throwable, response));

hangs as described in the bug.

Looks like some executorService().submit(...)  calls are eating exceptions in JdbcStatementDml and JdbcStatementQuery. :)

@msteffi PR https://github.com/oracle/helidon/pull/4772 should fix this for 2.x. You can verify it using https://github.com/Tomas-Kraus/helidon/tree/issue-4719-2.x branch build if you would like to.


Move to Acosix namespace and rebase onto Acosix Maven setup

This project should be moved inside the Acosix organisation on GitHub and its project structure as well as build should be fully based on the Acosix Maven setup. License should also be changed to the Apache license. Moving into Acosix organisation also allows for publication of the addon to Maven Central using the established namespace.

Move complete


Memgraph high-availabilty chart

Future ideas:

maybe we can group coordinators in one namespace and data instances in the second namespace
put ResourceQuota on each namespace
label for each version of the software, newer versions shouldn't be distinguished by namespace

Notes:

Passing arguments now work
we probably need multiple stateful sets in a cluster (hence, we cannot depend on our original chart)
The partial failure of the initial setup of replicas and coordinator should not cause another failure later.
The replication ports also need to be open across the board.

TODO:

[x] Create stateful sets for coordinators and data instances
[x] Fix args passing to work
[x] Connect Memgraphs instances into cluster
[x] Handle services
[x] Support envs for enterprise
[x] Handle services to the cluster
[x] Handle configs
[x] Handle versions
[x] Handle READMES
[x] Handle volumes
[x] Handle running as root
[x] StartupProbe, LivenessProbe, ReadynessProbe
[x] Write basic test Related:
[x] Handle tests, related: https://github.com/memgraph/helm-charts/issues/21

Later:

[ ] Add support for envs

It is expected for CI/CD to fail, since Memgraph 2.17.0 is still not released.


Bump django 2.1

This was completely painless.  Suggest we let 2.0 bed in for a couple of days before merging early next week.


support ordered instance type preference

Tell us about your request
have a provisioner that uses instances as they are ordered in the types list
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
we want to run our clusters with m6i.16xl nodes, but we want to allow fallback to 12xl,8xl etc
when pending pods are found karpenter will spin up the smallest possible node (8xl) and do that over-and-over until we have lots of 8xl nodes
(at this point we need consolidation to get 16xl nodes, but that causes pods to get deleted which is not ideal)
so a "ordered" provisioner would be nice that picks the first available instance type from the list
Are you currently working around this issue?
use multiple provisioners with descending weights (1 per type)
which is ugly to manage and I assume inefficient inside of karpenter since it needs to consider so many provisioners
Additional Context
No response
Attachments
No response
Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

We have several provisioners and consolidation works fine.
One is a limited family provisioner with a second one being a bigger pool of hw.

so you enable consolidation on each of the provisioners or just the "big pool" ?

On both provisioners

awesome, then I'll just try that and see if it works 🎉

let me reopen this ...
so if this works we are still looking at 12 different provisioners 🤦
(we use 6 instance types -> 6 for capacity reservation and 6 for regular instances) that seems not fun ...

Can you explain the logic behind your instance type preference? You may find that the cluster autoscaler is a better fit for this use case.

yeah, we are trying to move from CA to karpenter :D
the preference is instance family (m6 over m5, since we see performance gains)
and size 16 over 8 (since we see reduced overhead from daemonsets and packing of pods)

I'd typically let Karpenter binpack for you, rather than preferring 16 over 8. Regarding generation, I'd use provisioner weights to preference generation 6 over generation 5. Check out https://karpenter.sh/v0.19.2/tasks/scheduling/#weighting-provisioners and https://karpenter.sh/v0.19.2/tasks/scheduling/#supported-labels

yeah I looked at weights, downside would be that I have to duplicate provisioners.
I know karpenter can binpack via consolidation but for simplicity and to lower disruption I'd like to "always get 16xls", it will also be a smoother transition from cluster-autoscaler to have 1 less thing that changes.

Given that it's all yaml, you can template it, so you may end up with fewer actual full blown provisioner blocks.
Just depends on what you are using to deploy them.

Yeah I know that can work, the issue comes from "not wanting so many provisioners" in general and "setting max resources" (and maybe in the future min resources and disable which are 2 other issues we are hoping to get solved)

I believe the team is working to make some global values, which could include max resources for all provisioners

I'd much prefer global limits and trying to architect Karpenter to be more similar to CAS. I don't see a viable path to what you're suggesting without completely breaking how Karpenter thinks about instance type flexibility.

I was thinking that when deciding what type to pick it would have a flag to say "use the order from the requirements".

I have a use case that probably will be fixed with this feature:
I have 1 container/deployment that fits on t3.small (less than 1 core and low ram usage)
When horizontal pod autoscaler kicks in...
Karpenter calculates the best fit for the new containers and fails because...
Karpenter doesn't know that lots of small instances are cheaper than a few big instances.
right now I am having c5a.large and t3.medium instances in my cluster when everything could fit in t3.small
If I restrict the instance types on the provisioner it totally works but the documentation states that I need to provide more than 30 instance types to be a good list and I feel that leaving the default list is less risky than trying to be smart.
BTW I am using SPOT instances.
summarizing,
everything could fit in t3.small but karpenter didn't try to do the cheapest fit.

@mercuriete i would create two provisioners.
one with just t3.small with lower weight and another with larger number of families.
that way, Karpenter will try first the lower weight provisioner and if no instance of that type is available, tries the next one

@FernandoMiguel
Thanks.
It is really a good idea and it fits perfectly my use case.
I will implement it.

I still want this feature, because otherwise we have to manage 6+ providers for every nodegroup 😞
(we want to have m6i.16xl,12xl,8xl,... but not karpenter boot any of the smaller instances unless aws is out off capacity)

You should be able to share the same AWSNodeTemplate across multiple provisioners.
We have a preference mechanism implemented today. It leverages a single provisioner for AND rules, and multiple provisioners for (weighted) OR rules. Changing this to a single provisioner has significant architectural complexities (i.e., impact to how weights work today), and I don't see the value in trying to collapse multiple yamls into a single yaml to achieve the same use case. Open to hearing more about why I'm wrong on this, as well as a concrete idea of what an alternative would look like.

Yeah don't think you are wrong there, I imagine it's not easy.
I'm mostly hoping there is a way that I don't have to deal with so many provisioners.
The only alternative I can think of is making the instance type list special (maybe generic so any field could be "sort by this".

that would not work, not sure how that question is related though
I'm suggesting a single provider with:
  requirements:
  - key: karpenter.sh/capacity-type
    operator: In
    values: ["on-demand"]
  - key: "node.kubernetes.io/instance-type"
    operator: In
    values: ["m6i.16xlarge", "m6i.12xlarge", "m6i.8xlarge"]
  instanceTypeSortOrder: "node.kubernetes.io/instance-type"

or something like that

The problem is that we'd now need to revert to passing a single instance type to EC2, or use a fundamentally different pricing strategy. Neither of these fit well with karpenter's architectural assumptions, which are oriented around flexibility and instance type price analysis. Consider how this would work for Spot -- we would request instance types one at a time, and completely negate the pool depth analysis provided by the PriceCapacityOptimized algorithm of fleet.
If you need this specific use case, the Cluster Autoscaler's architecture is a better fit for the use case. However, I'd really question the assumptions of what you're trying to achieve via prioritization. Why do need this prioritization at all? Why is karpenter's built in binpacking failing to achieve the capacity results you're looking for?

yeah part of this is trying to stay close to CA so we can move to karpenter with minimal changes and then experiment once we are there

we are trying to have even instance types since we know they are cost-effective (especially m6i vs m5)
our daemonsts are tuned for the 16xl size (making them dynamic would be an option though, but more work)
we don't want pods to be shuffled around (so ideally boot 16xl and then it just stays on there)
for spot we'd most likely not want the prioritization since the depth is great good feature

Given that it's just a point in time problem for experimentation of a migration from another tool, id recommend just using weighted provisioners.

yeah that's my plan ... we'll see how much trouble that is
was mostly hoping it would be an easy fix to add


Fix/Add postman missing translations

Description
Additional translations :

pm.response.json()
pm.expect()

Contribution Checklist:

[x] The pull request only addresses one issue or adds one feature.
[x] The pull request does not introduce any breaking changes
[x] I have added screenshots or gifs to help explain the change if applicable.
[x] I have read the contribution guidelines.
[ ] Create an issue and link to the pull request.

Publishing to New Package Managers
Please see here for more information.

Translations for pm.body.json and pm.expect is available in the latest version of Bruno.
Closing this PR.


Align problem on RN 0.37.0

The button text on Android is align on the top left, i think the cause is the Text element that wrap the other Text children.

Android has this problem.

Thanks for reporting!
Can you attach me an screenshot?
Will try to solve this ASAP :)

@alvaromb

Solved in https://github.com/APSL/react-native-button/releases/tag/v3.0.2
Thanks.


Drop support for end-of-life Ruby versions + update dependencies.

Drop support for Ruby 2.7 and 3.0 per our version policy.
Update (theoretically) vulnerable npm packages (npm audit fix).
Update rubygems dependencies as far as compatible.
Update GitHub Actions dependencies.
Declare some missing transitive dependencies for forward compatibility with Ruby 3.4.

Someone with repo admin (or alphagov org admin) will need to update the repo's branch protection rules to fix the list of required checks.

I've removed the requirement for tests on ruby 2.7
will try to do a review in the next day or two (probably by just including the gem in another thing and making sure it works)

I have tested against a local tech docs site using ruby 3.2.3. Everything seems to function correctly.

Thanks @heathd!


chore: temporarily disable struct accessor tests

This is to unblock PRs until the real issue is identified and fixed in b/362738764.
Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

[ ] Make sure to open an issue as a bug/issue before writing your code!  That way we can discuss the change, evaluate designs, and agree on the general idea
[ ] Ensure the tests and linter pass
[ ] Code coverage does not decrease (if any source code was changed)
[ ] Appropriate docs were updated (if necessary)

Fixes #<issue_number_goes_here> 🦕

Closing in favor of https://github.com/googleapis/python-bigquery-dataframes/pull/953#pullrequestreview-2280586198


Troubleshooting intermittent 503 errors

We are using WebListener version 1.1.4. We have an issue where approximately 1% of requests return a 503 error. We see these 503 errors in our GTM logs. I can't find anything in our application logs where requests have high latency that could result in timeouts. So I want to see if WebListener got these requests and what it responded with.

I see the following logs. I assume these are from .NET core itself, and not necessarily from WebListener. If so, how do I enable WebListener logs?

Microsoft.AspNetCore.Hosting.Internal.WebHost: Information: Request finished in 370.1088ms 200 application/json; charset=utf-8

We are using the default values for MaxAccepts and RequestQueueLimit. The intermittent 503 errors occur even during low traffic periods when CPU is under 20%, so I assume it can't be caused by these default values.

A lot of online searches for 503 errors point at Application Pool configurations when using IIS. Does WebListener have a similar concept of Application Pools that might need configuring?
https://weblog.west-wind.com/posts/2006/Dec/04/503-Service-Unavailable-in-IIS-7-watch-those-Application-Pools

Is there a way to enable something similar to "Failed Request Tracing" in Web Listener?
https://blogs.iis.net/richma/502-3-bad-gateway-the-operation-timed-out-with-iis-application-request-routing-arr

Any other thoughts or suggestions or greatly appreciated :)

Start here for traces:
https://blogs.msdn.microsoft.com/wndp/2007/01/18/event-tracing-in-http-sys-part-1-capturing-a-trace/
Http.Sys does have a request queue and it will send 503s if the queue gets full. The RequestQueueLimit option was added in a later version that would let you adjust the length. If the logs indicate your queue is full then consider updating and setting this.

I'm not familiar with those low level logs or error codes. I wonder if the client already disconnected in this case.
They're slightly easier to search if you convert them to hex (0xC000020D), but I still didn't get any hits. Have you been able to capture a matching wireshark trace?

@chandimar001 are you still having issues?
One hypothesis is that your HTTP.sys queues are filling up. Can you verify via perf counter?


Avoiding the need for vibrate permission

The library can call performHapticFeedback() on the TextView to cause vibration. That does not require permissions, and it follows the preferences for vibration that the user set in the device settings

Done and done. Thanks for the tip


Calling commands "Add, Delete" without "Fish" are still valid commands

This also causes issues with the fish counter for each tank


Doesn't work with TS 5.2. No errors shown at all.

The plugin works fine with TS 5.1.6, but upgrading to 5.2.2 with the plugin enabled, completely turns off any TS errors in the IDE (not only strict mode errors - all others as well). This happens both in VSCode and Webstorm.
Dropping to 5.1.6 makes the plugin work again, and removing the plugin makes 5.2.2 show "normal" (non-strict) errors in the IDE.

I've managed to dig this up from IDE's logs:
#c.i.l.j.s.JSLanguageServiceQueue - Service internal error: Error processing request. Cannot read properties of undefined (reading 'getSyntacticDiagnostics')
TypeError: Cannot read properties of undefined (reading 'getSyntacticDiagnostics')

Could be useful for debugging this.
@KostkaBrukowa If you have some rough idea of what might be causing this and could point me in a right direction, I'd be happy to contribute.

Hey! Sorry for delay. @kamkry actually found the culprit: here and here should be
info.project['compilerOptions'].strict = true;

so the API changed in TS 5.2.2

Hi @zorzysty! We released the fix in the latest beta, could you check if it's working correctly now?
npm i<EMAIL_ADDRESS>

@kamkry It's definitely better, but something is still a bit off. Now I see strict mode errors when I open and edit a file, but they disappear when I restart TS Language server or change anything in tsconfig.json. To get them back, I need to reopen the file. This is not happening with 5.1.6 and the previous version of the plugin.

@zorzysty We tried to quickly find the problem but we need more time. It's good to hear the fix helped you, I opened the pull request and we'll try to release it as soon as it's possible, thank you for creating the issue 😄


Error: no WebRTC support

When running rushx test:node in fula-client I get this:
...
TAP version 13
# Setup
TAP version 13
not ok 1 Error: no WebRTC support
  ---
    operator: error
    stack: |-
      Error: no WebRTC support
...

The test:web script runs and has no problem with wrtc

createClient requires a wrtc option when running in Node


Can I separate nmap scan and Nmap2CVE-Search task into two hosts?

I want to install a very light client at the target machine and handoff other tasks as much as I can to another server. I am just wondering can I first nmap scan the target machine and then send its report to another server? On the other server I then run Nmap2CVE-Search.py to obtain the vulnerability report of the initial target VM? Or Nmap2CVE-Search.py must be run within the target machine?
Thanks,

Yes. Please check the Usage part of the README.md file. If you can transfer the .xml file from machine A to machine B, this works


Shuttle Does not Retain Added Stops

ITS-Pro time category: https://its-pro.ucsd.edu/projects/MA/issues/MA-34?filter=allopenissues
This is complete when:

[ ] The added shuttle stops remain after an app relaunch

To reproduce on 7.2.13 production build:

Tap on Manage Shuttle Stops
Add a stop
Confirm stop is added on the Home view
Completely close out the app
Launch the app
Home view does not show the added shuttle stop
Manage Shuttle Stops view does not show the added stop

PR #1096 has failed regression testing for some users. The issue of hard reset erasing added stops persists on Android and iOS.


Fix link to OpenSavvy Prepared

Sorry, I moved Prepared to a subgroup of OpenSavvy, and I broke the links :/
I'm planning to do the same change for Pedestal, I'll try to remember to update your links too, sorry for that :/
Thanks a lot for featuring my projects though <3

Thank you! And no problem about breaking links.


Not working in any manner

I have tried to install this locally and on the server as well but on both of the instances, it always shows 403 forbidden.
both local and live server has Laravel 8.59.0 installed

try to access to the login page with shopper\login

Thanks,
That does works but you should update that in documentation or redirect the /shopper to log in directly as the document is misleading for the URL to check for the after setup is completed.

shopper\login  after login, 403 UNAUTHORIZED error any solution? cleared cache but 403


fix: Disable save button when can_add: false, can_overwrite: false

fix #8302 (except the hotkey part)
I put off fixing the hotkey copy because it isn't quite accurate anyways, so I'm not sure what it should say. For instance, you can't ctrl-s to save on a slice unless it exists and you have overwrite permissions, and on a mac ctrl-r doesn't work anyhow.
CATEGORY

[X] Bug Fix
[ ] Enhancement (new features, refinement)
[ ] Refactor
[ ] Add tests
[ ] Build / Development Environment
[ ] Documentation

SUMMARY
Disable chart save button when can_add: false, can_overwrite: false
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
before:
after:
TEST PLAN
Configure a role such that it can view a chart but not edit/save it, then view a chart with that user.
ADDITIONAL INFORMATION

[X] Has associated issue: #8302
[X] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

REVIEWERS
@willbarrett maybe?

This looks reasonable to me. @nytai @rusackas does it look reasonable to you?

Codecov Report

Merging #9456 into master will decrease coverage by 11.96%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           master    #9456       +/-   ##
===========================================
- Coverage   71.35%   59.39%   -11.97%
===========================================
  Files         585      401      -184
  Lines       30913    12762    -18151
  Branches     3246     3247        +1
===========================================
- Hits        22059     7580    -14479
+ Misses       8744     5003     -3741
- Partials      110      179       +69

Flag
Coverage Δ

#cypress
?

#javascript
59.39% <100.00%> (+<0.01%)
:arrow_up:

#python
?

Impacted Files
Coverage Δ

...ontend/src/explore/components/QueryAndSaveBtns.jsx
70.00% <ø> (-20.00%)
:arrow_down:

...nd/src/explore/components/ExploreViewContainer.jsx
46.85% <100.00%> (-30.62%)
:arrow_down:

superset-frontend/src/SqlLab/App.jsx
0.00% <0.00%> (-100.00%)
:arrow_down:

superset-frontend/src/explore/App.jsx
0.00% <0.00%> (-100.00%)
:arrow_down:

superset-frontend/src/SqlLab/index.jsx
0.00% <0.00%> (-100.00%)
:arrow_down:

superset-frontend/src/dashboard/App.jsx
0.00% <0.00%> (-100.00%)
:arrow_down:

superset-frontend/src/explore/index.jsx
0.00% <0.00%> (-100.00%)
:arrow_down:

superset-frontend/src/dashboard/index.jsx
0.00% <0.00%> (-100.00%)
:arrow_down:

superset-frontend/src/setup/setupColors.js
0.00% <0.00%> (-100.00%)
:arrow_down:

superset-frontend/src/chart/ChartContainer.jsx
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 324 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 38a6bd7...cf515f8. Read the comment docs.

@villebro could you look this when you get the chance? It basically boils down to:
<QueryAndSaveBtns
-  canAdd="True"
+  canAdd={!!(this.props.can_add || this.props.can_overwrite)}


Blip Replicate Interface Is Down

Blip Replicate interface is down right now.
Source

It's up and running right now, thank you!

It's up and running right now, thank you!


[IDEA] Excerpt images

dynannotate-improvements will be merged into the master branch  when releasing tiddlywiki v5.2.3.
https://github.com/TWPUB/TWPUB-Tools/issues/15


OBST-454: Suppress s2i launch for SSO booster

Please hold this for now

Once merged, I will provide a copycat for Vert.x.

@cescoffier slacker 😆

same for node :)

@quintesse Heiko is on PTO until Thursday, and said he was all set with this pending the support in the launcher.  Please go ahead and merge this.

Ok, will do @balunasj !


add incident and maintenance endpoints

For https://github.com/muxinc/engbot/pull/34

@gtabrar do you need any help? The linked pull request is not visible to me (maybe private?).

Hey @nagelflorian - apologies I meant to push this to a fork. I'm extending the package to include some endpoints not currently covered, such as incidents. I hope to have a PR for you to include this soon 😄


Use travis stages to test different vertx versions

@jpkrohling @objectiser could you please review? I am not sure if we need this, but when I was writing this  integration I saw some differences in different versions of vertx-web.

@jpkrohling @objectiser Do you prefer this one or #6 ? This is using stages. It has slightly cleaner config but it's more verbose.

@pavolloffay I think I prefer this one, as it potentially allows other options to be provided with future variations.

This one.

I will merge this. @jpkrohling thanks for matrix :P


Publications project in Spanish

https://training-datalab.com/projects/political-science-publications.html

Upload.