Setting "return immediately" flag

Here's an interesting feedback from a customer:
http://stackoverflow.com/questions/38628150/gcloud-java-pubsub-api-how-to-set-return-immediately-flag
@mziccard @garrettjonesgoogle
Marco, what are your thoughts? And can you elaborate in this issue where this shows up in the code? It seems like this might cause some unnecessary polling.

Hi Omar!
The answer to that question is not entirely true. When MessageConsumer is used (see MessageConsumer pullAsync(String subscription, MessageProcessor callback, PullOption... options); returnImmediately is set to false (see here). MessageConsumer in fact does the continued pulling on behalf of the user, and handles possible timeout-related exceptions that might occur when using returnImmediately=false.
For what concerns other pull methods:

Iterator<ReceivedMessage> pull(String subscription, int maxMessages)
Future<Iterator<ReceivedMessage>> pullAsync(String subscription, int maxMessages)

The use of returnImmediately was discussed here. A returnImmediately option could be added to both methods, I am just not sure how much this is needed or might lead to unexpected behavior (e.g. with returnImmediately=false the synchronous method might hang until timeout). /cc @aozarov

I think the problem with returnImmediately=false, which could potentially block forever if no new messages are sent, is that the notion of "The client may cancel the request if it does not wish to wait any longer for the response." (as described here) is vague.
How do we do that? Seems like a challenge for synchronous calls.
Could probably be added for asynchronous calls and use the Future#cancel, hoping that the propagated cancel to the generated spi layer would do the right thing and cancel the underlying RPC call. This was left out for simplicity and and consistency with the synchronous call. It should be fairly simple to create an Iterator from MessageProcessor if desired (and maybe we can provide a utility for it) however I don't strongly object breaking the symmetry with the synchronous call in this case.

The original stackoverflow question was from me.
I would like to confirm that with our use cases, where we are replacing incumbent tech, we do need to be able to setReturnImmediately to false even for the synchronous pull. So I am very much interested in having this feature implemented. Once done I will be able to plan moving away from the existing REST API.

Hi @evmin! We are progressing on this, in fact I hope we will be able to release something by the end of next week.

we do need to be able to setReturnImmediately to false even for the synchronous pull.

We are considering making returnImmediately=false the default behavior of our:
Future<Iterator<ReceivedMessage>> pullAsync(String subscription, int maxMessages)

that way you can obtain the sync behavior you are seeking by doing:
Future<Iterator<ReceivedMessage>> future = pubsub.pullAsync("mysubscripton", 1000);
Iterator<ReceivedMessage> messageIterator = future.get():

How does this sound? The reason we don't want to add the returnImmediately option to the synchronous version pull(String subscription, int maxMessages) is that this request can hang indefinitely with no way for the user to terminate it. On the other hand, with the Future<Iterator<ReceivedMessage>> pullAsync(String subscription, int maxMessages) method you can still terminate the request by calling cance() on the future.
We would love to hear your thoughts!

From my perspective there are four considerations here.

Flexibility. With not providing an option to configure returnImmediately for synchronous pull the decision is effectively made for the developer, for the future needs. I would err here on the side of flexibility. I would make it available and let the devs decide down the line what fits their model. Make it a non default option, make it timeout, make timeout configurable, but provide the option.

The case I am working on accepts the fact that a thread might never return. It is a framework where polling is part of built in mechanism. The idea is that if it never returns, than there is no message. Valid use case as executor pools are dedicated.

Current implementation does have a synchronous pull. Regardless of the development of this library it looks like the time pressure will make us to go with the currently available Services version. Retrofitting synchronous pull to async is probably not a good idea if my understanding that  pullAsync creates yet another thread on execution is correct. Is this a case? Would the thread be created on each poll? If this is the case, creating a thread from within yet another dedicated executor pool seems to be counterproductive, and the framework we are using expects to manage the threads itself.

Python version does provide synchronous Pull. Would be a good idea to maintain parity and consistency, so cross platform implementations (such as ours) would be coding to the same standard.

Having said all this, I think that future.get() is still a good option to include.
This is my thinking at the moment. Do I miss something here that invalidates the train of thought?

@evmin Let me answer, but in a different order :)

Retrofitting synchronous pull to async is probably not a good idea if my understanding that pullAsync creates yet another thread on execution is correct. Is this a case?

No this is not the case. gRPC is inherently async, we have a channel associated to an executor which runs the async IO. Roughly speaking, gRPC responses are received via async callbacks, our async methods just convert results and do not start any thread other than the ones that are natively used by gRPC. This is important, our sync methods are just syntactic sugar on top of the async:
public Iterator<ReceivedMessage> pull(String subscription, int maxMessages) {
  try {
    return Uninterruptibles.getUninterruptibly(pullAsync(subscription, maxMessages));
  } catch (ExecutionException ex) {
    throw Throwables.propagate(ex.getCause());
  }
}

The case I am working on accepts the fact that a thread might never return. It is a framework where polling is part of built in mechanism. The idea is that if it never returns, than there is no message. Valid use case as executor pools are dedicated.

I know very little of your architecture but I believe that polling via user threads + sync methods is not the best option to reach maximum throughput when using the gRPC transport. I would consider instantiating multiple PubSub service objects (each one uses a separate channel) and giving them enough "executing power" (depending on your application needs) via PubSubOptions.Builder.setExecutorFactory() (by default we use an 8 thread executor, shared across all channels/service instances). Knowing very little, these are just random thoughts, thought.

Flexibility. With not providing an option to configure returnImmediately for synchronous pull the decision is effectively made for the developer, for the future needs.

I see your point on flexibility. However, if pullAsync uses returnImmediately=false by default, you can achieve your desired sync method with pullAsync("mysubscription", 1000).get() (at not extra cost, as I explained above).

Python version does provide synchronous Pull. Would be a good idea to maintain parity and consistency, so cross platform implementations (such as ours) would be coding to the same standard.

AFAIK Python does provide only synchronous pull at the moment (please correct me if I am wrong). So they have to provide all the available options to the sync method.
@aozarov In this comment we have some more user thoughts in favor of adding returnImmediately option to all pull methods. I would like to hear your thoughts on this!

That's a very, long, detailed and comprehensive description - I am truly appreciative of your effort. Thank you!
If no extra threads are created, then .get() is indeed workable solution. Great.
Though I am a bit confused here.
If I check https://github.com/GoogleCloudPlatform/google-cloud-java/blob/master/google-cloud-pubsub/src/main/java/com/google/cloud/pubsub/MessageConsumerImpl.java#L159
I see
private final ExecutorService executor = Executors.newSingleThreadExecutor();
If we check newSingleThreadExecutor, I can see
    public static ExecutorService More ...newSingleThreadExecutor() {         return new FinalizableDelegatedExecutorService             (new ThreadPoolExecutor(1, 1,                                     0L, TimeUnit.MILLISECONDS,                                     new LinkedBlockingQueue<Runnable>()));     }
And that's where it is probably too deep for me - I was not able to find confirmation if the Single Thread Executor does create a new thread or not. It looks like it does, doesn't it?
Apologies for the potentially ignorant question, I might be missing something, just being paranoid.
P.S. You are correct on the performance compromise. It is the penalty for adapting one framework for another - the benefits are the speed of implementation.

Apologies for the potentially ignorant question, I might be missing something, just being paranoid.

It's no problem really, there's a value in going through this and we are always happy to receive feedback and questions from people actually using (or planning to use) the library.
We have 3 different methods that do pull in different ways:

Future<Iterator<ReceivedMessage>> pullAsync(String subscription, int maxMessages)

async pull method, sends just one pull request to subscription and returns up to maxMessages (this is the method we are planning to make always use returnImmediately=false).
Message deadlines are renewed automatically by our library until you consume the message with iterator.next(), after that you are on your own :) and you must call message.modifyAckDeadline(...) if you need to postpone message deadline.
You must ack and nack messages yourself, with message.ack() or message.nack().

Iterator<ReceivedMessage> pull(String subscription, int maxMessages);

sync pull method, sends just one pull request to subscription and returns up to maxMessages (in our idea this method should always use returnImmediately=true).
Message deadlines are renewed automatically by our library until you consume the message with iterator.next(), after that you are on your own :) and you must call message.modifyAckDeadline(...) if you need to postpone message deadline.
You must ack and nack messages yourself, with message.ack() or message.nack().

MessageConsumer pullAsync(String subscription, MessageProcessor callback, PullOption... options)

Implements continuous pulling on your behalf. For each received message the callback is executed.
By default all callback are executed on the same, single threaded, executor. If you need more "executing power" you can pass the PullOption.executorFactory(ExecutorFactory) option to the method
To control the maximum number of "pending" message you application can afford (i.e. messages pulled but whose callback has not yet terminated) you can pass the PullOption.maxQueuedCallbacks(int) to the method - by default we set this value to 100
Message deadlines are automatically renewed by our library until the callback is executed on the message (either failing or succeeding)
Messages are automatically "acked" if callback terminates successfully, "nacked" if the callback throws an exception
You can stop pulling by callingclose() on the MessageConsumer

Long story short, the single threaded executor you see in https://github.com/GoogleCloudPlatform/google-cloud-java/blob/master/google-cloud-pubsub/src/main/java/com/google/cloud/pubsub/MessageConsumerImpl.java#L159 is just used when you use method 3) which does continuous pulling for you - and you could even avoid this by passing your own ExecutorFactory.
In your scenario you would use method 1) and then call get() on the returned future, so no extra threads for you :)

Thank you. Indeed, option no.1 with get() would serve the purpose. Also, your explanation of option no 3 highlights a few opportunities. I have tried it, but there were a couple of exceptions now and then that I could not decipher, but this is a topic for another thread, possibly.
I will copy the explanation and stick it on our internal wiki - it is very good intro. Would be great if the text written above could have made its way into some official documentation - my opinion is that it would benefits both the devs starting on the lib, and the penetration of the tech in general.
Thank you again.

Remaining to do: add the extended explanation by mziccard@ into the docs somewhere.

@pongad : could you triage this w.r.t. the Pub/Sub high-performance rewrite? Basically, determine if there is any use case in this issue not addressed in the rewrite, or if the noted use cases need to be discussed in documentation in the rewrite.

@garrettjonesgoogle From what I understand, @evmin still needs the synchronous pull method. We have made a decision to deprecate, but not remove, the previous hand-written client. All users who use these clients can continue doing so, so I don't think there's immediate cause of worry.
That said, I think we should revisit our decision to make package-private the SubscriberClient::pull method. Even though the new Subscriber is the way "things should be", I think there's value in keeping a non-deprecated synchronous version to help our users migrate from old code bases that assumes synchronous calls.

+1 for the synchronous call. Please check Apache Camel - it does manage the consumer threads at the framework level, which is critical to leave exposed to developers in certain scenarios.

@pongad, I think the understanding in this thread was that @evmin could achieve synchronous functionality through calling get() on a future returned from an async call.
@evmin , I'm curious why you are bringing up the fact that Apache Camel manages consumer threads; there still remains the fact that gRPC uses a thread pool of its own, thus anything that seems synchronous still does execute on a separate gRPC thread.
@evmin what is the motivation for direct access to SubscriberClient::pull from the system design perspective? Doing such a call on your own requires some logic to make it work right, e.g. extending deadlines when the work is taking longer, and it also consumes a user thread. I could see the argument that the new Subscriber class that we are writing doesn't fit a user's needs and they need to write their own pulling logic. Although in that case, I would really like to know what use cases are missing. If the only remaining use case is migrating current direct callers of pull, then maybe letting them sit on the deprecated code for a couple months is sufficient.
Let me know if I'm missing something!

@garrettjonesgoogle
TL;DR
Current GA library does have a sync pull. Feature consistency across libraries is paramount for stability of the solutions on top of them. Sync pull has been confirmed earlier and was one of the key factors for us to move ahead.
Longer version.
A bit of a background. I am a customer advocate for the GCP tech. I am currently implementing three major projects where the core component is Google PubSub  in a traditional, non tech organisation. Exactly the market Google aims to capture on the large scale, if I am not mistaken. My aim is to ensure that the projects are a success.
As with any non technical company, the skill level of the devs varies. And one of the risk mitigation strategies would be to use the abstraction frameworks, where the complex integration patterns reduced to a mere statement. Camel would be an example.
That comes at the price of having the framework stable and resilient - it should be able to handle the abuse of the developers and the end user requirements. In my career I have seen a fair bit of bending the tech - ETL solutions implemented on a service bus and databases used as the HTTP proxy. I know, I know. But if that's what customer is willing to pay for -  technology should be able to handle.
The non tech companies have little capability to redevelop the existing solutions - it is considered a risk and they are  generally are very risk averse.

@evmin , I'm curious why you are bringing up the fact that Apache Camel manages consumer threads; there still remains the fact that gRPC uses a thread pool of its own, thus anything that seems synchronous still does execute on a separate gRPC thread.

Well, we build on Camel to hide the complexity and I do not completely understand all the implications of how the new model would work for the solutions we have built on top of it. We do use Camel's capability to manage threads heavily  to scale up and down to align with the downstream processing. For example we use a single thread to pull just a single message synchronously to test if the end system is back on line and can accept the calls (proprietory, non HTTP). If it does - we scale the number of threads to pump the data. If not - scale down to single thread with back off intervals.
That's why migration to the new, self managed gRPC based library remains a risk factor from my perspective - and having the sync pull allows me to avoids retrofitting of the existing logic  on top of Camel / GA library combo. When the time comes I essentially would like to be able to swap the old library for the new with the minimum fuss. So I do need the the synchronous pull and the ability define the number of threads.
Also, a larger chunk of the third party devs we are working with - they all use synchronous pulls - though I have not done any research as to why. If it works for them - that's great.

@evmin what is the motivation for direct access to SubscriberClient::pull from the system design perspective? Doing such a call on your own requires some logic to make it work right, e.g. extending deadlines when the work is taking longer, and it also consumes a user thread.

That's correct. And we are totally fine with that - current GA library expects that, and we came to rely on the ability to manage it ourselves. Abandoning the message to be redelivered after the default timeout is another working scenario for one of the implementations.
From our earlier discussion I understood that pull will be there no matter what. That was essentially one of the key factors that allowed me to convince the team to go ahead - that when the new library hit the ground we would only need to do a swap and that has been priced in into the maintenance costs.
The discussion to remove sync pull is worrisome - as reworking the solutions to async would attract additional effort from our vendors, and, hence, invoices.

If the only remaining use case is migrating current direct callers of pull, then maybe letting them sit on the deprecated code for a couple months is sufficient.

Please consider that the new library will need to supersede the existing GA, where the pull capability is present. So by the time it is released, the GA based client might be embedded so deeply, that reworking these models would simply not be possible.
Generally speaking, more diverse capability set is always better than a narrow one. And if a capability needs to be removed there should be PLENTY of time for end projects to accommodate.
To give you a feel from the enterprise world. We have a solution that has been out of support by vendor for 7 years. It works and there is no inclination to upgrade. Salesforce took one and a half years to deprecate TLS 1.0. RedHat supports the old releases for at least 5. And there is a reason for that - things in the enterprise world are slow. Which is generally good for the vendor, as the tech becomes incumbent and generates a stable income stream.
So when the new library is released and stabilised as GA it would take at least 6 months for it to make its way into a Camel release. And then there is no guarantee that the clients using the previous version will be able to quickly move onto the new version and adapt to the new scheme of things. At least we wouldn’t and that would preclude us from moving on.
Camel backward compatibility and the feature stability were one of the core selling points. With PubSub component being a part of the offering Google instantly gets a wider market, but the feature stability is paramount.
Hope I was able to bring my point across.

TL;DR
Current GA library does have a sync pull. Feature consistency across libraries is paramount for stability of the solutions on top of them. Sync pull has been confirmed earlier and was one of the key factors for us to move ahead.

The earlier confirmation coupled with your dependency on it is reason enough to keep it (reason 1).

Longer version.
A bit of a background. I am a customer advocate for the GCP tech. I am currently implementing three major projects where the core component is Google PubSub  in a traditional, non tech organisation. Exactly the market Google aims to capture on the large scale, if I am not mistaken. My aim is to ensure that the projects are a success.
As with any non technical company, the skill level of the devs varies. And one of the risk mitigation strategies would be to use the abstraction frameworks, where the complex integration patterns reduced to a mere statement. Camel would be an example.
That comes at the price of having the framework stable and resilient - it should be able to handle the abuse of the developers and the end user requirements. In my career I have seen a fair bit of bending the tech - ETL solutions implemented on a service bus and databases used as the HTTP proxy. I know, I know. But if that's what customer is willing to pay for -  technology should be able to handle.
The non tech companies have little capability to redevelop the existing solutions - it is considered a risk and they are  generally are very risk averse.

For my understanding: is the PubSub interface in google-cloud-java exposed directly to any of your target population of users? Or is everyone going through Apache Camel? If so, I'm assuming Apache Camel would completely abstract away the PubSub support?
I'm mostly curious to know exactly who will be coding against PubSub - it helps to know who our users are.

@evmin , I'm curious why you are bringing up the fact that Apache Camel manages consumer threads; there still remains the fact that gRPC uses a thread pool of its own, thus anything that seems synchronous still does execute on a separate gRPC thread.

Well, we build on Camel to hide the complexity and I do not completely understand all the implications of how the new model would work for the solutions we have built on top of it. We do use Camel's capability to manage threads heavily  to scale up and down to align with the downstream processing. For example we use a single thread to pull just a single message synchronously to test if the end system is back on line and can accept the calls (proprietory, non HTTP). If it does - we scale the number of threads to pump the data. If not - scale down to single thread with back off intervals.

I wonder if such up/down scaling support could be added to the google-cloud-java PubSub library. If so, we couldn't promise it in short order, which is probably reason 2 for us to expose the synchronous pull.

That's why migration to the new, self managed gRPC based library remains a risk factor from my perspective - and having the sync pull allows me to avoids retrofitting of the existing logic  on top of Camel / GA library combo. When the time comes I essentially would like to be able to swap the old library for the new with the minimum fuss. So I do need the the synchronous pull and the ability define the number of threads.

For my understanding: will the Camel part be removed, where users will switch directly to the PubSub interface?

Also, a larger chunk of the third party devs we are working with - they all use synchronous pulls - though I have not done any research as to why. If it works for them - that's great.

@evmin what is the motivation for direct access to SubscriberClient::pull from the system design perspective? Doing such a call on your own requires some logic to make it work right, e.g. extending deadlines when the work is taking longer, and it also consumes a user thread.

That's correct. And we are totally fine with that - current GA library expects that, and we came to rely on the ability to manage it ourselves. Abandoning the message to be redelivered after the default timeout is another working scenario for one of the implementations.
From our earlier discussion I understood that pull will be there no matter what. That was essentially one of the key factors that allowed me to convince the team to go ahead - that when the new library hit the ground we would only need to do a swap and that has been priced in into the maintenance costs.
The discussion to remove sync pull is worrisome - as reworking the solutions to async would attract additional effort from our vendors, and, hence, invoices.

If the only remaining use case is migrating current direct callers of pull, then maybe letting them sit on the deprecated code for a couple months is sufficient.

Please consider that the new library will need to supersede the existing GA, where the pull capability is present. So by the time it is released, the GA based client might be embedded so deeply, that reworking these models would simply not be possible.
Generally speaking, more diverse capability set is always better than a narrow one. And if a capability needs to be removed there should be PLENTY of time for end projects to accommodate.

Technically, it isn't being removed from the GA library; the proposal was just to not add it to the new one.
I would argue that a more diverse capability set isn't always better; that generally means more to maintain, which can be wasteful if you implement features that only a few users might want. This definitely doesn't apply to your case though.

To give you a feel from the enterprise world. We have a solution that has been out of support by vendor for 7 years. It works and there is no inclination to upgrade. Salesforce took one and a half years to deprecate TLS 1.0. RedHat supports the old releases for at least 5. And there is a reason for that - things in the enterprise world are slow. Which is generally good for the vendor, as the tech becomes incumbent and generates a stable income stream.

Understood!

So when the new library is released and stabilised as GA it would take at least 6 months for it to make its way into a Camel release. And then there is no guarantee that the clients using the previous version will be able to quickly move onto the new version and adapt to the new scheme of things. At least we wouldn’t and that would preclude us from moving on.
Camel backward compatibility and the feature stability were one of the core selling points. With PubSub component being a part of the offering Google instantly gets a wider market, but the feature stability is paramount.
Hope I was able to bring my point across.

Indeed. You have made clear the extent of the user base that depends on this feature, so we will definitely retain the feature in google-cloud-java.

The earlier confirmation coupled with your dependency on it is reason enough to keep it (reason 1).

Thank you. I truly appreciate this.

For my understanding: is the PubSub interface in google-cloud-java exposed directly to any of your target population of users? Or is everyone going through Apache Camel?

Actually both.  External partners go directly through the API - we are trying to standardise on PubSub as the integration layer. Got two external vendors on Java client. TO my understanding one of them is using synchronous calls as well.
Internal teams - use Camel.

If so, I'm assuming Apache Camel would completely abstract away the PubSub support?

Kind of. The intention is to get Camel to abstract the implementation details of PubSub specifics, where PubSub is just yet another produce or consumer unified withing the Camel framework.

I'm mostly curious to know exactly who will be coding against PubSub - it helps to know who our users are.

In our case - external vendors. I am happy to go into the details here, would prefer to do that by email.

For my understanding: will the Camel part be removed, where users will switch directly to the PubSub interface?

I hoped for exactly the opposite - Apache Camel is an OpenSource Routing and Mediation framework that is used at the core of quite a number of commercial products - JBoss FUSE, Talend ESB, etc. PubSub component will naturally flow to these products hopefully leading to addition uptake of Google PubSub.

Indeed. You have made clear the extent of the user base that depends on this feature, so we will definitely retain the feature in google-cloud-java.

Thank you very much for this.

The Pub/Sub rewrite has been merged and released. Documenting returnImmediately as commented previously is no longer relevant. Doing a synchronous pull in SubscriberClient is supported. Closing out the issue.

The doc says return_immediately is set to False so that the system waits (for a bounded amount of time) until at lease one message is available. Do we know what's this "bounded amount of time"?


Dockerfile is busted

When trying to run the Dockerfile, I get:
W: Failed to fetch http://deb.debian.org/debian/dists/jessie-updates/main/binary-amd64/Packages  404  Not Found

For context:
Oldstable: Debian Jessie, jessie-updates and jessie-backports REMOVED 2019-03-24


Code showing on website

Code is showing on the Task Details page (http://allready-d.azurewebsites.net/Admin/Task/Details/69)

Working on it


Line Chart is loaded after user interaction

@traviscox
i'm using Ignition 8.1.12 with Apex Latest Module .. Line chart loaded on the view after user interaction on the page (Like press on Side Menu bar ) . after that chart appears on the view .
this happened one the first load of the page or refresh the the page .

Can you send over a backup of a view with that problem? I can't seem to replicate it.

Issue has been resolved in 1.0.6:
https://github.com/Kyvis-Labs/ignition-apexcharts-module/releases/tag/1.0.6

This issue was resolved improperly. It will revert back to the same behavior in 1.0.9.
https://github.com/Kyvis-Labs/ignition-apexcharts-module/releases/tag/1.0.9
However, all you need to do is wrap the chart inside of Flex container inside of the coordinate container when the coordinate container is in "percent" mode.
Can you update and let me know?

*bump

@traviscox
This appears to still be an issue.
Ignition 8.1.20, ApexCharts 1.0.9
Please see attached exported views. You can see I have the same ApexChart nested in different configurations of Flex & Coordinates. I have been having an issue where certain charts would not display until a resize of the viewport (which is what I assume @tamerplc is doing by opening the side bar). I found that if I put my charts (no nesting in a Flex type view) at grow=0, shrink=0, basis=50px, this issue would not occur. The moment I put grow=1 and shrink=1, the issue would re-appear. Sometimes the charts would display correctly the first time, sometimes not. Unfortunately I cannot share those views so I hope the views I attached and this thread's issue are related to mine. You will see charts "In Coord -> Flex" and "In Flex -> Coord -> Flex" do not show up until a viewport resize.
apex.zip

Fixed the resizing issue in 1.0.10: Can you download and try it out:
https://github.com/Kyvis-Labs/ignition-apexcharts-module/releases/tag/1.0.10

Had to fix another small issue, now at 1.0.11:
https://github.com/Kyvis-Labs/ignition-apexcharts-module/releases/tag/1.0.11

It seems 1.0.10/1.0.11 fixed the issue.
Thank you!

@traviscox, the view I attached in https://github.com/Kyvis-Labs/ignition-apexcharts-module/issues/7#issuecomment-1372297758 is fixed in versions > 1.0.9, but I am still having the same issue. This is with charts that are in widgets in a dashboard application (modified version of https://www.inductiveautomation.com/exchange/101/overview). I'm working on getting a view built that replicates the issue, as of right now my architecture and the views rely heavily on multiple project resources.

It appears the increase of bindings on the ApexChart properties correlates with the issue. It's as if the chart loads and renders, a late binding finishes executing, and then the chart won't display until viewport resize.

Ok, send me an example. I had to put a timer in there that will force a reload after initial mount.

See attached project. If you open the "/" page, use the button to navigate away, then go backward/forward until one of the charts stays at "No Data". At that point the viewport resize will render it.
ApexChartsBug_20230131230600.zip

Ok, I think we have finally figured out the root of the problem. The issue was a race condition with how the chart initially rendered and when bindings fired and were synced to the browser. We are handling the resize differently now using a react resize detector. That avoids the race condition. With your example I easily reproduced it in 1.0.12 but it never happened in 1.0.13. So give 1.0.13 a try:
https://github.com/Kyvis-Labs/ignition-apexcharts-module/releases/tag/1.0.13

Looks like 1.0.13 fixed all the issues I was experiencing.
Thanks a ton!


Utilize Datagen more

A lot of JSON files are still handwritten, especially in cases like the darkdweller log and its model.
To make life easier for all of us, write custom functions for data gen and let the data generator do the work.
Some checkboxes to track general progress:

[x] Block states
[x] Block models
[x] Item models
[x] Block Tags

Merged with #31


Feature: CLI backend configuration overhaul

CLI provider configuration serves the purpose well, but it could be improved:

Provider configuration is done via auth command, even though, some providers does not require explicit auth in configuration (should be maybe backend command?)
You can’t have multiple backends configured for the same provider (e.g. for different models, passwords, endpoints, configurations) with unique names. To improve this some configuration change might be needed, but I saw some migration code already, maybe it can be done in smooth way.

I think we could certainly improve the way the providers/auth mapping is done and support *:1 auth:provider.

@AlexsJones I've been exploring the cmd package for a while now. I'd like to give this a try.

Sure thing, no permission needed

Sure thing, no permission needed

Very well, I'll open a PR soon.

Hey @AlexsJones @bwplotka, I was wondering if modifying the AIProvider struct to something like:
type AIProvider struct {
    Backend string
    Config []AIConfig
    DefaultConfig int
}

type AIConfig struct {
	Name           string  `mapstructure:"name"`
	Model          string  `mapstructure:"model"`
	Password       string  `mapstructure:"password" yaml:"password,omitempty"`
	BaseURL        string  `mapstructure:"baseurl" yaml:"baseurl,omitempty"`
	EndpointName   string  `mapstructure:"endpointname" yaml:"endpointname,omitempty"`
	Engine         string  `mapstructure:"engine" yaml:"engine,omitempty"`
	Temperature    float32 `mapstructure:"temperature" yaml:"temperature,omitempty"`
	ProviderRegion string  `mapstructure:"providerregion" yaml:"providerregion,omitempty"`
	TopP           float32 `mapstructure:"topp" yaml:"topp,omitempty"`
	MaxTokens      int     `mapstructure:"maxtokens" yaml:"maxtokens,omitempty"`
}

would do the trick?
And then modifying the CLI commands to ask users for the backend and a configuration name whenever they add a configuration. Maybe we can add a --config-name flag for the update and remove commands and if this flag is not set, then the operation will be performed on the default config for that particular backend.


Fixed number mismatches

In some documentation (and tests) the atoms that are claimed to test for
and the atoms that are actually tested for differ. Fixed those.

Thanks.


#sudo su README.md

#sudo su
Pull Request Type

[x] ✨ feat
[x] 🐛 fix
[x] ♻ refactor
[x] 💄 style
[x] 🔨 chore
[x] 📝 docs

Relevant Issues

resolves #xxx
What is in this change?

Additional Information

Developer Validations

[x] I ran yarn lint from the root of the repo & committed changes
[x] Relevant documentation has been updated
[x] I have tested my code functionality
[x] Docker build succeeds locally

yarn install


Roll engine b14d9719607a..4d7afb9ab72b (2 commits)

https://github.com/flutter/engine/compare/b14d9719607a...4d7afb9ab72b
git log b14d9719607a876778b27149ec37ea170187bb97..4d7afb9ab72b4d19fd55cb6e377a98ec8bbcd771 --no-merges --oneline
4d7afb9ab Roll src/third_party/skia ed7966f179c6..698fa78b3cae (1 commits) (flutter/engine#9294)
05e1b6e50 Roll src/third_party/skia d82ca0bf2c99..ed7966f179c6 (2 commits) (flutter/engine#9293)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff (liyuqian@google.com), and stop
the roller if necessary.

Trybots failed. These were the failed builds: https://cirrus-ci.com/task/6186144597803008

Commit queue failed; closing this roll.


Bug: Unable to play any media from card

Describe the bug
[1610457704] Plex media not found using payload: '{"title":"Harold & Kumar Escape from Guantanamo Bay"}'
To Reproduce
Steps to reproduce the behavior:

Click on any title

Expected behavior
The movie to begin playback, or the option to select playback device.
Screenshots
N/A
Checks
Please check below if true:
[x] I am running Home Assistant on HTTP protocol
[ ] I am running BOTH Home Assistant AND Plex on HTTPS protocol
[x] My Plex server is accessible through protocol, port and ip/hostname I have specified for the card.
Version
2.0.12
Additional context
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 185, in handle_call_service
    await hass.services.async_call(
  File "/usr/src/homeassistant/homeassistant/core.py", line 1491, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1526, in _execute_service
    await handler.job.target(service_call)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 213, in handle_service
    await self.hass.helpers.service.entity_service_call(
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 658, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 811, in async_request_call
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 695, in _handle_entity_call
    await result
  File "/usr/src/homeassistant/homeassistant/components/cast/media_player.py", line 479, in async_play_media
    await self.hass.async_add_executor_job(
  File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 52, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/homeassistant/homeassistant/components/cast/media_player.py", line 519, in play_media
    media, _ = lookup_plex_media(self.hass, media_type, media_id)
  File "/usr/src/homeassistant/homeassistant/components/plex/services.py", line 122, in lookup_plex_media
    raise HomeAssistantError(
homeassistant.exceptions.HomeAssistantError: Plex media not found using payload: '{"title":"Harold & Kumar Escape from Guantanamo Bay"}'

restarted HA and it worked. no idea what happened.


On some slacks I only see reactions with matterircd 1.9.3 release

Hi, I'm having problems with 1 slack instance where I only see reactions, I can't join in irssi the channels that I am in the slack. And I typically only see reactions, no messages. I've tried 2 different IRC clients so the problem is clearly matterircd. I am using 1.9.3 . It seems weird that I only see reactions.
I don't seem to suffer the same problems with 1.9.2.
In the freenode channel another user said they suffered from the same problem with 1.9.3 and downgraded accordingly.
Other observations:
I would be joined to the &users channel. it would list more than 100 users. I could not join channels I was already in on slack, it said I'd have to be invited. If someone reacted in the channels I'd see the reaction.

Thanks for reporting, seems to be a bug in the upstream slack library.
I've fixed this in master and will be releasing a 1.9.4 soon


IE11 Compatability

Hi,
Using IE11 (with an addition of https://cdn.polyfill.io/v2/polyfill.min.js?features=default,matchMedia,fetch,Element.prototype.placeholder,Array.prototype.includes to hopefully grab everything I'd need to for compatibility since I was seeing fetch used) the UI isn't responding correctly; selections are not being added to the list of options; they just disappear. Are there any additional deps I should be using to solidify the browser support?

Hi @zslabs;
Would you be able to send me your config for Choices so I can try and identify the issue?
Thanks

Hey!
I was testing the default GH pages build (locally) under VirtualBox's modernIE build of IE11.

Hi @zslabs,
This has been resolved as of version 1.1.3. IE doesn't support DocumentFragment.children so I've opted for DocumentFragment.childNodes instead.
Thanks

Awesome! Thanks so much for jumping on that; can confirm it's working as expected. Appreciate it!

I think we still have some IE11 issues. Searching doesn't seem to work. I'll update if I can make a replicable test case.

I'm seeing issues with ie11, due to the unsupported es2015 code in the index file:

SCRIPT1002: Syntax error
Choices (249,31)

249        addItemText: (value) => { 250          returnAppuyez sur Entrée pour ajouter "${value}"; 251        },

Hi @inergy,
Is this on the demo site or your own code?
Thans

On the demo site and I've cloned the repo and can reproduce locally.  The index.html file has es2015 code, which I tracked it down to [this commit].(https://github.com/jshjohnson/Choices/commit/8be12c20cd514febd6d0a79c73988129c2f9c5ea#diff-eacf331f0ffc35d4b482f1d15a887d3b)
I did a quick refactor using es5 and things started working as expected (although, there are a few issues to be resolve after fixing the arrow functions and template literals).

Thanks for the heads up - this should now be resolved with these two commits:

https://github.com/jshjohnson/Choices/commit/31a57a0e2b42a611e74cac4fd70c2b10163c15ad
https://github.com/jshjohnson/Choices/commit/9bb84df8d0466c79c75c332b09d4dc6efc1a8472

👍


cargo doc --all -p mypackage --open should work

I want to be able to generate doco for all crates in and dependent on a workspace.

Describe the solution you'd like
I would like to be able to run a command like cargo doc --all --open or cargo doc --all -p somecrate --open and get documentation for all the crates that are (a) in my package or (b) dependent on them (or just the specified crate and its dependencies, if I specify one of the crates in my workspace).
Notes
At the moment, I get an error message:
error: Passing multiple packages and `open` is not supported.
Please re-run this command with `-p <spec>` where `<spec>` is one of the following
... [list of crates]

This should be fixed in 1.35 (which releases next week).  Can you try out the beta and see if it works for you?

It's working in nightly, anyway. Thanks.

Do you have javascript enabled?

Do you have javascript enabled?

javascript.enabled;true

Hm, that's strange.  Just to be clear, is the "Crates" listing in the sidebar visible? Is it empty?  Did Cargo print out that it was "Documenting" the crates?  Are the crates listed in target/doc/…?  Are there any errors printed on the javascript console?  Have you tried different browsers?  Running cargo clean?  Failing that, can you create an MRE?

Now this is working differently on two different boxes. On one box, after a few seconds, a list of crates appears, which is what I want,
On the box that I am using at the moment, that does not happen. So let me check your questions.
...is the "Crates" listing in the sidebar visible? No.
~~Is it empty? ~~
Did Cargo print out that it was "Documenting" the crates?  Yes.
Are the crates listed in target/doc/…? Yes.
Are there any errors printed on the javascript console? Yes: TypeError: paths is undefined

buildIndex file:///home/martin/git/shmup2/target/doc/main.js:95
initSearch file:///home/martin/git/shmup2/target/doc/main.js:95
<anonymous> file:///home/martin/git/shmup2/target/doc/search-index.js:758

I hope that helps.

Hm, so some time ago rustdoc changed (presumably a change in the minifier).  The only way I can think of this happening is if you documented different crates with different versions of cargo.  Did you run cargo clean and try again, making sure only one version of cargo is used?

@ehuss I did cargo clean and it is working now thanks.


React Native freezes UI when fetching response from API

Description
Hello everyone, I think this problem has been around for a long time, during fetching the API response, React Native will freeze the UI, no matter if you press the back or other buttons, you will not get the response until the application gets any response from the API.
I have tried Redux-Saga, Redux-Thunk, Axios or the Javascript fetch()...they all cannot fix the problems, It seems that the fetch request occupied the main thread of React Native.

I think the problem is in the thread, all API requests should not occupy each other on the main thread of RN, so I am looking for some methods, try to put the request on a thread other than the main thread, I don't know if there is any similar solutions?
Thanks all!
Version
0.66.0
Output of npx react-native info
System:
OS: macOS 11.5
CPU: (4) x64 Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz
Memory: 507.04 MB / 32.00 GB
Shell: 5.8 - /bin/zsh
Binaries:
Node: 14.18.1 - /usr/local/opt/node@14/bin/node
Yarn: 1.22.17 - /usr/local/bin/yarn
npm: 6.14.15 - /usr/local/opt/node@14/bin/npm
Watchman: 2<IP_ADDRESS> - /usr/local/bin/watchman
Managers:
CocoaPods: 1.11.2 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 21.2, iOS 15.2, macOS 12.1, tvOS 15.2, watchOS 8.3
Android SDK: Not Found
IDEs:
Android Studio: 2020.3 AI-203.7717.56.2031.7678000
Xcode: 13.2.1/13C100 - /usr/bin/xcodebuild
Languages:
Java: 11.0.11 - /usr/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: 17.0.2 => 17.0.2
react-native: 0.66.0 => 0.66.0
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found
Steps to reproduce

Create a heavy API request by using Axios / fetch()

Same problem here, I was using redux toolkit, and now react-query, but the UI freeze during fetch call. It is more visible on old device, maybe that's the problem...

@samjayhk , do you solve this problem? how to solve it?

Is there any solution to be applied in order to solve this problem? I'm using axios with redux-saga and facing the same problem. It is more visible on old device as @martinezguillaume said. Please I need some help to fix it.

Just to let you know I've tried to use fetch api but the problem still the same

I'm facing the same problem recently, I found out this repo but need to test it: https://github.com/billmalarky/react-native-queue#installation
Will update the result here.

@Vietvantue any updates about 'react-native-queue'? If you find any thing please let us know.

I'm facing the same problem.
Is there any solution?


lemmy: 0.17.3 -> 0.17.4

Description of changes
Just a simple update
Things done

Built on platform(s)

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

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

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

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

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

[ ] Fits CONTRIBUTING.md.

@marcusramberg @billewanick you might be interested in this.
@CobaltCause

Duplicate of #237716?

Why are the hashes different in the other PR?

This PR got the wrong hashes.

Duplicate of #237716?

Yes. Closing this one.


[Bug] There is no detail error message for sql-interception

Search before asking

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

Version
1.1.2
1.1.3
What's Wrong?
When hit the rule, server just close connection. And there isn't any error message.
(2013, 'Lost connection to MySQL server during query')

What You Expected?
show the detail message
Error running query: errCode = xxx, detailMessage = Hit block rule --- {{rule name}} , limit partition num / tablet_num / cardinality

How to Reproduce?
No response
Anything Else?
No response
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

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

There is detail message when hit the cardinality limit.
And no detail message when hit the partition  limit


Jesse: Watch hraovat.com

Jesse requests the watch of the watch_keyword hraovat\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

hraovat\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by tripleee in Charcoal HQ


Implement sign support

Tracked at https://linear.app/beyondstorage/issue/BS-212/implement-sign-support

Implemented and documentation has been added.

#104
doc


Show keyboard language near text input cursor or mouse pointer

Description of the new feature / enhancement
When the cursor change to text input (normally blinking vertial line), a small nation flag or keyboard layout name is showed near the cursor. So the user know what currnet keyboard layout is. Avoid mistype of unexpected language and delete before start typing again.
Scenario when this would be used?
Many people are using more than one language/keyboard layout on their system e.g. English + their native language. This could help increasing productivity by not having to look at the bottom right corner to identify current keyboard. Or even need to type a few characters to see what current language then delete and re-type again.
Supporting information
No response

/dup https://github.com/microsoft/PowerToys/issues/27293


override modifier should able to be used with declare modifier

Suggestion

🔍 Search Terms
useDefineForClassFields
override declare
'override' modifier cannot be used with 'declare' modifier. ts(1243)
Property 'a' will overwrite the base property in 'Cls'. If this is intentional, add an initializer. Otherwise, add a 'declare' modifier or remove the redundant declaration.(2612)
✅ Viability Checklist

My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion
When declaring class fields:
The override modifier should be able to be used with declare modifier.
Have ! work in the place of declare OR:
Remove this error if ! or override is specifically given: Property 'a' will overwrite the base property in 'Cls'. If this is intentional, add an initializer. Otherwise, add a 'declare' modifier or remove the redundant declaration.(2612)
📃 Motivating Example
Given a decorator Prop() that somehow declares some metadata on the class field,
that would later be used in some other technical components like Database ORMs or Validators, etc.
Consider this example, before useDefineForClassFields set to true:
interface Animal {
  animalStuff: any;
}
interface Dog extends Animal {
  dogStuff: any;
}

class AnimalHouse {
  internalProp: number;

  @Prop({
    default: {
      animalStuff: 'food',
    }
  })
  resident: Animal;

  @Prop({
    default: 'foo'
  })
  someOtherProp: string;

  constructor(animal: Animal) {
    this.resident = animal;
  }
}

class DogHouse extends AnimalHouse {
  @Prop({
    default: {
      animalStuff: 'food',
      dogStuff: 'dog food',
    }
  })
  override resident: Dog;
}

Note that the DogHouse is defined quite straightforward and expected in a general sense.
Now after useDefineForClassFields set to true, the current way of specifying the DogHouse becomes:
class DogHouse extends AnimalHouse {
  @Prop({
    default: {
      animalStuff: 'food',
      dogStuff: 'dog food',
    }
  })
  declare resident: Dog;
}

It doesn't look too bad, but things can get more complicated:
class DogHouse extends AnimalHouse {
  override internalProp: 42;

  @Prop({
    default: {
      animalStuff: 'food',
      dogStuff: 'dog food',
    }
  })
  declare resident: Dog;

  @Prop({
    default: 'foo'
  })
  override someOtherProp: string = 'foo';

  @Prop({
    default: 'foo'
  })
  someOtherProp2: string;
}

Now it sucks.
The consistency and readability from using override is completely screwed up by declare.
At least the override should be allowed to be used with declare to make it suck a little less:
class DogHouse extends AnimalHouse {
  override internalProp: 42;

  @Prop({
    default: {
      animalStuff: 'food',
      dogStuff: 'dog food',
    }
  })
  declare override resident: Dog;

  @Prop({
    default: 'foo'
  })
  override someOtherProp: string = 'foo';

  @Prop({
    default: 'foo'
  })
  someOtherProp2: string;
}

The best case however, is to have ! work in the place of declare:
class DogHouse extends AnimalHouse {
  override internalProp: 42;

  @Prop({
    default: {
      animalStuff: 'food',
      dogStuff: 'dog food',
    }
  })
  override resident!: Dog; // No declaration emit

  @Prop({
    default: 'bar'
  })
  override someOtherProp: string; // With declaration emit

  @Prop({
    default: 'foo'
  })
  someOtherProp2: string;
}

💻 Use Cases
As example suggested.
The code readability degradation from declare is unacceptable.
I am using typescript with useDefineForClassFields set to off now.
Please consider my suggestion..

The best case however, is to have ! work in the place of declare

! on a property already means something else though, specifically "don't check that this property is assigned in the constructor" so that would be a rather large breaking change.

"don't check that this property is assigned in the constructor"

I'm a little disagree with this interpretation.
Isn't that mean the same "Don't check/do-anything about the initiation of this property ."
Even if you disagree with !, !! is still better than declare.
Given what useDefineForClassFields does, it is the one that's making the breaking changes.

Isn't that mean the same "Don't check/do-anything about the initiation of this property ."

Yes, that’s what ! on a property already does, because there are patterns where a property does get initialized but TS can’t verify it at compile-time (e.g. if the property is initialized by an indirect method call in the ctor).
If you want something to not be emitted, use declare.  That’s why it’s there.

You see, I already have multiple layered inherited classes, a very complex structure.
Like in the examples, most subclasses don't have a constructor. They are just decorated differently.
When subclass overrides parent property, they are declared with override prop!: Type;
I don't really care about the emit/no-emit of the properties.
I would like my code continue to work after I specify target: 'es2022' in tsconfig.json, and the code readability and maintainability not drop.
And now, with this useDefineForClassFields defaults to true.
This doesn't work.
People choose TypeScript for its readability and maintainability. Javascript that Scales, remember?
It's a shame that TypeScript is willing to drop both for useDefineForClassFields nonsense.

Another approach.
Remove this error if ! / override is specifically given:
Property 'a' will overwrite the base property in 'Cls'. If this is intentional, add an initializer. Otherwise, add a 'declare' modifier or remove the redundant declaration.(2612)
I don't know what's happening around useDefineForClassFields  and declare override and !
But you guys should rethink it.
I don't think you will get a good adoption of useDefineForClassFields if you keep the way it is now.
Maybe Interview some real-world users.

If your issue is useDefineForClassFields breaking your code, you can just set it to false.  If that's not possible because you depend on third-party code that expects the [[Define]] behavior, well, you need to take that up with the ECMAScript committee, as that is how the class fields spec is written and the backward-compatibility mechanism TS has provided is to manually set useDefineForClassFields: false.  If you were writing plain JS with class fields, you wouldn't even have that luxury.
Also, please tone down the language and hostility if you don't want the TS devs to lock your issue.

@fatcerberus  Apologies If my words are too offensive. I'm not very good at English after all. I just wanted to express my feeling on this issue and the direction it is developing. Now I believe you have acknowledged my frustration. I hope the user frustration still means something to TS devs. Maybe I'll start a new issue and rephrase all about this after further discussion.
It's not about the new ES Class define behaviour, not on their part. This is exactly a TypeScript issue.
According to your own reply here, you are well aware of no matter what TS do, the eventual behaviour will change because of the underlying runtime.
Then it's ok to treat it transparently and not throw errors on this:
class DogHouse extends AnimalHouse {
  @Prop({
    default: {
      animalStuff: 'food',
      dogStuff: 'dog food',
    }
  })
  override resident!: Dog;
}

At least it should have an option to disable this error.
Property 'resident' will overwrite the base property in 'AnimalHouse'. If this is intentional, add an initializer. Otherwise, add a 'declare' modifier or remove the redundant declaration.(2612)
FYI the decorator is working as expected. I authored those decorators. It's using the metadata registering approach.
It's not about the code not working; it works.
It's about TypeScript not allowing this formally-valid clear, precise way of writing code anymore, and proposes another much less favourable approach, known as declare.

I've put it in another way, hopefully it can convenience you more.
https://github.com/microsoft/TypeScript/issues/51536

Please consider this case.
import type { Model, ModelView, Prop } from 'myORMLib';

@Model
class SomeModel {
    @Prop({ type: 'uint16' })
    prop1!: number;
    // ...   propN: type;
    @Prop({ maxLength: 256 })
    prop15!: string;
}

// make all properties readonly
// So ugly, but works! (ignore the 2612 error here)
@ModelView
class ReadonlySomeModel extends SomeModel {
    @Prop({ readonly: true })
    readonly prop1!: SomeModel["prop1"];
    // ...   propN: SomeModel["propN"];
    @Prop({ readonly: true })
    readonly prop15!: SomeModel["prop15"];
}

I have to write propN: SomeModel["propN"] for every property i want to decorate in ReadonlySomeModel subclass.
And now imagine how cool it would be if decorators works with declare keyword!?
// make all properties readonly
// 🦄🌈 beauty and shine 🌈🦄
@ModelView
class ReadonlySomeModel extends SomeModel {
    @Prop({ readonly: true })
    declare readonly prop1;
    // ...   propN: SomeModel["propN"];
    @Prop({ readonly: true })
    declare readonly prop15;
}


X11 compatibility checklist

[x] xterm - working
[x] xeyes - working but not receiving mouse input with wayland backend (doesn't seem related to X11, also happens with wayland clients)
[x] env GDK_BACKEND=x11 DISPLAY=:1 transmission-gtk - working but not receiving mouse input with wayland backend (doesn't seem related to X11, also happens with wayland clients)
[ ] env GDK_BACKEND=x11 DISPLAY=:1 gnome-calculator - crashing
[ ] env DISPLAY=:1 dmenu - X protocol errors
[ ] env DISPLAY=:1 xev

The last three work on current master with drm backend.

Ticked some boxes and expanded the dmenu checklist

Is this still relevant? Can you test whatever your issues are with #331?


Update pekko-actor-typed, pekko-stream to 1.1.1

About this PR
📦 Updates

org.apache.pekko:pekko-actor-typed
org.apache.pekko:pekko-stream

from 1.0.3 to 1.1.1
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.apache.pekko" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.apache.pekko" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, version-scheme:semver-spec, commit-count:1

Superseded by #591.


expand retries and logging for status updates

pursuant to https://github.com/Kong/kubernetes-ingress-controller/pull/1537#discussion_r668830683
We currently have some fragility in the status updates code: if an error occurs after several retries we log it, but nothing else.
The purpose of this task is to investigate the best options to harden this code path and make the status updates more resilient.

This is no longer required, as #1492 completely changed the implementation and retries are now attempted based on controller queues.


Allow users to change focus without adding tag

Currently, whenever the user clicks outside of the input area or presses tab to change focus, a new tag will automatically be inserted. Is there a way to disable this? I want users to keep their current text when they click off, instead of automatically converting it. Thanks.

You can disable that, but this is a bit hacky. Hopefully you don’t see any glitch in the UI because of the last tag removal on every blur event:
let hasValue = false;

picker.input.addEventListener('input', function() {
    hasValue = !!this.textContent;
});

picker.on('blur', function(tags, count) {
    if (0 === count || !hasValue) {
        return; // Ignore if no tags available or input has no value
    }
    let lastTag = tags[count - 1];
    this.let(lastTag); // Remove the last tag
    this.input.textContent = lastTag; // Put the last tag back to the input
});


Web - Invoice-Amount not updated in invoice details after changing currency until opening invoice again

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: v9.0.53-0
Reproducible in staging?: Y
Reproducible in production?:  Y
Issue was found when executing this PR: https://github.com/Expensify/App/pull/50620
Issue reported by: Applause Internal Team
Action Performed:

Go to https://staging.new.expensify.com/
and log in
Create a workspace if there is no any
Navigate to the workspace settings > More features
Enable the Invoice option
Click on FAB > Send invoice
Select an invoice receiver
Enter the company info and send the invoice
Navigate to the invoice details
Update the currency

Expected Result:
The new amount is calculated and updated in the invoice details
Actual Result:
The new invoice amount is not updated until user goes to the invoice room and open the invoice details again.
Workaround:
Unknown
Platforms:

[ ] Android: Standalone
[ ] Android: HybridApp
[ ] Android: mWeb Chrome
[ ] iOS: Standalone
[ ] iOS: HybridApp
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
https://github.com/user-attachments/assets/e7979faa-e3c9-47b5-8f38-7a4bc19d4755

View all open jobs on GitHub

We think that this bug might be related to #vip-bills

@mallenexpensify  FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

Checking on here

Is anyone focusing on currency (or changing currency) issues holistically?  I've run across a few the past month that are a version of "do something A, change currency, currency not updated for A", ie. this one

Added [Currency] to title.  I think this is quality, let me repro this week

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

@CortneyOfstad I'm off the next week, can you please keep an eye on this issue til I'm back? Thx

Proposal
Please re-state the problem that we are trying to solve in this issue.
Invoice-Amount not updated in invoice details after changing currency until opening invoice again
What is the root cause of that problem?
When the transaction currency is not the same as the iouReport currency we are returning 0 here
https://github.com/Expensify/App/blob/8a83e2baa1c7ce7ee2c31103574937c0484854be/src/libs/actions/IOU.ts#L2478
So the iouReport.total will remain the same
https://github.com/Expensify/App/blob/8a83e2baa1c7ce7ee2c31103574937c0484854be/src/libs/actions/IOU.ts#L2637
What changes do you think we should make in order to solve the problem?

The logic inside calculateDiffAmount is totally wrong. The idea behind calculateDiffAmount is to get the iouReport total change incurred by the change of the current transaction ( as there can be multiple transactions under an iouReport) but the only time we can know the diff amount from FE is (as we can't know exchange rates between currencies) when the transaction's currency was and is the same as iouReport currency. In that case, all values are in the same currency so we can return updatedAmount - currentAmount
    if (updatedCurrency === iouReport?.currency && currentCurrency === iouReport.currency) {
        // Calculate the diff between the updated amount and the current amount if we change the amount and the currency of the transaction is the currency of the report
        return updatedAmount - currentAmount;
    }

Now what should we do for other cases. Iou report total is indeterministic state until we get the data from BE.
It doesn't matter what value we set for the iou report so we can leave it as it is and disable showing iou report until the value is fetched from the BE
We will add a pending field for the total
            ...(diff === 0 && {pendingFields: {total: 'update'}}),

and reset the pending field of total in successData and failureData
And then in the BE we will need to start pushing the new value of the iouReport total on UPDATE_MONEY_REQUEST_AMOUNT_AND_CURRENCY API
Then we will disable showing iou total via money report view when the total field is pending
https://github.com/Expensify/App/blob/8a83e2baa1c7ce7ee2c31103574937c0484854be/src/components/ReportActionItem/MoneyReportView.tsx#L49
function MoneyReportView({report, policy, isCombinedReport = false, shouldShowTotal: shouldShowTotalProp = true, shouldHideThreadDividerLine, pendingAction}: MoneyReportViewProps) {
    const shouldShowTotal = shouldShowTotalProp && !report.pendingFields?.total;

What alternative solutions did you explore? (Optional)

Proposal
Please re-state the problem that we are trying to solve in this issue.
Invoice-Amount not updated in invoice details after changing currency until opening invoice again
What is the root cause of that problem?
When the transaction currency is not the same as the iouReport currency we are returning 0 here
https://github.com/Expensify/App/blob/8a83e2baa1c7ce7ee2c31103574937c0484854be/src/libs/actions/IOU.ts#L2478
So the iouReport.total will remain the same
https://github.com/Expensify/App/blob/8a83e2baa1c7ce7ee2c31103574937c0484854be/src/libs/actions/IOU.ts#L2637
and the BE also doesn't push the iouReport.total value for UPDATE_MONEY_REQUEST_AMOUNT_AND_CURRENCY API
What changes do you think we should make in order to solve the problem?

The logic inside calculateDiffAmount is totally wrong. The idea behind calculateDiffAmount is to get the iouReport total change incurred by the change of the current transaction ( as there can be multiple transactions under an iouReport) but the only time we can know the diff amount from FE is (as we can't know exchange rates between currencies) when the transaction's currency was and is the same as iouReport currency. In that case, all values are in the same currency so we can return updatedAmount - currentAmount
    if (updatedCurrency === iouReport?.currency && currentCurrency === iouReport.currency) {
        // Calculate the diff between the updated amount and the current amount if we change the amount and the currency of the transaction is the currency of the report
        return updatedAmount - currentAmount;
    }

Now what should we do for other cases? IOUreport total is indeterministic state until we get the data from BE.
It doesn't matter what value we set for the iou report so we can leave it as it is.
We will add a pending field for the iou report total
            ...(diff === 0 && {pendingFields: {total: 'update'}}),

and reset the pending field of total in successData and failureData
And then in the BE we will need to start pushing the new value of the iouReport total on UPDATE_MONEY_REQUEST_AMOUNT_AND_CURRENCY API
Then we will start showing pending iou report total until the value is fetched from the BE. This includes The pay buttons in ReportPreview and MoneyReportHeader, the total amount we show in MoneyReportView and also the Header titles (such as someone owes ...) and LHN
Additionally we should also start thinking the payment process done before the BE replies because the payed system message we create optimistically will indicate wrong total values so we can create generic messages until the BE overrides it.
What alternative solutions did you explore? (Optional)

Proposal
Please re-state the problem that we are trying to solve in this issue.
Invoice-Amount not updated in invoice details after changing currency until opening invoice again
What is the root cause of that problem?
When the transaction currency is not the same as the iouReport currency we are returning 0 here
https://github.com/Expensify/App/blob/8a83e2baa1c7ce7ee2c31103574937c0484854be/src/libs/actions/IOU.ts#L2478
So the iouReport.total will remain the same
https://github.com/Expensify/App/blob/8a83e2baa1c7ce7ee2c31103574937c0484854be/src/libs/actions/IOU.ts#L2637
and the BE also doesn't push the iouReport.total value for UPDATE_MONEY_REQUEST_AMOUNT_AND_CURRENCY API
What changes do you think we should make in order to solve the problem?

The logic inside calculateDiffAmount is totally wrong. The idea behind calculateDiffAmount is to get the iouReport total change incurred by the change of the current transaction ( as there can be multiple transactions under an iouReport) but the only time we can know the diff amount from FE is (as we can't know exchange rates between currencies) when the transaction's currency was and is the same as iouReport currency. In that case, all values are in the same currency so we can return updatedAmount - currentAmount
       if (updatedCurrency === iouReport?.currency && currentCurrency === iouReport.currency) {
        // Calculate the diff between the updated amount and the current amount if we change the amount and the currency of the transaction is the currency of the report
        return updatedAmount - currentAmount;
    }

    return null;
}

Now what should we do for other cases? IOUreport total is indeterministic state until we get the data from BE.
It doesn't matter what value we set for the iou report so we can leave it as it is.
We will add a pending field for the iou report total
updatedMoneyRequestReport = {
            ...iouReport,
            total: iouReport.total - (diff ?? 0),
            ...(diff === null && {pendingFields: {total: 'update'}}),
        };

and reset the pending field of total in successData and failureData
And then in the BE we will need to start pushing the new value of the iouReport total on UPDATE_MONEY_REQUEST_AMOUNT_AND_CURRENCY API
Then we will start showing pending iou report total until the value is fetched from the BE. This includes The pay buttons in ReportPreview and MoneyReportHeader, the total amount we show in MoneyReportView and also the Header titles (such as someone owes ...) and LHN
Additionally we should also start thinking the payment process done before the BE replies because the payed system message we create optimistically will indicate wrong total values so we can create generic messages until the BE overrides it.
What alternative solutions did you explore? (Optional)

@sobitneupane there is a proposal above for review – thanks!

Thanks for the proposal @FitseTLT
Were you able to reproduce the issue? I am facing this issue while trying to send invoice.

Put on hold pending

#52672

Removed Help Wanted , thanks @CortneyOfstad for keeping an eye on

Thanks for the proposal, @FitseTLT.
I agree with you—the logic in calculateDiffAmount seems flawed. Could you please link the PR that introduced this logic?

It had the problem even from the start @sobitneupane

Also, could you add a screen recording of the output? I’d like to verify whether it’s sufficient to make the total field pending or not.

https://github.com/user-attachments/assets/263270c9-1e9d-458b-ac06-32142cb5ef43

@FitseTLT Thanks for the update.
I’m not in favor of using a loading indicator. Are we currently using it elsewhere?
I believe we used to display grayed-out text for offline situations.

@FitseTLT Thanks for the update.
I’m not in favor of using a loading indicator. Are we currently using it elsewhere? I believe we used to display grayed-out text for offline situations.

@sobitneupane  Currently when you create a transaction with different currency than the report on offline you are shown grayed-out old value and when turning online it will turn to loading indicator
https://github.com/user-attachments/assets/f333dd2d-c854-427d-9cc5-44f7ea8a9670
@Expensify/design We need your input here.
Currently when a user updates a transaction with a different currency from the iou report we cannot determine the report total value from Front-end because we don't have currency exchange rate information. So until the BE returns the total amount what should we display?
Options:

graying out on offline and showing loading indicator when online or always showing loading indicator
avoid showing the value until the correct total data arrives from BE

If you guys suggest other options it would be great. 👍


Scheduling problem with WhenAnyValue when applied to dependency props

Do you want to request a feature or report a bug?
bug (maybe)
What is the current behavior?
FilterTextBox is a WPF textbox. I am not binding it to a viewmodel property like I really should but just using WhenAnyValue on the text property to drive a filter.
        this.FilterTextBox.WhenAnyValue(c => c.Text)
            .Select(txt => !String.IsNullOrWhiteSpace(txt))
            .ObserveOn(RxApp.MainThreadScheduler)
            .Subscribe(filtering =>
            {
                if ( filtering )
                {
                    VisualStateManager.GoToElementState(this.Grid, "Yes", true);
                }
                else
                {
                    VisualStateManager.GoToElementState(this.Grid, "No", true);
                }
            });

In RXUI7.4 this was working. I've upgraded to RXUI8.0-alpha-94 and it fails with

It is failing somewhere within WhenAnyValue
System.Windows.Threading.Dispatcher.VerifyAccess	Unknown	No symbols loaded.
System.Windows.DependencyObject.GetValue	Unknown	No symbols loaded.
System.Windows.Controls.TextBox.Text.get	Unknown	No symbols loaded.
[Native to Managed Transition]		Annotated Frame
[Managed to Native Transition]		Annotated Frame
ReactiveUI.Reflection.TryGetValueForPropertyChain<object>	Unknown	No symbols loaded.
ReactiveUI.ObservedChangedMixin.TryGetValue<object, object>	Unknown	No symbols loaded.
ReactiveUI.ObservedChangedMixin.GetValue<object, object>	Unknown	No symbols loaded.
**ReactiveUI.ReactiveNotifyPropertyChangedMixin.nestedObservedChanges.AnonymousMethod__0	Unknown	No symbols loaded.**
System.Reactive.Linq.ObservableImpl.Select<ReactiveUI.IObservedChange<object, object>, ReactiveUI.ObservedChange<object, object>>._.OnNext	Unknown	No symbols loaded.
System.Reactive.Linq.ObservableImpl.Concat<ReactiveUI.IObservedChange<object, object>>._.OnNext	Unknown	No symbols loaded.
System.Reactive.Linq.ObservableImpl.Return<ReactiveUI.ObservedChange<object, object>>._.Invoke	Unknown	No symbols loaded.
System.Reactive.Concurrency.Scheduler.Invoke	Unknown	No symbols loaded.
System.Reactive.Concurrency.DefaultScheduler.Schedule.AnonymousMethod__0	Unknown	No symbols loaded.
System.Reactive.Concurrency.ConcurrencyAbstractionLayerImpl.QueueUserWorkItem.AnonymousMethod__0	Unknown	No symbols loaded.
System.Threading.ExecutionContext.RunInternal	Unknown	No symbols loaded.
System.Threading.ExecutionContext.Run	Unknown	No symbols loaded.
System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem	Unknown	No symbols loaded.
System.Threading.ThreadPoolWorkQueue.Dispatch	Unknown	No symbols loaded.

at the highlighted stack position

ReactiveUI.ReactiveNotifyPropertyChangedMixin.nestedObservedChanges.AnonymousMethod__0	Unknown	No symbols loaded.

I see in the local variables windows

expression	{c.Text}	System.Linq.Expressions.Expression {System.Linq.Expressions.PropertyExpression}

which matches the expression in the WhenAnyValue. Nowhere else in my code does c.Text exist.
My only guess is that some magic inside WhenAnyValue is scheduling some activity onto another thread and then trying to read the source property which, for WPF components is illegal.
What should the behaviour be
No activities on the source property should be scheduled on threads other than the thread on which WhenAnyValue was called.

Do you have reactiveui-wpf installed?

Ummmm no!! I forget that it all got split up.  I'll try that. Will probably work.
However it still seems wrong in the general case that the source property is accessed on another thread than the thread that created the WhenAnyValue call.

I don't think it is because you have the .ObserveOn(RxApp.MainThreadScheduler) in there. As per #1499, the behavior is far from ideal when the reactiveui-wpf package is not installed in a WPF app.

Yes the error has to be occurring directly within WhenAnyValue or some spawned task of it somewhere. The text  c.Text was found in the call stack of the error.
Anyway with the wpf lib installed it all works fine.

Damnit. Going to have to find a solution to this :/ sorry brad.


fix: virtual card swipe LR, RL, UD and DU

Description

Updates on virtual card swiping LR, RL, UD, and DU ( Left - Right, Right - Left, Up - Down, Down - Up respectively)
Adjusted  notification screen navbar

Type of Change

[ ] ✨ New feature (non-breaking change which adds functionality)
[x] 🛠 Bug fix (non-breaking change which fixes an issue)
[ ] ❌ Breaking change (fix or feature that would cause existing functionality to change)
[x] 🧹 Code refactor
[ ] ✅ Build configuration change
[ ] 📝 Documentation
[x] 🗑 Chore

Pre-launch Checklist

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] I read and ran all relevant commands as specififed in the Running Tests section of the Contributor Guide.
[ ] The title of the PR follows the Conventional Commits guideline
[ ] My local branch follows the naming standards in the Deepsource Branch Naming Convention or Biodiversity Branch Naming Convention
[ ] I listed at least one issue that this PR fixes in the description above.
[ ] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy,
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] I added new tests to check the change I am making, or this PR is [test-exempt].
[ ] All existing and new tests are passing.

Alright, on it


Ensure all() is not given any parameters when converted to ruby.

Currently it outputs all(nil) which throws an argument error since it doesn't take arguments.

Thanks 👍


CSS3 Speech Module Which browsers support it? See

CSS3 Speech Module
Which browsers support it?
See: http://www.w3.org/TR/2011/WD-css3-speech-20110419/

This issue was imported from Google Moderator
Moderator votes: +6
Issue added by Ozzy on 2012-05-06
To vote this issue up or down, simply include +1 or -1 in your comment.

+1

+1

+1

Updated spec link: https://drafts.csswg.org/css-speech-1/

+1

+1

+1

It's been suggested on the discussion under #1515 to merge with this issue, and close #1515.
Somehow I think it should be the other way round because #1515 is placed very high at https://caniuse.com/issue-list whereas #1240 is considerably lower. They are essentially duplicates.
If we do this, will the votes for both get summed? If so, it doesn't matter which one is the 'winner'.
Can anyone offer a compelling reason not to do this at some early opportunity?

@brennanyoung thanks for your comments. Since the feature requested in #1515 was never completed, perhaps it should stay open to discuss completing as the CSS 2 stub, as you suggested there.
Getting vote parity between this issue and #1515 shouldn't be hard, we just need 10 more +1's here.

Added #4274 to discuss.

+1

+1

+1

+1


Reduce CI builds for Swift 4 branch

I rebased the branch on top of master in #61 to save us headache in the future.


Multiple SpanNameProvider instances

I have a question about the name providers. My application has both client and server components (in separate libraries) and both are providing bindings to SpanNameProvider, since I want different handling for each. This is, of course, resulting in a Guice binding conflict.
Is there a recommended way around this? Seems like it would be useful to allow multiple name providers within one application.
(I'm using brave-jaxrs2)

I think the best way to address this right now, is to make a provider
method for the filters that use the span namers. in your provides
parameter, you can place a qualifier on each.

Ah okay, so if I understand correctly I'll need to change the filter code to use @Named where the SpanNameProvider gets injected?

yep Named or an annotation you make up that has Qualifier on it.

I'm working with brave-http and trying to understand how zipkin chooses between spanNameProviders when it is given two options (one from client side and one from server side). It appears to randomly select one of the spanNameProviders even when the same services are involved. Is there a way I can force the zipkin UI to choose the client side provider if both are present but still use the server side provider if client side wasn't present in a span?

SpanNameProvider is a type in Brave, but that's controlled by the user
doing configuration. For example, if you were using jaxrs, the
BraveClientRequestFilter and BraveContainerRequestFilter types are
something that you can configure to specify how to name the client vs
the server side.
Brave sends a patch of a span to zipkin for each side. Both sides can
include a span name, or empty string for the span name. If you want to
defer to the other side, you'd specify empty string (or "unknown").
For example, if you want the server to prefer the client's name of the
span, you can have the server's SpanNameProvider return empty string.
Zipkin's UI doesn't resolve conflicts on span name, as conflicts
happen before the UI gets a list of spans. Technically, this conflict
can only occur when a client and server span share the same id:
zipkin-server merges by ID before returning the api response, as it is
unexpected to return duplicate ids.
Here's exactly where the preference happens:
https://github.com/openzipkin/zipkin/blob/master/zipkin/src/main/java/zipkin/Span.java#L197
Hope this helps.

Brave 4.3 is out, which includes HttpTracing which configures things generically and avoids this problem as the client and server parser are different objects


docs: Provide more granular documentation

This change is

Review status: 0 of 10 files reviewed at latest revision, 25 unresolved discussions.

README.md, line 5 at r1 (raw file):

Virtlet is a Kubernetes runtime server which allows you to run VM workloads, based on QCOW2 images.

At this stage (pre-alpha), only supported way of starting Virtlet is following instructions from [Running local environment](docs/running-local-environment.md) or [Deploy using DaemonSets](contrib/deploy/README.md) documents.

Better write it this way:
At this stage (pre-alpha), it's possible to run Virtlet by following the instructions from either Running local environment or Deploy using DaemonSets documents.

README.md, line 9 at r1 (raw file):

## Getting started with Virtlet

To quickly check out virtlet usage follow instructions from [Running local environment](docs/running-local-environment.md) and [try out examples](examples/README.md) documents.

To quickly check out virtlet usage follow instructions -> To try out Virtlet follow the instructions

README.md, line 13 at r1 (raw file):

## Need any help with Virtlet?

If you will encounter any issue during Virtlet usage please look into our [issue tracker](http://github.com/Mirantis/virtlet/issues) on github. If your case is not mentioned there - please fill new issue for it.

during Virtlet usage -> when using Virtlet

README.md, line 17 at r1 (raw file):

## Contributing

Virtlet is an open source project and any contributions are welcomed. Look into [CONTRIBUTING](docs/contributing.md) document for our guide lines and further instructions how to set up dev environment.

guidelines ...
... on how to set up Virtlet development environment

README.md, line 21 at r1 (raw file):

## Licensing

Unless specifically noted, all data in this project is licensed under the [Apache 2.0 license](LICENSE).

all parts of this project are licensed under ...

docs/architecture.md, line 3 at r1 (raw file):

# Overview

Whole Virtlet solution consists of following elements:

Virtlet consists of the following components:

docs/architecture.md, line 5 at r1 (raw file):

Whole Virtlet solution consists of following elements:

* [Virtlet manager](../cmd/virtlet) - implementing CRI interface for virtualisation and images handling

implements ... for virtualization and image handling

docs/architecture.md, line 7 at r1 (raw file):

* [Virtlet manager](../cmd/virtlet) - implementing CRI interface for virtualisation and images handling
* [libvirt](http://libvirt.org) instance
* [VM wrapper](../cmd/vmwrapper) whos responsibility is to prepare environment for VM runner

which is responsible for preparing the environment for the emulator

docs/architecture.md, line 8 at r1 (raw file):

* [libvirt](http://libvirt.org) instance
* [VM wrapper](../cmd/vmwrapper) whos responsibility is to prepare environment for VM runner
* VM runner, currently [qemu](http://www.qemu-project.org/) with KVM support (with possibility to disable KVM)

VM runner -> emulator

docs/architecture.md, line 10 at r1 (raw file):

* VM runner, currently [qemu](http://www.qemu-project.org/) with KVM support (with possibility to disable KVM)

Our example setup additionally provide:

In addition to the above, our example setup provides the following:

docs/architecture.md, line 12 at r1 (raw file):

Our example setup additionally provide:

* [Images service](../contrib/deploy/image-service.yaml) which provides VM images accessible through HTTP in local cluster environment. It's only used as faciliation, because Virtlet manager can pull images through HTTP from any accessible for node place.

facilitation -> optional helper
can pull images from any HTTP server accessible from the node

docs/architecture.md, line 13 at r1 (raw file):

* [Images service](../contrib/deploy/image-service.yaml) which provides VM images accessible through HTTP in local cluster environment. It's only used as faciliation, because Virtlet manager can pull images through HTTP from any accessible for node place.
* [CRI proxy](../cmd/criproxy) which provides possibility to mix docker shim based workloads with VM based on same kubelet instance.

the possibility to mix docker-shim and VM based workloads on the same k8s node

docs/architecture.md, line 19 at r1 (raw file):

Main binary is responsible for providing API fullfiling
[CRI specification](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/container-runtime-interface-v1.md).
Basing on requests from kubelet, it:

It serves the requests from kubelet by doing the following:

docs/architecture.md, line 23 at r1 (raw file):

* controls libvirt in how to prepare VM environment (virtual drives, network interfaces, trimming resources
like RAM, CPU),
* calls [CNI plugins](https://kubernetes.io/docs/admin/network-plugins/#cni) to base setup networking setup,

to set up network environment for virtual machines

docs/architecture.md, line 24 at r1 (raw file):

like RAM, CPU),
* calls [CNI plugins](https://kubernetes.io/docs/admin/network-plugins/#cni) to base setup networking setup,
* controls libvirt to spawn VM runner using VM wrapper,

tells libvirt to call VM wrapper instead of using the emulator directly

docs/architecture.md, line 32 at r1 (raw file):

Its responsibility is to:
* reconstruct network interfaces configured by CNI plugins from container compatible to VM compatible (in network namespace),

pass the network configuration prepared by CNI plugins to the VM by means of built-in DHCP server

docs/architecture.md, line 33 at r1 (raw file):

Its responsibility is to:
* reconstruct network interfaces configured by CNI plugins from container compatible to VM compatible (in network namespace),
* spawn VM runner (currently qemu-kvm),

VM runner -> emulator

docs/architecture.md, line 35 at r1 (raw file):

* spawn VM runner (currently qemu-kvm),
* respond to DHCP queries from VM,
* signal VM runner to stop VM,

VM runner -> emulator

docs/architecture.md, line 36 at r1 (raw file):

* respond to DHCP queries from VM,
* signal VM runner to stop VM,
* reconstruct network interfaces to initial state for CNI tear down procedure.

teardown

docs/architecture.md, line 42 at r1 (raw file):

Provides a way to have on same kubelet controlled node CRI implementation and
docker shim, what is required to e.g. run on same node Virtlet and kube-proxy.
Deeper description in [this](criproxy.md) document.

See  CRI Proxy design document for more detailed description.

docs/contributing.md, line 1 at r1 (raw file):

If You want to start helping us in making virtlet better and better, take a look on:

If you want to help us make Virtlet better, please take a look at the following documents:

docs/getting-started.md, line 5 at r1 (raw file):

## Manual setup

First way of setting up Virtlet in Kubernetes environment is based on

One way

docs/getting-started.md, line 8 at r1 (raw file):

kubernetes local cluster, with kubelet pointed to runtime using CRI.
It has few depenencies which have to be installed manually.
To prepare such setup please follow [these](running-local-environment.md) instruction.

this setup ... instructions

docs/getting-started.md, line 14 at r1 (raw file):

This method looks a bit more complicated, but has wider functionality
(possibility to mix container based workloads with VM based workloads on same
node, using CRI Proxy) and is better automated than previos method.

previos -> the first

docs/getting-started.md, line 15 at r1 (raw file):

(possibility to mix container based workloads with VM based workloads on same
node, using CRI Proxy) and is better automated than previos method.
To prepare such setup please follow [these](../contrib/deploy/README.md) instruction.

this setup ... instructions

Comments from Reviewable

All suggestions accepted with one minor change.

Review status: 0 of 10 files reviewed at latest revision, 25 unresolved discussions.

README.md, line 5 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
Better write it this way:
At this stage (pre-alpha), it's possible to run Virtlet by following the instructions from either Running local environment or Deploy using DaemonSets documents.

Done.

README.md, line 9 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
To quickly check out virtlet usage follow instructions -> To try out Virtlet follow the instructions

Done.

README.md, line 13 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
during Virtlet usage -> when using Virtlet

Done.

README.md, line 17 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
guidelines ...
... on how to set up Virtlet development environment

Done.

README.md, line 21 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
all parts of this project are licensed under ...

Done.

docs/architecture.md, line 3 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
Virtlet consists of the following components:

Done.

docs/architecture.md, line 5 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
implements ... for virtualization and image handling

Done.

docs/architecture.md, line 7 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
which is responsible for preparing the environment for the emulator

Done.

docs/architecture.md, line 8 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
VM runner -> emulator

Done.

docs/architecture.md, line 10 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
In addition to the above, our example setup provides the following:

Done.

docs/architecture.md, line 12 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
facilitation -> optional helper
can pull images from any HTTP server accessible from the node

Done.

docs/architecture.md, line 13 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
the possibility to mix docker-shim and VM based workloads on the same k8s node

Done.

docs/architecture.md, line 19 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
It serves the requests from kubelet by doing the following:

Done.

docs/architecture.md, line 23 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
to set up network environment for virtual machines

Done.

docs/architecture.md, line 24 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
tells libvirt to call VM wrapper instead of using the emulator directly

Done.

docs/architecture.md, line 32 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
pass the network configuration prepared by CNI plugins to the VM by means of built-in DHCP server

Done.

docs/architecture.md, line 33 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
VM runner -> emulator

Done.

docs/architecture.md, line 35 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
VM runner -> emulator

Done.

docs/architecture.md, line 36 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
teardown

Done.

docs/architecture.md, line 42 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
See  CRI Proxy design document for more detailed description.

Done.

docs/contributing.md, line 1 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
If you want to help us make Virtlet better, please take a look at the following documents:

I used "links" instead of "documents" because of issue tracker.

docs/getting-started.md, line 5 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
One way

Done.

docs/getting-started.md, line 8 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
this setup ... instructions

Done.

docs/getting-started.md, line 14 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
previos -> the first

Done.

docs/getting-started.md, line 15 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
this setup ... instructions

Done.

Comments from Reviewable

 let's merge and fix small issues in further PRs :)

Review status: 0 of 10 files reviewed at latest revision, 25 unresolved discussions.

Comments from Reviewable


⚠ Nebulance has degraded performance

In e745864, Nebulance ($NBL) experienced degraded performance:

HTTP code: 200
Response time: 1143 ms

Resolved: Nebulance performance has improved in 6ccf516.


Feature/tech 394 integrate cypress in mpyl

📕 TECH-394 Integrate cypress suites into mpyl
Make sure that certain cypress suites get triggered for certain projects when specified in the project.yml.
🏗 Build 3 ❗ Failed with exception, started by Jorg Post
🚀  enrichChargeSessionsJob, job, kong-sync, nodeservice, sbtservice

What's up with the huge icons? :D

it's not like I changed anything related to the icons or reporting 😅


Git properties plugin fails with worktree

Known issue in com.gorylenko.gradle-git-properties failing if .git is a symlink and not a directory.

Removed from 0.8.0 due to #131