AdminServer is now the only one to send_webhook

First stab at the refactor. All the tests are passing and seems to be working fine with the toolbox.
Any event with a topic acapy::webhook::(.*) will get forwarded as a webhook. However, I'm thinking now might be a good time to improve the naming convention of these events, while still maintaining backwards compatibility with webhook topics.
i.e.  a mapping from event name to webhook topic might be:
{
  "acapy::basicmessage_received": "basicmessages",
  "acapy::ping": "ping",
  "acapy::ping_response": "ping",
  "acapy::driver_get_active_menu": "get-active-menu",
  "acapy::driver_perform_menu_action": "perform-menu-action",
  "acapy::problem_report": "problem_report",
}

However, I'm thinking now might be a good time to improve the naming convention of these events, while still maintaining backwards compatibility with webhook topics.
i.e. a mapping from event name to webhook topic might be:
{
  "acapy::basicmessage_received": "basicmessages",
  "acapy::ping": "ping",
  "acapy::ping_response": "ping",
  "acapy::driver_get_active_menu": "get-active-menu",
  "acapy::driver_perform_menu_action": "perform-menu-action",
  "acapy::problem_report": "problem_report",
}

I agree with this approach with the one suggestion that adding more "namespaces" could be nice. So acapy::basicmessage_received might be acapy::basicmessage::received.

Looking pretty good so far. Left some comments and thoughts.

Made some changes:

Brought back responder.send_webhook with a deprecation warning
Added comment to explain why if TYPE_CHECKING is used
Added EVENT_WEBHOOK_MAPPING

Question, is it ok to remove these:

BaseAdminServer.add_webhook_target - superseded by profile.settings.get("admin.webhook_urls")
BaseAdminServer.remove_webhook_target - superseded by profile.settings.get("admin.webhook_urls")
BaseAdminServer.send_webhook - Now that we have events, this seems like an implementation detail, not necessarily something all admin servers need to support.

Apologies, I've lost track of all the different conversations -- are there further changes needed after our discussion or is this ready for final review?

@dbluhm I think it's ready for final review if we are ok removing BaseAdminServer.[add/remove]_webhook_target All the tests are passing and seems to work fine with the toolbox

@dbluhm Ok, I made a PR to make those changes: #59 I did a PR so it'd be easy to diff and back out if we decide against it.


Geo-Name Abbreviations missing

The article references how the geo-name abbreviations need to be in place for the URL requests. The problem is that nowhere in the online documentation are these listed. I did finally find a lite of them from an online blog by a random user, so I cant attest to the validity of all these, but feel like we should be including this in the documentation:

Geography
Country
Region
Code

Americas
USA
Central US
CUS

Americas
USA
East US 2
EUS2

Americas
USA
East US
EUS

Americas
USA
North Central US
NCUS

Americas
USA
South Central US
NSUS

Americas
USA
West US 2
WUS2

Americas
USA
West Central US
WCUS

Americas
Azure Gov
West US,US DoD Central
WUSD

Americas
Azure Gov
US DoD East
USDE

Americas
Azure Gov
US Gov. Arizona
USGA

Americas
Azure Gov
US Gov. Iowa
USGI

Americas
Azure Gov
US Gov. Texas
USGT

Americas
Azure Gov
US Gov. Virginia
USGV

Americas
Azure Gov
US Sec East
USSE

Americas
Azure Gov
US Sec West
USSW

Americas
Canada
Canada Central
CC

Americas
Canada
Canade East
CE

Americas
Brazil
Brazil South
BS

Europe
Europe
North Europe
NE

Europe
Europe
West Europe
WE

Europe
UK
UK South
UKS

Europe
UK
UK West
UKW

Europe
Germany
Germany North
GN

Europe
Germany
Germany West Central
GWC

Europe
Switzerland
Switzerland North
SN

Europe
Switzerland
Switzerland West
SW

Europe
Norway
Norway West
NW

Europe
Norway
Norway East
NE

Asia Pacific
Asia Pacific
East Asia
EA

Asia Pacific
Asia Pacific
Southeast Asia
SA

Asia Pacific
Australia
Australia Central
AC

Asia Pacific
Australia
Australia Central 2
AC2

Asia Pacific
Australia
Australia East
AE

Asia Pacific
Australia
Australia Southeast
AS

Asia Pacific
China
China East
CE

Asia Pacific
China
China North
CN

Asia Pacific
China
China East 2
CE2

Asia Pacific
China
China North 2
CN2

Asia Pacific
India
Central India
CI

Asia Pacific
India
South India
SI

Asia Pacific
India
West India
WI

Asia Pacific
Japan
Japan East
JE

Asia Pacific
Japan
Japan West
JW

Asia Pacific
Korea
Korea Central
KC

Asia Pacific
Korea
Korea South
KS

Middle East and Africa
South Africa
South Africa North
SAN

Middle East and Africa
South Africa
South Africa West
SAW

Middle East and Africa
UAE
UAE Central
UC

Middle East and Africa
UAE
UAE North
UN

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

ID: 142ddb2b-65ef-10f4-0e68-f9af6f0e3d52
Version Independent ID: 74e33ef9-9a43-8ae6-abbd-a84f1cf91a25
Content: Recover files and folders from Azure VM backup - Azure Backup
Content Source: articles/backup/backup-azure-restore-files-from-vm.md
Service: backup
GitHub Login: @dcurwin
Microsoft Alias: dacurwin

Thanks for the feedback and bringing this to our notice . At this time we are reviewing the feedback and will update the document as appropriate .

@eransamocha Thank you for your feedback and idea to enhance our Azure documentation. Assigning this issue to our document author @dcurwin to further evaluate the feedback and see how we can enhance this document or any other document to incorporate this information.

@pvrk - Can you provide an authoritative list of regions and codes? We also need to decide where that list should be posted.
#reassign:pvrk

@eransamocha : I will present my understanding below. Please correct me if I am wrong.
This doc request stems from the need to get access to the URLs listed . Since they contain geo-name, you need geo-name, is this right?
If yes, if you are using NSG, then you can just use 'Azure backup' service tag to access these URLs. No need to remember these names/URLs.

The idea here stems directly from a customer request to figure this out. If we can provide a referenceable list it makes pulling this up easier.
It does seem logical to provide the list of geo-names abbreviations for articles like this that would require the reference – or at least a link to this chart elsewhere. The geo-names are easy enough to find, but the corresponding abbreviations, which are required for this particular call, are not obvious. The reference chart would make finding the abbreviations significantly less painful.
I am happy to set up a quick call if necessary.
--
Eran Samocha
Azure Specialist – Manufacturing and Resources
M: +1<PHONE_NUMBER>
[signature_580504661]
LinkedInhttps://www.linkedin.com/in/eran-samocha/
From: Kartik P V R<EMAIL_ADDRESS>Sent: Wednesday, September 2, 2020 12:23 AM
To: MicrosoftDocs/azure-docs<EMAIL_ADDRESS>Cc: Eran Samocha<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/azure-docs] Geo-Name Abbreviations missing (#61803)
@eransamochahttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feransamocha&data=02|01|Eran.Samocha%40microsoft.com|13dc6b768a1a4ca0b1be08d84f00513b|72f988bf86f141af91ab2d7cd011db47|1|0|637346210067278847&sdata=Ms%2B9WidpNTjmw0X%2FezH0wCo54WjK3ayqAfz%2F7XszUpo%3D&reserved=0 : I will present my understanding below. Please correct me if I am wrong.
This doc request stems from the need to get access to the URLs listed . Since they contain geo-name, you need geo-name, is this right?
If yes, if you are using NSG, then you can just use 'Azure backup' service tag to access these URLs. No need to remember these names/URLs.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F61803%23issuecomment-685306757&data=02|01|Eran.Samocha%40microsoft.com|13dc6b768a1a4ca0b1be08d84f00513b|72f988bf86f141af91ab2d7cd011db47|1|0|637346210067287711&sdata=ByVyNMMuLRLO%2FGhmg73cQ0rOcWt1lmZF4UGHBTtBdNo%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAQTXSWBRBH4ESJSIMTUO5WTSDXJEZANCNFSM4QQWDPLQ&data=02|01|Eran.Samocha%40microsoft.com|13dc6b768a1a4ca0b1be08d84f00513b|72f988bf86f141af91ab2d7cd011db47|1|0|637346210067287711&sdata=b2WL%2FM73EjbYGByd%2B4wxY4OKg0CqAyfNn25JeRbMbBA%3D&reserved=0.

@eransamocha : With regards to the statement: "The idea here stems directly from a customer request to figure this out.", I am exactly trying to figure out why? I can try to get the entire list but I want to understand where the customer has to provide these.

Specifically in the article referenced for the portion where you are pinging the individual data centers per the URL you are required to enter in the geo-name abbreviation.
In the article it gives the example of wcus for west central us, but doesn't give any more reference examples. So for customers who use any other days enter, there is no where in any of our online documentation that tells them where to go to reference what to enter there.
We should either include a table for reference or direct instructions on how to look it up on a subscription for a unique resource.
The customer came to me asking what the abbreviation would be for their 3 data centers we were looking at.
At first the customer only used the sample url link in the article. Then they did "wcus". Then I did research and found that table which I provided them to give them specific geo name abbreviations. The issue here is specific that the geo name ABNREVIATIONS are not listed anywhere. So again, my belief is that the documentation that says you need to enter in geo-name abbreviations, should then also either give a lost of all the abbreviations or at the very least give very clear instructions on how to use it.
I ran this by multiple CSAs who also agreed that this should be included in the documentation of the one thing that requires that as it is not apparent anywhere in the article where to find it o how. Also. The geo name abbreviations are not always obvious and it can be a guessing game without knowing.
Does that help clarify? Please let me know and thank you again!
--
Eran Samocha
Azure Specialist
Manufacturing and Resources
M: +1<PHONE_NUMBER>

From: Kartik P V R<EMAIL_ADDRESS>Sent: Monday, September 7, 2020 5:48:17 AM
To: MicrosoftDocs/azure-docs<EMAIL_ADDRESS>Cc: Eran Samocha<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/azure-docs] Geo-Name Abbreviations missing (#61803)
@eransamochahttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feransamocha&data=02|01|Eran.Samocha%40microsoft.com|7b791a88e581481e7d4308d8531b8810|72f988bf86f141af91ab2d7cd011db47|1|0|637350725598335644&sdata=Rb6aJPIupuiQuDfvYz9iMTl%2FYqWYjQt2MYzaDCWwyXU%3D&reserved=0 : With regards to the statement: "The idea here stems directly from a customer request to figure this out.", I am exactly trying to figure out why? I can try to get the entire list but I want to understand where the customer has to provide these.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F61803%23issuecomment-688243899&data=02|01|Eran.Samocha%40microsoft.com|7b791a88e581481e7d4308d8531b8810|72f988bf86f141af91ab2d7cd011db47|1|0|637350725598335644&sdata=7mU6EM2F62tVemYXLicLagCouEHPOdbwyO5VFVnnBt8%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAQTXSWHTYFKBXBAKIPRFPU3SES27DANCNFSM4QQWDPLQ&data=02|01|Eran.Samocha%40microsoft.com|7b791a88e581481e7d4308d8531b8810|72f988bf86f141af91ab2d7cd011db47|1|0|637350725598335644&sdata=W1WGy4tjUKVE3%2FbZYGu7gB04NGXcRR9p4KTh9oaVQG4%3D&reserved=0.

@eransamocha : Thanks and it does help me understand the scenario. However I would like to clarify once more.
The URL is required so that you can provide access to it. However, if you are using NSGs, you need not ping, get the URL and then whitelist it. All the URLs are covered under "Azure Backup" service tag. In short, if you give access via service tag in NSG, then you don't need to know URL and hence don't need geo abbreviation.
However, if you are using firewall, you may need to know the end-point. Here too, to get the geo-name abbreviation, you can just refer to the script name because it will be of the format "VMName_Geo_GUID". This is already recorded as a note just below the access requirements section. This might help you or any customer know the relevant geo-abbreviations until I can provide the list of geo-abbreviations.
Hope this helps.

I understand. This specific case was a customer using a sandbox envt to run some basic test, so that might be why they weren't able to use NSGs for the test.
Either way, I will definitely update my customer with the directions from here, but so still think the table list is useful to address that one case as well.
Thank you!
--
Eran Samocha
Azure Specialist
Manufacturing and Resources
M: +1<PHONE_NUMBER>

From: Kartik P V R<EMAIL_ADDRESS>Sent: Monday, September 7, 2020 1:21:39 PM
To: MicrosoftDocs/azure-docs<EMAIL_ADDRESS>Cc: Eran Samocha<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/azure-docs] Geo-Name Abbreviations missing (#61803)
@eransamochahttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feransamocha&data=02|01|Eran.Samocha%40microsoft.com|3425596207754180092408d8535add8b|72f988bf86f141af91ab2d7cd011db47|1|0|637350997014573135&sdata=O%2BrUv8lN5VmgOJM17I31WxxiasdEpNmDyMGyzQvXYwE%3D&reserved=0 : Thanks and it does help me understand the scenario. However I would like to clarify once more.
The URL is required so that you can provide access to it. However, if you are using NSGs, you need not ping, get the URL and then whitelist it. All the URLs are covered under "Azure Backup" service tag. In short, if you give access via service tag in NSG, then you don't need to know URL and hence don't need geo abbreviation.
However, if you are using firewall, you may need to know the end-point. Here too, to get the geo-name abbreviation, you can just refer to the script name because it will be of the format "VMName_Geo_GUID". This is already recorded as a note just below the access requirements section. This might help you or any customer know the relevant geo-abbreviations until I can provide the list of geo-abbreviations.
Hope this helps.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F61803%23issuecomment-688464575&data=02|01|Eran.Samocha%40microsoft.com|3425596207754180092408d8535add8b|72f988bf86f141af91ab2d7cd011db47|1|0|637350997014583106&sdata=%2FdCRuQKITcFioAvvVHu%2Bcmhp2mzcDWVSX9cdtDRYnyo%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAQTXSWFEUJK7FVWBBEKDVZLSEUQDHANCNFSM4QQWDPLQ&data=02|01|Eran.Samocha%40microsoft.com|3425596207754180092408d8535add8b|72f988bf86f141af91ab2d7cd011db47|1|0|637350997014583106&sdata=Er8WTHl1Ve6aRBVFUHGhP0Sm%2Bn%2FCQJx6%2B4tUletCKfI%3D&reserved=0.

@eransamocha : While I completely understand the request, it is taking time for me to gather an authoritative list and making sure that it is upto date with new regions getting added. Also, we need to decide a better location for this to be posted.
@dcurwin : Since we did provide a way for customer to get the URL based on script name, I would like to ask if this bug can be closed. I did undertake the request but preparing this list is taking more time than intended. I don't know if this bug needs to be open for that long or can we close this and internally track this to closure.

Can we at least add directions to the website on how to populate/get the geo-abbreviation in the article?
Get Outlook for Androidhttps://aka.ms/ghei36

From: Kartik P V R<EMAIL_ADDRESS>Sent: Tuesday, September 22, 2020 1:26:34 PM
To: MicrosoftDocs/azure-docs<EMAIL_ADDRESS>Cc: Eran Samocha<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/azure-docs] Geo-Name Abbreviations missing (#61803)
@eransamochahttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feransamocha&data=02|01|Eran.Samocha%40microsoft.com|8d567ee1024c4338aad208d85f250958|72f988bf86f141af91ab2d7cd011db47|1|0|637363959962612949&sdata=sR4GZHlim3V0bA3oo1g%2Bj7BgmSIq5dGHi5MV4Y%2BM%2BqM%3D&reserved=0 : While I completely understand the request, it is taking time for me to gather an authoritative list and making sure that it is upto date with new regions getting added. Also, we need to decide a better location for this to be posted.
@dcurwinhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdcurwin&data=02|01|Eran.Samocha%40microsoft.com|8d567ee1024c4338aad208d85f250958|72f988bf86f141af91ab2d7cd011db47|1|0|637363959962622947&sdata=%2FuLv31FPhh1p6teaJhEk6UtIJPS4z0KzEmdQq9UUjHM%3D&reserved=0 : Since we did provide a way for customer to get the URL based on script name, I would like to ask if this bug can be closed. I did undertake the request but preparing this list is taking more time than intended. I don't know if this bug needs to be open for that long or can we close this and internally track this to closure.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F61803%23issuecomment-696899532&data=02|01|Eran.Samocha%40microsoft.com|8d567ee1024c4338aad208d85f250958|72f988bf86f141af91ab2d7cd011db47|1|0|637363959962622947&sdata=uu72zH4AegEyzRmCIkbcUbcqZT6fCMG2Zy%2FSyE2f674%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAQTXSWGVICJGCANDUHCPSVTSHDT5VANCNFSM4QQWDPLQ&data=02|01|Eran.Samocha%40microsoft.com|8d567ee1024c4338aad208d85f250958|72f988bf86f141af91ab2d7cd011db47|1|0|637363959962632939&sdata=tMwgXTXGNaZ7%2BHb%2FGn2P9AtT6p%2B%2FgiFxZw6j6u%2FTPjA%3D&reserved=0.

@eransamocha : Apologies, but can you elaborate? Which website? The way to get the geo-abbreviations is to download the script and refer to the script name. This is documented in the current article and I have mentioned above. Am I missing anything here?

I've updated the note on the page to be more clear about how to determine the geo-name:

The script file you downloaded in step 5 above will have the geo-name in the name of the file. Use that geo-name to fill in the URL. The downloaded script name will begin with: 'VMname''geoname''GUID'.
So for example, if the script filename is ContosoVM_wcus_12345678, the geo-name is wcus and the URL would be:
https://pod01-rec2.wcus.backup.windowsazure.com

I think that should answer any questions.
If you have no further considerations, I'll go ahead and close this issue.
Thanks!

Perfect – thank you!
--
Eran Samocha
Azure Specialist – Manufacturing and Resources
M: +1<PHONE_NUMBER>
[signature_580504661]
LinkedInhttps://www.linkedin.com/in/eran-samocha/
From: David Curwin<EMAIL_ADDRESS>Sent: Wednesday, September 23, 2020 5:52 AM
To: MicrosoftDocs/azure-docs<EMAIL_ADDRESS>Cc: Eran Samocha<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/azure-docs] Geo-Name Abbreviations missing (#61803)
I've updated the note on the page to be more clear about how to determine the geo-name:
The script file you downloaded in step 5 above will have the geo-name in the name of the file. Use that geo-name to fill in the URL. The downloaded script name will begin with: 'VMname''geoname''GUID'.
So for example, if the script filename is ContosoVM_wcus_12345678, the geo-name is wcus and the URL would be:
https://pod01-rec2.wcus.backup.windowsazure.comhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpod01-rec2.wcus.backup.windowsazure.com%2F&data=02|01|Eran.Samocha%40microsoft.com|e3e370bde76946e6529f08d85faeb272|72f988bf86f141af91ab2d7cd011db47|1|0|637364551966761902&sdata=ZAlARz%2FZ1zXJVHwMx12VFZLsMV0ITM7Ndc%2BWO0b93y4%3D&reserved=0
I think that should answer any questions.
If you have no further considerations, I'll go ahead and close this issue.
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F61803%23issuecomment-697287042&data=02|01|Eran.Samocha%40microsoft.com|e3e370bde76946e6529f08d85faeb272|72f988bf86f141af91ab2d7cd011db47|1|0|637364551966761902&sdata=h93HY1EOwwwl4yABfRcv1exM3Jn38q%2B%2BE2kZC0QNqeg%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAQTXSWFOS46WIQ3YK3YZHDLSHHHM7ANCNFSM4QQWDPLQ&data=02|01|Eran.Samocha%40microsoft.com|e3e370bde76946e6529f08d85faeb272|72f988bf86f141af91ab2d7cd011db47|1|0|637364551966771895&sdata=9ZO%2F%2BT6YN58yDf4FGjkFfAM9kZ05TC71Dk2DC%2FR5Los%3D&reserved=0.

#please-close


Bug / Feature request: Time intensive custom_messages functions trigger heartbeat timeout

Prerequisites

[X] I am using the latest version of Locust
[X] I am reporting a bug, not asking a question

Description
Currently the functions of custom_messages are blocking the greenlet responsible for reading from the grpc connection between master and its workers.
When the function for a custom_message is time intensive, then it can happen that the heartbeat_timeout_checker is triggered, and therefore a worker is killed.
A solution for this issue would be to encapsulate the functions for custom_messages in a greenlet to ensure that the heartbeat and other message types locust depends on can be received all the time.
MasterRunner line of code
WorkerRunner line of code
Instead of
self.custom_messages[msg.type](environment=self.environment, msg=msg)

I would propose to to do
gevent.spawn(self.custom_messages[msg.type], environment, msg)

to ensure that it can run concurrently.
Still this solution will likely be breaking for some current users of Locust.
Another solution, which would probably take a bit more time to implement, but would be a lot better is, to implement some kind of store for the custom_messages and its functions instead of using a dictionary.
When adding a new listener a keyword like concurrent or non_blocking could tell this store to run the function as a greenlet or in a blocking way, therefore being fully backwards compatible for all users.
        environment.runner.register_message("acknowledge_users", on_acknowledge, concurrent=True)

I'm looking forward hearing from you! :)
Command line
locust -f mylocustfile.py --headless
Locustfile contents
from locust import HttpUser, between, events, task
from locust.runners import MasterRunner, WorkerRunner
import gevent

usernames = []

def setup_test_users(environment, msg, **kwargs):
    # Fired when the worker receives a message of type 'test_users'
    usernames.extend(map(lambda u: u["name"], msg.data))
    print("Before sleep")
    gevent.sleep(80)
    print("After Sleep")
    environment.runner.send_message("acknowledge_users", f"Thanks for the {len(msg.data)} users!")

def on_acknowledge(msg, **kwargs):
    # Fired when the master receives a message of type 'acknowledge_users'
    print(msg.data)

@events.init.add_listener
def on_locust_init(environment, **_kwargs):
    if not isinstance(environment.runner, MasterRunner):
        environment.runner.register_message("test_users", setup_test_users)
    if not isinstance(environment.runner, WorkerRunner):
        environment.runner.register_message("acknowledge_users", on_acknowledge)

@events.test_start.add_listener
def on_test_start(environment, **_kwargs):
    # When the test is started, evenly divides list between
    # worker nodes to ensure unique data across threads
    if not isinstance(environment.runner, WorkerRunner):
        users = []
        for i in range(environment.runner.target_user_count):
            users.append({"name": f"User{i}"})

        worker_count = environment.runner.worker_count
        chunk_size = int(len(users) / worker_count)

        for i, worker in enumerate(environment.runner.clients):
            start_index = i * chunk_size

            if i + 1 < worker_count:
                end_index = start_index + chunk_size
            else:
                end_index = len(users)

            data = users[start_index:end_index]
            environment.runner.send_message("test_users", data, worker)

class WebsiteUser(HttpUser):
    host = "http://<IP_ADDRESS>:8089"
    wait_time = between(2, 5)

    def __init__(self, parent):
        self.username = usernames.pop()
        super().__init__(parent)

    @task
    def task(self):
        print(self.username)

Python version
3.11
Locust version
2.23.1
Operating system
MacOS

Hmm. Good issue.
Maybe having a single ”custom message handler greenlet” handle events is the best, but I’m unsure. With the new distributor-pattern used by locust-plugins there can be a LOT of messages flying back and forth, so we probably dont want to start new greenlets every time.
If you have time to try implementing it I’m all ears.

So unfortunately I'm on vacation until mid of march, therefore I can't implement it until then.
If this is still open when I return, then I'll take a look at it and try to do a PR :)

Maybe having a single ”custom message handler greenlet” handle events is the best, but I’m unsure

What about using a gevent.Pool there. We could have a base setting of size one, but if needed one could adjust this value.
I know that this would still start n greenlets but we would have more control over the amount of concurrency.

I dont know what would be the best solution. It is kind of easy to workaround by just starting a greenlet inside the event handler yourself (pooled or not) so I think there's no rush to fix it. With distributors the master is often handling >1000 custom messages/s so I want to be sure we dont introduce any extra overhead for the "normal" case when the handler is fast.


Update Italian strings (installer/GUI)

@jrathlev
Please merge. Thanks.

@jrathlev
Sorry but probably is your site that don't use as should be standrad for GitHub UTF-8


Upgrade embedded Kotlin to 1.7.22

https://github.com/JetBrains/kotlin/releases/tag/v1.7.20
https://github.com/JetBrains/kotlin/releases/tag/v1.7.21
https://github.com/JetBrains/kotlin/releases/tag/v1.7.22

@bot-gradle test QFL

@bot-gradle test QFL

OK, I've already triggered the following builds for you:

QuickFeedbackLinux build

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test QFL

OK, I've already triggered the following builds for you:

QuickFeedbackLinux build

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

This is also blocked on https://github.com/gradle/gradle/issues/22853 :disappointed:

@bot-gradle test this

@bot-gradle test AST

OK, I've already triggered the following builds for you:

AllSmokeTestsPullRequestFeedback build

@bot-gradle test APT

OK, I've already triggered the following builds for you:

AllPerformanceTestsReadyForRelease build

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test and merge

OK, I've already triggered a build for you.

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

Pre-tested commit build failed.

OK, I've already triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test and merge

OK, I've already triggered a build for you.


Versions: Add CNI plugins version

The cni-plugins commit will be used to build that specific
version on the CI, instead of using master.
Fixes #407.
Signed-off-by: Salvador Fuentes<EMAIL_ADDRESS>

lgtm.

lgtm


Feature Request: Improve Updatecli Report

Is your feature request related to a problem?
As the number of Pipeline that Updatecli handles grow, it gets more and more difficult to visualize what changed.
At the moment we have report such as:
REPORTS:

✔ Bump venom version:
	Source:
		✔ [latestVersion] Get latest Venom release (kind: githubrelease)
	Target:
		✔ [goWorkflow] Bump Venom version to v1.1.0 (kind: file)

This report are very minimal, rely on stage title instead of what was effectively changed.
I am experimenting with something like:
REPORTS:

✔ Bump venom version:
	Source:
		✔ [latestVersion] Get latest Venom release (kind: githubrelease)
	Target:
		✔ [goWorkflow] Bump Venom version to v1.1.0
			=> all contents from 'file' and 'files' combined already up to date

Solution you'd like
I would like to be able to export a report with the following data

[ ] date: Date of pipeline execution
[x] source: The result of a source execution https://github.com/updatecli/updatecli/pull/1304
[x] condition: The result of a condition execution  https://github.com/updatecli/updatecli/pull/1314
[x] target: The result of a target execution https://github.com/updatecli/updatecli/pull/1296

Alternatives you've considered

Export the report to a http endpoint such as updatemonitor.updatecli.io
Export the report to a file

Anything else?
No response

This is still ongoing, I am experimenting with a new project named udash
I currently have a demo environment deployed on https://app.updatecli.io


Listing Creation: Silent Failure With Announcement Listing Type

When attempting to create a listing, the "Next" button fails silently if "Announcement" is selected as the listing type. The console produces Error: [React Intl] An id must be provided to format a message..

Fixed by https://github.com/OriginProtocol/origin-dapp/pull/558


Fix carousel RTL and refactor code, fix rtl swipe issues

It fixes rtl next/previous functionality,
it separates directions from order, and transfers all the rtl and direction responsibility on the _slide method
Preview: https://deploy-preview-32913--twbs-bootstrap.netlify.app/docs/5.0/components/carousel/

Looks good to me but this reminds me that we don't have tests for this code.
Also, we already have next() and prev(), perhaps we could leverage them instead of adding new functions?

I did the  change you propose
Cause of RTL support I would prefer to keep left/right against next/previous

if vertical carousel #32988 is going to be merged, I think the left/right is better to be independent of the next/prev

I'm not sure about #32988; it lacks tests docs and everything. Either way, can you please add a few tests to ensure that when isRTL is true, the right this is done?

@XhmikosR any help how to mock the isRTL import? I was not able to find any way, so for now I used it as a component method

@GeoSot You can make isRTL a function in the util if you need to check the dir in the runtime :thinking:

Hi, I made #33076 before noticing this PR. Would appreciate it if you take a look.

I think #32446 should be merged first :thinking:

@rohit2sharma95  I added the checks.
You will find two new methods directionToOrder and orderToDirection
Both of them, maybe would have to be extracted in future to support other modules with right/left directions

@XhmikosR Will leave for you to squash as you like :)


[BUG] [Playwright] Lambda /tmp fills up quickly

Environment

@sparticuz/chromium Version: ^121.0.0
playwright / playwright-core Version: 1.41.2
Node.js Version:  20
Lambda / GCF Runtime:  nodejs20.x

Expected Behavior

Should be able to request a await page.goto(c.req.query('url')); indefinitely.
Current Behavior

With 1GB ephemeral storage allocated to the Lambda, the /tmp spaces fills up after about 30-40 invocations and every subsequent request fails with:
ERROR   Unexpected Error: page.goto: net::ERR_INSUFFICIENT_RESOURCES at https://www.google.com/
Steps to Reproduce
Create a basic lambda that runs the following code...
const { Hono } = require('hono');
const playwright = require('playwright-core');
const { stream } = require('hono/streaming');
const fs = require('fs');
const { exec } = require('child_process');
const util = require('util');
const execProm = util.promisify(exec);

function routes({ args, executablePath, headless }) {
  const app = new Hono();

  app.get('/', async (c) => {
    let browser;
    try {
      browser = await playwright.chromium.launch({
        args,
        executablePath: await executablePath,
        headless,
      });
      const page = await browser.newPage();

      console.log('Navigating to:', c.req.query('url'));
      const response = await page.goto(c.req.query('url'));
      const title = await page.title();
      console.log('Response status:', response?.status(), title);
    } catch (error) {
      console.error('Unexpected Error:', error);
      const message = error.message || 'Unexpected Error';
      return c.text(message, 500);
    } finally {
      console.log('Closing the browser...');
      await browser?.close();
    }
    c.res.headers.set('content-type', 'text/plain');
    return stream(c, async (stream) => {
      stream.onAbort(() => {
        console.log('Stream aborted!');
      });

      await stream.write(`Hello from Lambda Service! ${await getTmpDfOutput()}`);
      console.log(await getTmpDfOutput());
    });
  });

  return { app };
}

async function getTmpDfOutput() {
  // log out the output of df -h /tmp
  const { stdout } = await execProm('df -h /tmp 2>&1');
  return `df -h /tmp:\n\n${stdout}`;
}

module.exports = routes;

LOGS
INIT_START Runtime Version: nodejs:20.v15 Runtime Version ARN: xxxxxxxx
START RequestId: 9465ec3b-4c58-4f71-8d6e-76fc3784240d Version: $LATEST
2024-02-17T23:48:21.236Z  9465ec3b-4c58-4f71-8d6e-76fc3784240d    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:21.963Z  9465ec3b-4c58-4f71-8d6e-76fc3784240d    INFO    Response status: 200 Google
2024-02-17T23:48:21.964Z  9465ec3b-4c58-4f71-8d6e-76fc3784240d    INFO    Closing the browser...
2024-02-17T23:48:22.338Z  9465ec3b-4c58-4f71-8d6e-76fc3784240d    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G  310M  715M  31% /tmp
END RequestId: 9465ec3b-4c58-4f71-8d6e-76fc3784240d
REPORT RequestId: 9465ec3b-4c58-4f71-8d6e-76fc3784240d    Duration: 2515.31 ms    Billed Duration: 2516 ms        Memory Size: 8192 MB    Max Memory Used: 675 MB        Init Duration: 505.31 ms
START RequestId: 22500773-957f-4247-96c1-508936bcc173 Version: $LATEST
2024-02-17T23:48:22.552Z  22500773-957f-4247-96c1-508936bcc173    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:23.274Z  22500773-957f-4247-96c1-508936bcc173    INFO    Response status: 200 Google
2024-02-17T23:48:23.275Z  22500773-957f-4247-96c1-508936bcc173    INFO    Closing the browser...
2024-02-17T23:48:23.435Z  22500773-957f-4247-96c1-508936bcc173    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G  310M  715M  31% /tmp
END RequestId: 22500773-957f-4247-96c1-508936bcc173
REPORT RequestId: 22500773-957f-4247-96c1-508936bcc173    Duration: 951.38 ms     Billed Duration: 952 ms Memory Size: 8192 MB    Max Memory Used: 683 MB
START RequestId: 90cc4876-cadc-4427-949d-b26957f18b7c Version: $LATEST
2024-02-17T23:48:23.614Z  90cc4876-cadc-4427-949d-b26957f18b7c    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:24.279Z  90cc4876-cadc-4427-949d-b26957f18b7c    INFO    Response status: 200 Google
2024-02-17T23:48:24.279Z  90cc4876-cadc-4427-949d-b26957f18b7c    INFO    Closing the browser...
2024-02-17T23:48:24.448Z  90cc4876-cadc-4427-949d-b26957f18b7c    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G  310M  715M  31% /tmp
END RequestId: 90cc4876-cadc-4427-949d-b26957f18b7c
REPORT RequestId: 90cc4876-cadc-4427-949d-b26957f18b7c    Duration: 895.51 ms     Billed Duration: 896 ms Memory Size: 8192 MB    Max Memory Used: 686 MB
START RequestId: 747ed449-68c6-4752-afc5-099b0663c8cd Version: $LATEST
2024-02-17T23:48:24.629Z  747ed449-68c6-4752-afc5-099b0663c8cd    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:25.305Z  747ed449-68c6-4752-afc5-099b0663c8cd    INFO    Response status: 200 Google
2024-02-17T23:48:25.306Z  747ed449-68c6-4752-afc5-099b0663c8cd    INFO    Closing the browser...
2024-02-17T23:48:25.614Z  747ed449-68c6-4752-afc5-099b0663c8cd    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G  436M  590M  43% /tmp
END RequestId: 747ed449-68c6-4752-afc5-099b0663c8cd
REPORT RequestId: 747ed449-68c6-4752-afc5-099b0663c8cd    Duration: 1047.99 ms    Billed Duration: 1048 ms        Memory Size: 8192 MB    Max Memory Used: 807 MB
START RequestId: 95e26a17-6a5a-414e-8777-7a234ff3d7df Version: $LATEST
2024-02-17T23:48:25.799Z  95e26a17-6a5a-414e-8777-7a234ff3d7df    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:26.760Z  95e26a17-6a5a-414e-8777-7a234ff3d7df    INFO    Response status: 200 Google
2024-02-17T23:48:26.761Z  95e26a17-6a5a-414e-8777-7a234ff3d7df    INFO    Closing the browser...
2024-02-17T23:48:27.075Z  95e26a17-6a5a-414e-8777-7a234ff3d7df    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G  561M  465M  55% /tmp
END RequestId: 95e26a17-6a5a-414e-8777-7a234ff3d7df
REPORT RequestId: 95e26a17-6a5a-414e-8777-7a234ff3d7df    Duration: 1333.33 ms    Billed Duration: 1334 ms        Memory Size: 8192 MB    Max Memory Used: 938 MB
START RequestId: 8466ab22-517b-474e-9b70-364eb005696c Version: $LATEST
2024-02-17T23:48:27.259Z  8466ab22-517b-474e-9b70-364eb005696c    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:27.916Z  8466ab22-517b-474e-9b70-364eb005696c    INFO    Response status: 200 Google
2024-02-17T23:48:27.917Z  8466ab22-517b-474e-9b70-364eb005696c    INFO    Closing the browser...
2024-02-17T23:48:28.110Z  8466ab22-517b-474e-9b70-364eb005696c    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G  561M  465M  55% /tmp
END RequestId: 8466ab22-517b-474e-9b70-364eb005696c
REPORT RequestId: 8466ab22-517b-474e-9b70-364eb005696c    Duration: 918.28 ms     Billed Duration: 919 ms Memory Size: 8192 MB    Max Memory Used: 948 MB
START RequestId: 431440fa-f411-4965-9d53-16a293bc635e Version: $LATEST
2024-02-17T23:48:28.299Z  431440fa-f411-4965-9d53-16a293bc635e    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:28.944Z  431440fa-f411-4965-9d53-16a293bc635e    INFO    Response status: 200 Google
2024-02-17T23:48:28.944Z  431440fa-f411-4965-9d53-16a293bc635e    INFO    Closing the browser...
2024-02-17T23:48:29.162Z  431440fa-f411-4965-9d53-16a293bc635e    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G  561M  465M  55% /tmp
END RequestId: 431440fa-f411-4965-9d53-16a293bc635e
REPORT RequestId: 431440fa-f411-4965-9d53-16a293bc635e    Duration: 918.93 ms     Billed Duration: 919 ms Memory Size: 8192 MB    Max Memory Used: 950 MB
START RequestId: b5c548e5-903f-435f-9d0b-cc3b05b148d6 Version: $LATEST
2024-02-17T23:48:29.334Z  b5c548e5-903f-435f-9d0b-cc3b05b148d6    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:30.002Z  b5c548e5-903f-435f-9d0b-cc3b05b148d6    INFO    Response status: 200 Google
2024-02-17T23:48:30.002Z  b5c548e5-903f-435f-9d0b-cc3b05b148d6    INFO    Closing the browser...
2024-02-17T23:48:30.147Z  b5c548e5-903f-435f-9d0b-cc3b05b148d6    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G  561M  465M  55% /tmp
END RequestId: b5c548e5-903f-435f-9d0b-cc3b05b148d6
REPORT RequestId: b5c548e5-903f-435f-9d0b-cc3b05b148d6    Duration: 872.00 ms     Billed Duration: 873 ms Memory Size: 8192 MB    Max Memory Used: 950 MB
START RequestId: 47bb2514-5412-48d2-8a15-e7fee7c78a61 Version: $LATEST
2024-02-17T23:48:30.368Z  47bb2514-5412-48d2-8a15-e7fee7c78a61    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:31.026Z  47bb2514-5412-48d2-8a15-e7fee7c78a61    INFO    Response status: 200 Google
2024-02-17T23:48:31.026Z  47bb2514-5412-48d2-8a15-e7fee7c78a61    INFO    Closing the browser...
2024-02-17T23:48:31.569Z  47bb2514-5412-48d2-8a15-e7fee7c78a61    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G  689M  336M  68% /tmp
END RequestId: 47bb2514-5412-48d2-8a15-e7fee7c78a61
REPORT RequestId: 47bb2514-5412-48d2-8a15-e7fee7c78a61    Duration: 1304.02 ms    Billed Duration: 1305 ms        Memory Size: 8192 MB    Max Memory Used: 1076 MB
START RequestId: 411b9ce6-ca95-4666-8159-c7bb39812efa Version: $LATEST
2024-02-17T23:48:31.760Z  411b9ce6-ca95-4666-8159-c7bb39812efa    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:32.433Z  411b9ce6-ca95-4666-8159-c7bb39812efa    INFO    Response status: 200 Google
2024-02-17T23:48:32.433Z  411b9ce6-ca95-4666-8159-c7bb39812efa    INFO    Closing the browser...
2024-02-17T23:48:32.602Z  411b9ce6-ca95-4666-8159-c7bb39812efa    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G  689M  336M  68% /tmp
END RequestId: 411b9ce6-ca95-4666-8159-c7bb39812efa
REPORT RequestId: 411b9ce6-ca95-4666-8159-c7bb39812efa    Duration: 916.92 ms     Billed Duration: 917 ms Memory Size: 8192 MB    Max Memory Used: 1083 MB
START RequestId: 80044812-03db-443f-8f8b-80716bb4686f Version: $LATEST
2024-02-17T23:48:32.771Z  80044812-03db-443f-8f8b-80716bb4686f    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:33.464Z  80044812-03db-443f-8f8b-80716bb4686f    INFO    Response status: 200 Google
2024-02-17T23:48:33.464Z  80044812-03db-443f-8f8b-80716bb4686f    INFO    Closing the browser...
2024-02-17T23:48:33.832Z  80044812-03db-443f-8f8b-80716bb4686f    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G  818M  207M  80% /tmp
END RequestId: 80044812-03db-443f-8f8b-80716bb4686f
REPORT RequestId: 80044812-03db-443f-8f8b-80716bb4686f    Duration: 1115.46 ms    Billed Duration: 1116 ms        Memory Size: 8192 MB    Max Memory Used: 1210 MB
START RequestId: 4fe9f769-ecca-427b-be85-618237b78c72 Version: $LATEST
2024-02-17T23:48:34.007Z  4fe9f769-ecca-427b-be85-618237b78c72    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:34.693Z  4fe9f769-ecca-427b-be85-618237b78c72    INFO    Response status: 200 Google
2024-02-17T23:48:34.693Z  4fe9f769-ecca-427b-be85-618237b78c72    INFO    Closing the browser...
2024-02-17T23:48:34.866Z  4fe9f769-ecca-427b-be85-618237b78c72    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G  818M  207M  80% /tmp
END RequestId: 4fe9f769-ecca-427b-be85-618237b78c72
REPORT RequestId: 4fe9f769-ecca-427b-be85-618237b78c72    Duration: 919.01 ms     Billed Duration: 920 ms Memory Size: 8192 MB    Max Memory Used: 1217 MB
START RequestId: 35c8cbc9-1ffc-4fa9-988a-f83c8f05080d Version: $LATEST
2024-02-17T23:48:35.040Z  35c8cbc9-1ffc-4fa9-988a-f83c8f05080d    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:35.731Z  35c8cbc9-1ffc-4fa9-988a-f83c8f05080d    INFO    Response status: 200 Google
2024-02-17T23:48:35.732Z  35c8cbc9-1ffc-4fa9-988a-f83c8f05080d    INFO    Closing the browser...
2024-02-17T23:48:35.891Z  35c8cbc9-1ffc-4fa9-988a-f83c8f05080d    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G  818M  207M  80% /tmp
END RequestId: 35c8cbc9-1ffc-4fa9-988a-f83c8f05080d
REPORT RequestId: 35c8cbc9-1ffc-4fa9-988a-f83c8f05080d    Duration: 909.90 ms     Billed Duration: 910 ms Memory Size: 8192 MB    Max Memory Used: 1217 MB
START RequestId: 7631534f-2cd7-4d4e-8c02-d4fb35f3c362 Version: $LATEST
2024-02-17T23:48:36.073Z  7631534f-2cd7-4d4e-8c02-d4fb35f3c362    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:36.770Z  7631534f-2cd7-4d4e-8c02-d4fb35f3c362    INFO    Response status: 200 Google
2024-02-17T23:48:36.770Z  7631534f-2cd7-4d4e-8c02-d4fb35f3c362    INFO    Closing the browser...
2024-02-17T23:48:37.200Z  7631534f-2cd7-4d4e-8c02-d4fb35f3c362    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G  947M   79M  93% /tmp
END RequestId: 7631534f-2cd7-4d4e-8c02-d4fb35f3c362
REPORT RequestId: 7631534f-2cd7-4d4e-8c02-d4fb35f3c362    Duration: 1196.90 ms    Billed Duration: 1197 ms        Memory Size: 8192 MB    Max Memory Used: 1342 MB
START RequestId: 8001a0e8-735c-468f-876f-670890cc1f38 Version: $LATEST
2024-02-17T23:48:37.385Z  8001a0e8-735c-468f-876f-670890cc1f38    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:38.039Z  8001a0e8-735c-468f-876f-670890cc1f38    INFO    Response status: 200 Google
2024-02-17T23:48:38.039Z  8001a0e8-735c-468f-876f-670890cc1f38    INFO    Closing the browser...
2024-02-17T23:48:38.371Z  8001a0e8-735c-468f-876f-670890cc1f38    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G  996M   29M  98% /tmp
END RequestId: 8001a0e8-735c-468f-876f-670890cc1f38
REPORT RequestId: 8001a0e8-735c-468f-876f-670890cc1f38    Duration: 1056.76 ms    Billed Duration: 1057 ms        Memory Size: 8192 MB    Max Memory Used: 1394 MB
START RequestId: 58ab6592-3f99-45a5-ae21-1ab18d5dd2be Version: $LATEST
2024-02-17T23:48:38.541Z  58ab6592-3f99-45a5-ae21-1ab18d5dd2be    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:39.192Z  58ab6592-3f99-45a5-ae21-1ab18d5dd2be    INFO    Response status: 200 Google
2024-02-17T23:48:39.192Z  58ab6592-3f99-45a5-ae21-1ab18d5dd2be    INFO    Closing the browser...
2024-02-17T23:48:39.243Z  58ab6592-3f99-45a5-ae21-1ab18d5dd2be    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G  996M   29M  98% /tmp
END RequestId: 58ab6592-3f99-45a5-ae21-1ab18d5dd2be
REPORT RequestId: 58ab6592-3f99-45a5-ae21-1ab18d5dd2be    Duration: 758.63 ms     Billed Duration: 759 ms Memory Size: 8192 MB    Max Memory Used: 1398 MB
START RequestId: f129a3c4-f7d8-457b-8acd-c85e96790f6b Version: $LATEST
2024-02-17T23:48:39.411Z  f129a3c4-f7d8-457b-8acd-c85e96790f6b    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:40.106Z  f129a3c4-f7d8-457b-8acd-c85e96790f6b    INFO    Response status: 200 Google
2024-02-17T23:48:40.106Z  f129a3c4-f7d8-457b-8acd-c85e96790f6b    INFO    Closing the browser...
2024-02-17T23:48:40.167Z  f129a3c4-f7d8-457b-8acd-c85e96790f6b    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G  998M   27M  98% /tmp
END RequestId: f129a3c4-f7d8-457b-8acd-c85e96790f6b
REPORT RequestId: f129a3c4-f7d8-457b-8acd-c85e96790f6b    Duration: 812.32 ms     Billed Duration: 813 ms Memory Size: 8192 MB    Max Memory Used: 1398 MB
START RequestId: fbb36ab1-e362-4827-8fd1-9d1d89811d92 Version: $LATEST
2024-02-17T23:48:40.344Z  fbb36ab1-e362-4827-8fd1-9d1d89811d92    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:41.023Z  fbb36ab1-e362-4827-8fd1-9d1d89811d92    INFO    Response status: 200 Google
2024-02-17T23:48:41.024Z  fbb36ab1-e362-4827-8fd1-9d1d89811d92    INFO    Closing the browser...
2024-02-17T23:48:41.072Z  fbb36ab1-e362-4827-8fd1-9d1d89811d92    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1000M   25M  98% /tmp
END RequestId: fbb36ab1-e362-4827-8fd1-9d1d89811d92
REPORT RequestId: fbb36ab1-e362-4827-8fd1-9d1d89811d92    Duration: 790.47 ms     Billed Duration: 791 ms Memory Size: 8192 MB    Max Memory Used: 1398 MB
START RequestId: 178f7cf2-4987-4a75-aa77-2f4c9b8040a2 Version: $LATEST
2024-02-17T23:48:41.252Z  178f7cf2-4987-4a75-aa77-2f4c9b8040a2    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:41.835Z  178f7cf2-4987-4a75-aa77-2f4c9b8040a2    INFO    Response status: 200 Google
2024-02-17T23:48:41.835Z  178f7cf2-4987-4a75-aa77-2f4c9b8040a2    INFO    Closing the browser...
2024-02-17T23:48:41.870Z  178f7cf2-4987-4a75-aa77-2f4c9b8040a2    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1000M   25M  98% /tmp
END RequestId: 178f7cf2-4987-4a75-aa77-2f4c9b8040a2
REPORT RequestId: 178f7cf2-4987-4a75-aa77-2f4c9b8040a2    Duration: 683.64 ms     Billed Duration: 684 ms Memory Size: 8192 MB    Max Memory Used: 1398 MB
START RequestId: 46dbb121-58ab-44c6-8cc9-f7848f056dfa Version: $LATEST
2024-02-17T23:48:42.053Z  46dbb121-58ab-44c6-8cc9-f7848f056dfa    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:42.628Z  46dbb121-58ab-44c6-8cc9-f7848f056dfa    INFO    Response status: 200 Google
2024-02-17T23:48:42.629Z  46dbb121-58ab-44c6-8cc9-f7848f056dfa    INFO    Closing the browser...
2024-02-17T23:48:42.870Z  46dbb121-58ab-44c6-8cc9-f7848f056dfa    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1000M   25M  98% /tmp
END RequestId: 46dbb121-58ab-44c6-8cc9-f7848f056dfa
REPORT RequestId: 46dbb121-58ab-44c6-8cc9-f7848f056dfa    Duration: 885.21 ms     Billed Duration: 886 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: 3f360bd6-c211-4f4d-81a5-cac136aa4857 Version: $LATEST
2024-02-17T23:48:43.038Z  3f360bd6-c211-4f4d-81a5-cac136aa4857    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:43.875Z  3f360bd6-c211-4f4d-81a5-cac136aa4857    INFO    Response status: 200 Google
2024-02-17T23:48:43.876Z  3f360bd6-c211-4f4d-81a5-cac136aa4857    INFO    Closing the browser...
2024-02-17T23:48:43.990Z  3f360bd6-c211-4f4d-81a5-cac136aa4857    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1000M   25M  98% /tmp
END RequestId: 3f360bd6-c211-4f4d-81a5-cac136aa4857
REPORT RequestId: 3f360bd6-c211-4f4d-81a5-cac136aa4857    Duration: 1010.47 ms    Billed Duration: 1011 ms        Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: ac0356fb-9bc5-4ca8-9908-28b53b9eb452 Version: $LATEST
2024-02-17T23:48:44.155Z  ac0356fb-9bc5-4ca8-9908-28b53b9eb452    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:44.837Z  ac0356fb-9bc5-4ca8-9908-28b53b9eb452    INFO    Response status: 200 Google
2024-02-17T23:48:44.837Z  ac0356fb-9bc5-4ca8-9908-28b53b9eb452    INFO    Closing the browser...
2024-02-17T23:48:44.879Z  ac0356fb-9bc5-4ca8-9908-28b53b9eb452    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1002M   23M  98% /tmp
END RequestId: ac0356fb-9bc5-4ca8-9908-28b53b9eb452
REPORT RequestId: ac0356fb-9bc5-4ca8-9908-28b53b9eb452    Duration: 778.45 ms     Billed Duration: 779 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: fe0f5431-7d26-4082-9e47-fd0565bda65c Version: $LATEST
2024-02-17T23:48:45.049Z  fe0f5431-7d26-4082-9e47-fd0565bda65c    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:45.646Z  fe0f5431-7d26-4082-9e47-fd0565bda65c    INFO    Response status: 200 Google
2024-02-17T23:48:45.646Z  fe0f5431-7d26-4082-9e47-fd0565bda65c    INFO    Closing the browser...
2024-02-17T23:48:45.695Z  fe0f5431-7d26-4082-9e47-fd0565bda65c    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1004M   21M  98% /tmp
END RequestId: fe0f5431-7d26-4082-9e47-fd0565bda65c
REPORT RequestId: fe0f5431-7d26-4082-9e47-fd0565bda65c    Duration: 706.68 ms     Billed Duration: 707 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: 7aea8121-2a46-428b-9338-36931f6813b0 Version: $LATEST
2024-02-17T23:48:45.868Z  7aea8121-2a46-428b-9338-36931f6813b0    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:46.356Z  7aea8121-2a46-428b-9338-36931f6813b0    INFO    Response status: 200 Google
2024-02-17T23:48:46.356Z  7aea8121-2a46-428b-9338-36931f6813b0    INFO    Closing the browser...
2024-02-17T23:48:46.514Z  7aea8121-2a46-428b-9338-36931f6813b0    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1004M   21M  98% /tmp
END RequestId: 7aea8121-2a46-428b-9338-36931f6813b0
REPORT RequestId: 7aea8121-2a46-428b-9338-36931f6813b0    Duration: 708.33 ms     Billed Duration: 709 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: 410cc0cb-8a50-4cab-aac9-c8ffa52eb13c Version: $LATEST
2024-02-17T23:48:46.687Z  410cc0cb-8a50-4cab-aac9-c8ffa52eb13c    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:47.165Z  410cc0cb-8a50-4cab-aac9-c8ffa52eb13c    INFO    Response status: 200 Google
2024-02-17T23:48:47.165Z  410cc0cb-8a50-4cab-aac9-c8ffa52eb13c    INFO    Closing the browser...
2024-02-17T23:48:47.322Z  410cc0cb-8a50-4cab-aac9-c8ffa52eb13c    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1004M   21M  98% /tmp
END RequestId: 410cc0cb-8a50-4cab-aac9-c8ffa52eb13c
REPORT RequestId: 410cc0cb-8a50-4cab-aac9-c8ffa52eb13c    Duration: 696.85 ms     Billed Duration: 697 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: ccf19014-0629-4f75-8024-1d8db1fad839 Version: $LATEST
2024-02-17T23:48:47.495Z  ccf19014-0629-4f75-8024-1d8db1fad839    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:48.003Z  ccf19014-0629-4f75-8024-1d8db1fad839    INFO    Response status: 200 Google
2024-02-17T23:48:48.003Z  ccf19014-0629-4f75-8024-1d8db1fad839    INFO    Closing the browser...
2024-02-17T23:48:48.166Z  ccf19014-0629-4f75-8024-1d8db1fad839    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1004M   21M  98% /tmp
END RequestId: ccf19014-0629-4f75-8024-1d8db1fad839
REPORT RequestId: ccf19014-0629-4f75-8024-1d8db1fad839    Duration: 735.81 ms     Billed Duration: 736 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: 1bc2daf7-709c-4ed4-97ee-96a49a9cb053 Version: $LATEST
2024-02-17T23:48:48.348Z  1bc2daf7-709c-4ed4-97ee-96a49a9cb053    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:48.881Z  1bc2daf7-709c-4ed4-97ee-96a49a9cb053    INFO    Response status: 200 Google
2024-02-17T23:48:48.881Z  1bc2daf7-709c-4ed4-97ee-96a49a9cb053    INFO    Closing the browser...
2024-02-17T23:48:49.002Z  1bc2daf7-709c-4ed4-97ee-96a49a9cb053    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1004M   21M  98% /tmp
END RequestId: 1bc2daf7-709c-4ed4-97ee-96a49a9cb053
REPORT RequestId: 1bc2daf7-709c-4ed4-97ee-96a49a9cb053    Duration: 722.28 ms     Billed Duration: 723 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: 438ee63f-01b1-4884-855e-1c0738de1416 Version: $LATEST
2024-02-17T23:48:49.179Z  438ee63f-01b1-4884-855e-1c0738de1416    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:49.802Z  438ee63f-01b1-4884-855e-1c0738de1416    INFO    Response status: 200 Google
2024-02-17T23:48:49.802Z  438ee63f-01b1-4884-855e-1c0738de1416    INFO    Closing the browser...
2024-02-17T23:48:49.839Z  438ee63f-01b1-4884-855e-1c0738de1416    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1004M   21M  98% /tmp
END RequestId: 438ee63f-01b1-4884-855e-1c0738de1416
REPORT RequestId: 438ee63f-01b1-4884-855e-1c0738de1416    Duration: 722.41 ms     Billed Duration: 723 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: 26a1bf1f-932b-437e-8349-d37ca06c275c Version: $LATEST
2024-02-17T23:48:50.006Z  26a1bf1f-932b-437e-8349-d37ca06c275c    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:50.481Z  26a1bf1f-932b-437e-8349-d37ca06c275c    INFO    Response status: 200 Google
2024-02-17T23:48:50.481Z  26a1bf1f-932b-437e-8349-d37ca06c275c    INFO    Closing the browser...
2024-02-17T23:48:50.639Z  26a1bf1f-932b-437e-8349-d37ca06c275c    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1004M   21M  98% /tmp
END RequestId: 26a1bf1f-932b-437e-8349-d37ca06c275c
REPORT RequestId: 26a1bf1f-932b-437e-8349-d37ca06c275c    Duration: 687.86 ms     Billed Duration: 688 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: e1f28509-672d-4833-b2db-b521bb4df170 Version: $LATEST
2024-02-17T23:48:50.807Z  e1f28509-672d-4833-b2db-b521bb4df170    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:51.376Z  e1f28509-672d-4833-b2db-b521bb4df170    INFO    Response status: 200 Google
2024-02-17T23:48:51.376Z  e1f28509-672d-4833-b2db-b521bb4df170    INFO    Closing the browser...
2024-02-17T23:48:51.646Z  e1f28509-672d-4833-b2db-b521bb4df170    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1004M   21M  98% /tmp
END RequestId: e1f28509-672d-4833-b2db-b521bb4df170
REPORT RequestId: e1f28509-672d-4833-b2db-b521bb4df170    Duration: 897.28 ms     Billed Duration: 898 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: 28ce27d6-12eb-491c-83cd-5991dc57eaca Version: $LATEST
2024-02-17T23:48:51.800Z  28ce27d6-12eb-491c-83cd-5991dc57eaca    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:52.409Z  28ce27d6-12eb-491c-83cd-5991dc57eaca    INFO    Response status: 200 Google
2024-02-17T23:48:52.409Z  28ce27d6-12eb-491c-83cd-5991dc57eaca    INFO    Closing the browser...
2024-02-17T23:48:52.448Z  28ce27d6-12eb-491c-83cd-5991dc57eaca    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1004M   21M  98% /tmp
END RequestId: 28ce27d6-12eb-491c-83cd-5991dc57eaca
REPORT RequestId: 28ce27d6-12eb-491c-83cd-5991dc57eaca    Duration: 694.38 ms     Billed Duration: 695 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: c45a4001-3de5-448e-846a-cdb97f53b51d Version: $LATEST
2024-02-17T23:48:52.620Z  c45a4001-3de5-448e-846a-cdb97f53b51d    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:53.110Z  c45a4001-3de5-448e-846a-cdb97f53b51d    INFO    Response status: 200 Google
2024-02-17T23:48:53.110Z  c45a4001-3de5-448e-846a-cdb97f53b51d    INFO    Closing the browser...
2024-02-17T23:48:53.172Z  c45a4001-3de5-448e-846a-cdb97f53b51d    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1010M   15M  99% /tmp
END RequestId: c45a4001-3de5-448e-846a-cdb97f53b51d
REPORT RequestId: c45a4001-3de5-448e-846a-cdb97f53b51d    Duration: 611.73 ms     Billed Duration: 612 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: 63a41a59-6354-4fd5-a152-ea05f6aeaf0e Version: $LATEST
2024-02-17T23:48:53.353Z  63a41a59-6354-4fd5-a152-ea05f6aeaf0e    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:53.787Z  63a41a59-6354-4fd5-a152-ea05f6aeaf0e    INFO    Response status: 200 Google
2024-02-17T23:48:53.787Z  63a41a59-6354-4fd5-a152-ea05f6aeaf0e    INFO    Closing the browser...
2024-02-17T23:48:53.827Z  63a41a59-6354-4fd5-a152-ea05f6aeaf0e    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1010M   15M  99% /tmp
END RequestId: 63a41a59-6354-4fd5-a152-ea05f6aeaf0e
REPORT RequestId: 63a41a59-6354-4fd5-a152-ea05f6aeaf0e    Duration: 541.38 ms     Billed Duration: 542 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: a5f86d89-af41-429b-98ad-97b89788ca78 Version: $LATEST
2024-02-17T23:48:54.008Z  a5f86d89-af41-429b-98ad-97b89788ca78    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:54.429Z  a5f86d89-af41-429b-98ad-97b89788ca78    INFO    Response status: 200 Google
2024-02-17T23:48:54.429Z  a5f86d89-af41-429b-98ad-97b89788ca78    INFO    Closing the browser...
2024-02-17T23:48:54.630Z  a5f86d89-af41-429b-98ad-97b89788ca78    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1010M   15M  99% /tmp
END RequestId: a5f86d89-af41-429b-98ad-97b89788ca78
REPORT RequestId: a5f86d89-af41-429b-98ad-97b89788ca78    Duration: 690.29 ms     Billed Duration: 691 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: 32831137-59c3-42a2-a1b4-b39612e63ede Version: $LATEST
2024-02-17T23:48:54.816Z  32831137-59c3-42a2-a1b4-b39612e63ede    INFO    Navigating to: https://www.google.com
2024-02-17T23:48:55.238Z  32831137-59c3-42a2-a1b4-b39612e63ede    INFO    Response status: 200 Google
2024-02-17T23:48:55.239Z  32831137-59c3-42a2-a1b4-b39612e63ede    INFO    Closing the browser...
2024-02-17T23:48:55.442Z  32831137-59c3-42a2-a1b4-b39612e63ede    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1010M   15M  99% /tmp
END RequestId: 32831137-59c3-42a2-a1b4-b39612e63ede
REPORT RequestId: 32831137-59c3-42a2-a1b4-b39612e63ede    Duration: 698.58 ms     Billed Duration: 699 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: 057301c1-bffc-447a-8c41-25bd0c46a120 Version: $LATEST
2024-02-17T23:49:36.963Z  057301c1-bffc-447a-8c41-25bd0c46a120    INFO    Navigating to: https://www.google.com
2024-02-17T23:49:37.398Z  057301c1-bffc-447a-8c41-25bd0c46a120    INFO    Response status: 200 Google
2024-02-17T23:49:37.398Z  057301c1-bffc-447a-8c41-25bd0c46a120    INFO    Closing the browser...
2024-02-17T23:49:37.443Z  057301c1-bffc-447a-8c41-25bd0c46a120    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1010M   15M  99% /tmp
END RequestId: 057301c1-bffc-447a-8c41-25bd0c46a120
REPORT RequestId: 057301c1-bffc-447a-8c41-25bd0c46a120    Duration: 540.32 ms     Billed Duration: 541 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: bcea64ce-356e-4bc3-8b73-f2878b19bb0a Version: $LATEST
2024-02-17T23:49:37.659Z  bcea64ce-356e-4bc3-8b73-f2878b19bb0a    INFO    Navigating to: https://www.google.com
2024-02-17T23:49:38.103Z  bcea64ce-356e-4bc3-8b73-f2878b19bb0a    INFO    Response status: 200 Google
2024-02-17T23:49:38.103Z  bcea64ce-356e-4bc3-8b73-f2878b19bb0a    INFO    Closing the browser...
2024-02-17T23:49:38.152Z  bcea64ce-356e-4bc3-8b73-f2878b19bb0a    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1012M   13M  99% /tmp
END RequestId: bcea64ce-356e-4bc3-8b73-f2878b19bb0a
REPORT RequestId: bcea64ce-356e-4bc3-8b73-f2878b19bb0a    Duration: 565.18 ms     Billed Duration: 566 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: c6d0cafe-bc03-4643-bc39-2963f061ed76 Version: $LATEST
2024-02-17T23:49:38.339Z  c6d0cafe-bc03-4643-bc39-2963f061ed76    INFO    Navigating to: https://www.google.com
2024-02-17T23:49:39.500Z  c6d0cafe-bc03-4643-bc39-2963f061ed76    INFO    Response status: 200 Google
2024-02-17T23:49:39.500Z  c6d0cafe-bc03-4643-bc39-2963f061ed76    INFO    Closing the browser...
2024-02-17T23:49:39.544Z  c6d0cafe-bc03-4643-bc39-2963f061ed76    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1013M   12M  99% /tmp
END RequestId: c6d0cafe-bc03-4643-bc39-2963f061ed76
REPORT RequestId: c6d0cafe-bc03-4643-bc39-2963f061ed76    Duration: 1271.99 ms    Billed Duration: 1272 ms        Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: d24fe1c8-0faa-4631-a57c-2faa1c3904c0 Version: $LATEST
2024-02-17T23:49:39.727Z  d24fe1c8-0faa-4631-a57c-2faa1c3904c0    INFO    Navigating to: https://www.google.com
2024-02-17T23:49:40.189Z  d24fe1c8-0faa-4631-a57c-2faa1c3904c0    INFO    Response status: 200 Google
2024-02-17T23:49:40.189Z  d24fe1c8-0faa-4631-a57c-2faa1c3904c0    INFO    Closing the browser...
2024-02-17T23:49:40.231Z  d24fe1c8-0faa-4631-a57c-2faa1c3904c0    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1014M   11M  99% /tmp
END RequestId: d24fe1c8-0faa-4631-a57c-2faa1c3904c0
REPORT RequestId: d24fe1c8-0faa-4631-a57c-2faa1c3904c0    Duration: 576.77 ms     Billed Duration: 577 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: 307446b8-4f42-4ac7-b1cd-ad7831c79b61 Version: $LATEST
2024-02-17T23:49:40.410Z  307446b8-4f42-4ac7-b1cd-ad7831c79b61    INFO    Navigating to: https://www.google.com
2024-02-17T23:49:41.413Z  307446b8-4f42-4ac7-b1cd-ad7831c79b61    INFO    Response status: 200 Google
2024-02-17T23:49:41.413Z  307446b8-4f42-4ac7-b1cd-ad7831c79b61    INFO    Closing the browser...
2024-02-17T23:49:41.494Z  307446b8-4f42-4ac7-b1cd-ad7831c79b61    INFO    df -h /tmp:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdd        1.1G 1014M   11M  99% /tmp
END RequestId: 307446b8-4f42-4ac7-b1cd-ad7831c79b61
REPORT RequestId: 307446b8-4f42-4ac7-b1cd-ad7831c79b61    Duration: 1145.56 ms    Billed Duration: 1146 ms        Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: d87622b4-bba3-4f79-be35-65ad8aad83ea Version: $LATEST
2024-02-17T23:49:41.666Z  d87622b4-bba3-4f79-be35-65ad8aad83ea    INFO    Navigating to: https://www.google.com
2024-02-17T23:49:41.959Z  d87622b4-bba3-4f79-be35-65ad8aad83ea    ERROR   Unexpected Error: page.goto: Target page, context or browser has been closed
Call log:
  - navigating to "https://www.google.com/", waiting until "load"

    at Array.<anonymous> (/var/task/routes.js:23:35)
    at async Runtime.handler (/var/task/node_modules/.pnpm/hono@3.12.10/node_modules/hono/dist/cjs/adapter/aws-lambda/handler.js:53:21)
    at async Runtime.handleOnceStreaming (/var/runtime/index.mjs:1206:26)
2024-02-17T23:49:41.960Z  d87622b4-bba3-4f79-be35-65ad8aad83ea    INFO    Closing the browser...
END RequestId: d87622b4-bba3-4f79-be35-65ad8aad83ea
REPORT RequestId: d87622b4-bba3-4f79-be35-65ad8aad83ea    Duration: 356.68 ms     Billed Duration: 357 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: ae256f14-c71f-4247-a347-a3c8a30647f5 Version: $LATEST
2024-02-17T23:49:42.140Z  ae256f14-c71f-4247-a347-a3c8a30647f5    INFO    Navigating to: https://www.google.com
2024-02-17T23:49:42.442Z  ae256f14-c71f-4247-a347-a3c8a30647f5    ERROR   Unexpected Error: page.goto: Target page, context or browser has been closed
Call log:
  - navigating to "https://www.google.com/", waiting until "load"

    at Array.<anonymous> (/var/task/routes.js:23:35)
    at async Runtime.handler (/var/task/node_modules/.pnpm/hono@3.12.10/node_modules/hono/dist/cjs/adapter/aws-lambda/handler.js:53:21)
    at async Runtime.handleOnceStreaming (/var/runtime/index.mjs:1206:26)
2024-02-17T23:49:42.442Z  ae256f14-c71f-4247-a347-a3c8a30647f5    INFO    Closing the browser...
END RequestId: ae256f14-c71f-4247-a347-a3c8a30647f5
REPORT RequestId: ae256f14-c71f-4247-a347-a3c8a30647f5    Duration: 359.22 ms     Billed Duration: 360 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: d75e52e2-1473-4993-be78-f108e7313668 Version: $LATEST
2024-02-17T23:49:42.614Z  d75e52e2-1473-4993-be78-f108e7313668    INFO    Navigating to: https://www.google.com
2024-02-17T23:49:42.890Z  d75e52e2-1473-4993-be78-f108e7313668    ERROR   Unexpected Error: page.goto: Target page, context or browser has been closed
Call log:
  - navigating to "https://www.google.com/", waiting until "load"

    at Array.<anonymous> (/var/task/routes.js:23:35)
    at async Runtime.handler (/var/task/node_modules/.pnpm/hono@3.12.10/node_modules/hono/dist/cjs/adapter/aws-lambda/handler.js:53:21)
    at async Runtime.handleOnceStreaming (/var/runtime/index.mjs:1206:26)
2024-02-17T23:49:42.890Z  d75e52e2-1473-4993-be78-f108e7313668    INFO    Closing the browser...
END RequestId: d75e52e2-1473-4993-be78-f108e7313668
REPORT RequestId: d75e52e2-1473-4993-be78-f108e7313668    Duration: 343.92 ms     Billed Duration: 344 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: 07313c8c-e13f-4217-80b3-eb69aef77431 Version: $LATEST
2024-02-17T23:49:43.062Z  07313c8c-e13f-4217-80b3-eb69aef77431    INFO    Navigating to: https://www.google.com
2024-02-17T23:49:43.269Z  07313c8c-e13f-4217-80b3-eb69aef77431    ERROR   Unexpected Error: page.goto: net::ERR_INSUFFICIENT_RESOURCES at https://www.google.com/
Call log:
  - navigating to "https://www.google.com/", waiting until "load"

    at Array.<anonymous> (/var/task/routes.js:23:35)
    at async Runtime.handler (/var/task/node_modules/.pnpm/hono@3.12.10/node_modules/hono/dist/cjs/adapter/aws-lambda/handler.js:53:21)
    at async Runtime.handleOnceStreaming (/var/runtime/index.mjs:1206:26) {
  name: 'Error'
}
2024-02-17T23:49:43.270Z  07313c8c-e13f-4217-80b3-eb69aef77431    INFO    Closing the browser...
END RequestId: 07313c8c-e13f-4217-80b3-eb69aef77431
REPORT RequestId: 07313c8c-e13f-4217-80b3-eb69aef77431    Duration: 302.25 ms     Billed Duration: 303 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB
START RequestId: 54abde91-ed73-4e23-a635-a7a663c96c70 Version: $LATEST
2024-02-17T23:49:43.490Z  54abde91-ed73-4e23-a635-a7a663c96c70    INFO    Navigating to: https://www.google.com
2024-02-17T23:49:43.707Z  54abde91-ed73-4e23-a635-a7a663c96c70    ERROR   Unexpected Error: page.goto: net::ERR_INSUFFICIENT_RESOURCES at https://www.google.com/
Call log:
  - navigating to "https://www.google.com/", waiting until "load"

    at Array.<anonymous> (/var/task/routes.js:23:35)
    at async Runtime.handler (/var/task/node_modules/.pnpm/hono@3.12.10/node_modules/hono/dist/cjs/adapter/aws-lambda/handler.js:53:21)
    at async Runtime.handleOnceStreaming (/var/runtime/index.mjs:1206:26) {
  name: 'Error'
}
2024-02-17T23:49:43.707Z  54abde91-ed73-4e23-a635-a7a663c96c70    INFO    Closing the browser...
END RequestId: 54abde91-ed73-4e23-a635-a7a663c96c70
REPORT RequestId: 54abde91-ed73-4e23-a635-a7a663c96c70    Duration: 313.69 ms     Billed Duration: 314 ms Memory Size: 8192 MB    Max Memory Used: 1399 MB

Possible Solution
I wish i knew of one, I am stumped so far.  I have tried increasing to 4GB and 8 GB and it still fills up all the space.

@Sparticuz This seems to only happen when using Playwright.  With puppeteer the /tmp space doesn't grow like this.  Any ideas?

@sg650 Did you try adding @sparticuz/chromium as a lambda layer?

Did you ever resolve this? Getting similiar results with playright

@Sparticuz Any insight here? Enjoy your travels, and thanks for the great tool.

I had the same problem with Playwright even running on a Python Docker Image on Lambda.
I posted about it in the Playwright Discord server, but never got a response: https://discord.com/channels/807756831384403968/1230133049090379827/1230133049090379827
In my post I said Lambda is running out of memory until it crashes, but it had the same problem with /tmp/* filling up. Depending on the configuration, either memory or storage runs out first and causes Lambda to crash.
So I think this issue should probably be moved to the Playwright repo, even though I don't think you'll get any help tehre.

Any update on this?
I assume it's more of a Puppeteer issue though, but we have the same issue when trying to generate a large number of PDF's... We get a few thousand Invoices (as XML) from a customer and then we need to generate PDF's for these. We have set ephemeral storage to 10GB and we can generate some 600-700 PDF's (invokations) before it runs out of /tmp space, with either ENOSPC: no space left on device, mkdtemp '/tmp/ or
2024-10-16T11:55:09.278Z	c5b6c5f7-d891-4760-a2a7-0c2659ab20a8	INFO	htmltopdf getting this error Error: Failed to launch the browser process!
[1016/115509.269172:ERROR:platform_thread_posix.cc(155)] pthread_create: Resource temporarily unavailable (11)
[1016/115509.269211:ERROR:platform_thread_posix.cc(155)] pthread_create: Resource temporarily unavailable (11)
[1016/115509.269328:ERROR:platform_thread_posix.cc(155)] pthread_create: Resource temporarily unavailable (11)
[1016/115509.269544:FATAL:browser_task_executor.cc(310)] Failed to start BrowserThread:IO

AWS is not using "isolated" /tmp storage per invokation, even if we set ephemeral storage size for a Lambda, so it runs out of /tmp space when we have concurrent invokations. We can't delete /tmp in one Lambda either, as each concurrent Lambda is using the same "disk".
We tried this and then the other concurrent Lambdas "crash" as the /tmp files they had written is gone.
So, is it possible to know which files "belongs" to which invokation to only delete the ones belonging to that instance?
I've raised a support ticket with AWS as IMO the ephemeral storage should be available as the set value for EVERY invokation. That's how I interpret this article as well: https://aws.amazon.com/blogs/compute/using-larger-ephemeral-storage-for-aws-lambda/


Update docker.md

Found a typo.
Please note that the "edit this page" button on the french website does go to the english section. I'm not sure where to look to fix this

Thanks! The code of the website is in this repo: https://github.com/dunglas/frankenphp-website
A PR is very welcome, but if you have no time we can try to fix it too :)


chore: remove patch version

Backport e6e0386

Codecov Report

Merging #16 (a40c530) into fdb-0.2.x (17cb651) will decrease coverage by 0.03%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##           fdb-0.2.x      #16      +/-   ##
=============================================
- Coverage      89.48%   89.44%   -0.04%
=============================================
  Files             17       17
  Lines           7666     7666
=============================================
- Hits            6860     6857       -3
- Misses           806      809       +3

Impacted Files
Coverage Δ

fdb/src/future.rs
80.41% <0.00%> (-1.04%)
:arrow_down:

Continue to review full report at Codecov.

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


showShareSheetWithLinkProperties triggers deep link behaviour on app resume with some applications

iOS version: 9.2.1
Production environment: debug and release
Steps to reproduce:

create a BranchUniversalObject
call the showShareSheetWithLinkProperties method of the universal object
share with the Notes or Reminders iOS applications
Press home button
Resume application
The callback method of the Branch instance is called with the data of the universal object that was previously shared and has the +clicked_branch_link property set to true/1

This behaviour does not appear when sharing to Facebook, WhatsApp, Twitter etc. In these cases a normal callback with no additional data is performed.

@teodora92 I answered on #302..closing here


blog: a post on tilt-apiserver

Hello @ellenkorbes, @milas,
Please review the following commits I made in branch nicks/curl:
550152aedb669557b2251cb4011e319422cf38e1 (2021-03-04 12:55:59 -0500)
blog: a post on tilt-apiserver
Code review reminders, by giving a LGTM you attest that:

Commits are adequately tested
Code is easy to understand and conforms to style guides
Incomplete code is marked with TODOs
Code is suitably instrumented with logging and metrics

Mainly trying to externalize a lot of the discussions we've been having internally about extensibility and why it's useful

ha - i think the line about pod is just badly phrased - not trying to explain what a pod is. Just trying to establish the analogy between the pod API and /proc. I'll rephrase.
re: the audience - trying to capture the tone / technical level of https://wizardzines.com/comics/containers-arent-magic/, which i really admire. i.e., developers who use Kubernetes, but treat it as a black box, and would benefit from a deeper understanding of how it works.
re: the conclusion line - ya, i agree with that, will move it up


raycast: 1.76.1 -> 1.77.0

Description of changes
Changelog: https://www.raycast.com/changelog/1-77-0
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 321080 run on aarch64-darwin 1

1 package built:

raycast


Extended script to with parameter to submit a specific commit sha to be downloaded and installed.

I would love to see this merged.


Moveable performance: Cache wrapper's BoundingClientRect

Calling .getBoundingClientRect() on every update is pretty expensive and could lead to jankiness on mobile and such, so please do consider caching it instead.
I'm not sure about Moveable.update() because there's a slim chance the window might be resized and then the offsets and what not will be out of wack, but for the most part I think it shouldn't be an issue perhaps just use .trigger() (it now updates the rect when called) when manually updating the position. Otherwise the BoundingClientRect will be updated on each ._tapstart() which is fine, also just for brevity .trigger(evt) <- can now optionally take an event so it can be used in ._tapstart() avoiding repetition.

Your right, that's actually very expensive. Good improvement, never thought about it :)
.update() is only being called from the setHSVA() method, so it should be no problem to use the cached coordinates.


fix(extra.lang.scala): Fix the always initializing regardless of file…

…type

Thanks!
And I only now saw that vsnip got in there, so thank you for removing that!


RuntimeError with WebAssembly in @react-pdf/yoga on Node.js Server

Hello,
I've encountered a critical issue while using @react-pdf/renderer in a Node.js Express server environment. The server crashes with a RuntimeError related to WebAssembly memory allocation when attempting to generate PDFs. The error message is as follows:
RuntimeError: Aborted(RangeError: WebAssembly.instantiate(): Out of memory: wasm memory). Build with -sASSERTIONS for more info.
    at w (/usr/app/node_modules/yoga-layout/binaries/wasm-async-node.js:14:73)
    at /usr/app/node_modules/yoga-layout/binaries/wasm-async-node.js:62:60

This error suggests that the WebAssembly module within yoga-layout, which is a dependency of @react-pdf/renderer, is running out of memory.
To Reproduce

Set up a basic Express server that uses @react-pdf/renderer to generate PDFs.
Trigger the PDF generation endpoint with the necessary data.
The server crashes with the above RuntimeError after a few successful PDF generations.
Expected Behavior:

The PDF generation should complete successfully without causing a server crash or running out of WebAssembly memory.
Actual Behavior:
The server crashes with a RuntimeError indicating that WebAssembly ran out of memory.
Additional Context:
The issue seems to occur after generating multiple PDFs, suggesting a potential memory leak or insufficient memory allocation for WebAssembly in the yoga-layout module.
Reducing the complexity of the PDF layout temporarily mitigates the issue but does not solve it entirely.
I would appreciate any insights or suggestions on how to resolve this issue. If there are any known workarounds or if additional information is needed, please let me know.
Environment:
Node.js version: v16.18.1
Express version: ^4.18.2
@react-pdf/layout": "3.10.3",
@react-pdf/renderer": "3.3.4",
Operating System: docker image
Thank you for your time and assistance.

This is going to be hard to diagnose without more information about the usage.
The Yoga itself allows heap growth (https://github.com/facebook/yoga/blob/58aa0907746204e151eac38f05827322bc4e6f63/javascript/CMakeLists.txt#L37) and provides methods to free nodes/configs.
Without knowing more, out of memory seems like the consuming library might not be freeing resources, or that there is an irregularly large tree.

Not sure if this is relevant, but in my (browser based) benchmarking scripts where I was constructing, measuring and then destructing Yoga trees in a loop, I was hitting a similar crash. It took quite high iteration count (>10000) to hit it, but it was with a script that in theory shouldn't have increased heap size at all. This also occurred with a similar Taffy-based benchmark at similar iteration counts.
It could perhaps be due to heap fragmentation? Or immaturity of WASM implementations? Although I must admit that I haven't investigated this thoroughly enough to rule out user error.
As a workaround, if this is only occurring after repeated PDF generation, then you could try the following steps (in order):

Catch the exception
Deinitialise the WASM module
Reinitialise the WASM module
Retry your call into Yoga

I took a quick look at this, and other issues running into it: https://github.com/vercel/next.js/issues/51870
I missed that this error happens during WASM environment instantiation. So, this error indicates that the WASM is being loaded into a new environment, and Node doesn't have enough memory to do that.
I am wondering if this scenario is somehow doing this loading more than once, or if maybe multiple processes are doing this, and running out of memory.
I went to double check if we have documented guarantees from Emscripten module that it is only loaded once on load call,  but couldn't quickly verify. We are pushing out Yoga 3.0 now, which will cache the instance regardless.


GKE node version change

what is the manual process for rolling forward or rolling backwards the version of kubernetes running on a gke node?
this ticket should produce a set of command line steps to effect both up and down version changes.
Should also include about how long the process takes.

https://cloud.google.com/container-engine/docs/clusters/upgrade

from above page:
Rolling back a node upgrade (ALPHA)
Container Engine now supports rolling back of Failed or Canceled node upgrades. If you roll back an upgrade, any nodes that have been upgraded will be rolled back to the previous configuration. Any nodes that had not been upgraded will be left as-is. However, note that you cannot roll back an upgrade that had previously completed successfully; a rollback operation on a successful upgrade is interpreted as a no-op.
You can roll back an upgrade by running the following command in your shell or terminal window:
gcloud alpha container node-pools rollback $POOL_NAME --cluster $CLUSTER_NAME

word choice issue on my part.  in the google cloud vernacular this ticket is about upgrades and downgrades of the cluster nodes.

from the same page:
Because the cluster master is managed by Google, the version of Kubernetes that is running on the master is automatically updated to the most recently released version. The cluster nodes, however, are not automatically upgraded when newer versions of the Kubernetes API are released. This allows you to upgrade on your own schedule, coordinating with other maintenance and avoiding impact during business-critical windows.

Because the cluster master is managed by Google, the version of Kubernetes that is running on the master is automatically updated to the most recently released version. The cluster nodes, however, are not automatically upgraded when newer versions of the Kubernetes API are released. This allows you to upgrade on your own schedule, coordinating with other maintenance and avoiding impact during business-critical windows.
To find the supported master and node versions for upgrades, run the following command:
gcloud container get-server-config [--zone=ZONE]
To change your cluster nodes' version, use the gcloud container clusters upgrade command:
gcloud container clusters upgrade $CLUSTER_NAME --cluster-version=$CLUSTER_VERSION

CLUSTER_NAME is the name of the container cluster to upgrade.
CLUSTER_VERSION has the form X.Y.Z
Optionally, --cluster-version can be used to upgrade or downgrade to a specific release. Omitting this flag upgrades the container cluster to the version on the master. If used, you must specify a version within two minor releases of the master's version, at the highest patch number. Supported versions are listed in the Release Notes.

When you initiate a cluster version change, each instance in the cluster is deleted one at a time. After the instance is deleted, Container Engine adds a new instance to the cluster with the specified Kubernetes API, as well as the associated base image, Docker daemon, kubelet, and kube-proxy.
I started a 3 node cluster and added the cnct/central-logging system for testing purposes.  It took 11 minutes to upgrade the cluster.
More detailed info found at Updating a Container Cluster

From Updating a Container Cluster
###Important considerations
Before beginning an upgrade or downgrade, there are some important details to consider.

An upgrade/downgrade works by deleting all node instances, one at a time, and replacing them with new instances running the desired Kubernetes version.

Before an instance is deleted, it is marked unschedulable and drained. Any pods running on the instance are deleted. If they are managed by a controller, the controller will attempt to reschedule the pods on the remaining instances. Pods that are not managed by a controller will not be restarted.  Once the node re-enters the fleet at the new version, it is marked schedulable.

Any data in hostDir or emptyDir volumes in pods is deleted during an upgrade/downgrade. To preserve data across upgrade/downgrade, use a pod with a gcePersistentDisk volume. Note that this is different than the persistent disk created by default as a boot disk with Compute Engine instances; boot disks are deleted along with the instances as part of the upgrade/downgrade. A gcePersistentDisk volume is a disk created separately from your instances.

When a node instance is shut down as part of an upgrade/downgrade, its replacement will be assigned the same instance name.

Downgrades are supported up to two minor versions before the master's version (x.X.x), each at their latest patch version (x.x.X).

You can find the supported master and node versions for upgrades by running the following command:

gcloud container get-server-config [--zone=ZONE]

34 pods running on 5 nodes took :
$ time  gcloud container clusters upgrade ds-more-pods --cluster-version=1.5.2 --zone=us-west1-a
All 5 nodes of cluster [ds-more-pods] will be upgraded from version
[1.5.3] to version [1.5.2]. This operation is long-running and will
block other operations on the cluster (including delete) until it has
run to completion.

Do you want to continue (Y/n)?  Y

Upgrading ds-more-pods... RollingUpdate finished in "us-west1-a"....done.
Updated [https://container.googleapis.com/v1/projects/k8s-work/zones/us-west1-a/clusters/ds-more-pods].

real	18m11.993s
user	0m1.282s
sys	0m0.232s

11 pods running on 3 nodes:
time gcloud container clusters upgrade ds-small-cluster --cluster-version=1.5.2
All 3 nodes of cluster [ds-small-cluster] will be upgraded from
version [1.5.3] to version [1.5.2]. This operation is long-running and
 will block other operations on the cluster (including delete) until
it has run to completion.

Do you want to continue (Y/n)?  Y

Upgrading ds-small-cluster... RollingUpdate finished in "us-central1-a"....done.
Updated [https://container.googleapis.com/v1/projects/k8s-work/zones/us-central1-a/clusters/ds-small-cluster].

real	12m14.141s
user	0m0.973s
sys	0m0.177s

ToReview:

ensure that steps listed here: https://github.com/samsung-cnct/k2/issues/217#issuecomment-285467380 fully cover what we're up to


No music playback in Editor

Below is the code block being used by me to add music to Video Editor instance:
if (musicId == -1) {
    musicId = editor?.addMusic(config.toString()) ?: -1
} else {
    editor?.updateMusic(config.toString(), musicId)
}

The config is:
{
    "path":"/data/user/0/blog.rishabh.trinity/cache/musicfile.mp3",
    "startTime":0,
    "endTime":239102
}

Music is not played back in the editor. However, once the video is exported, music shows up in the exported final video.

+1
I've the same issues.

Please use mars to parse the log file and submit

using implementation 'com.github.wlanjie:trinity:0.3.0' video editor call prepare before playing


download icon for pdfs missing from document detail template

Just want to note that in fact we want the download icon to show up automatically on any link for any document (PDF, DOCX, etc). If it can't be automatic, then we need some way for content editors to add it -- but would be preferable if the cms could recognize that the linked object is not a hyperlink and add the icon automatically.
For reference, this is the [Design Manual entry on hyperlinks] (https://cfpb.github.io/design-manual/ui-toolkit/links.html) -- scroll to the bottom for "Links with icons" section and see the download example.

Do we want to limit what molecules the download icon is shown in? We've included a little bit of code on the WordPress "subpages" to do this and we can move it to some of the atomic stylesheets.
https://github.com/cfpb/cfgov-refresh/blob/5e64cc36be5d1e50c0815c1dcea6d1013a9ff344/cfgov/unprocessed/css/pages/sub-pages.less#L16

Um, I think the only kinds of places where we wouldn't want the icon is in headers or navigation -- but that seems like the kind of thing we could control via content input. @duelj and @ajbush am I missing anything?
Also, I noticed that the download link isn't showing up on blog/news entries, which are being pulled in from WordPress -- is that a different bug that I should log separately? Examples: First link in body text of this post is a PDF and report link at the end of this post is a PDF

@schaferjh - that sounds right to me. Although keeping the icon in all cases (including header and nav) might help us quickly sort if someone tries putting a download in on of those areas, and flag it earlier than if there were no icon. Sort of keeping a bug to spot another bug (improper use of content).

Also, I noticed that the download link isn't showing up on blog/news entries, which are being pulled in from WordPress -- is that a different bug that I should log separately?

Nope. Same issue.

(PDF, DOCX, etc)

What are the etc files... .doc is one, but do you have a full list?

I don't have a full list, but I think this list would cover 95% (if not 99%) of instances:

PDF
DOCX
DOC
XLSX
XLS
CSV

@sarahsimpson09 @tnferrell anything you'd add?

I got it working in a way that looks good with our mobile styles, works with our download lists, and doesn't do anything weird when there's already an icon. However, due to the new way we're doing underlines in CF, the icons have an underline that we won't be able to remove with CSS alone in full-width text molecules and the blog.
Thoughts on how to address this?

@KimberlyMunoz I did a lot of research back in the day, and I don't think it's possible with CSS only, unfortunately.
At one point, we had the notion to use Sheer to filter the content coming in from the CMS to add in the necessary markup to do this as designed when it detected a PDF link or external link. The same concept could probably be done with Django?

Is this something that we can do, @kurtw, @kave or @richaagarwal?
Using this method, we could add a , but we'd have to do this in only the blog section and full-text width modules to prevent an extra download icon with list downloads.

This is an interesting question. This is certainly possible to add a content type to select which would render the link like that, but within a RichTextField it could be rather hard. More research is needed, but I'll get an answer ASAP.

Is this something that will apply to adding the external link icon to non-gov third party links as well?

btw, in discussion with content we realized ZIP is also a file type that we should include as a linked file type that gets this icon.

@KimberlyMunoz for V1 I am totally fine with the link underline continuing under the icon. @kurtw did your research turn up anything? If no or if the fix is time-consuming, I would like us to move forward with showing the icon with the link underline in some places.
This is high priority because users need to know if a link is a document or a hyperlink. It's also high priority if the answer to this:

Is this something that will apply to adding the external link icon to non-gov third party links as well?

is yes.

Apologies for the late response. Unfortunately, the icon feature within rich text fields would be time consuming. Is @KimberlyMunoz solution sufficient for all cases? Meaning, is there anything else BEWDs could take care of or need to be aware?

I'll take this issue for this sprint. We'll add a task for a better solution in v2.

Something else that could impact this in v4 that you might want to note in your future task: a move away from minicons as an icon font to an SVG library.

The implementation should still be similar. At the very least moving to SVGs will be a big move that affects everything at once and we'll know how to deal with it in this case.


Update Kotlin to 1.5.0

I've updated Kotlin to 1.5.0. This needed some small code changes. After updating I've encountered a weird issue with ktlint and because of that I've added NewApirule to the "information" group to make lint work. I've also created an issue that aims to bring that rule back to the "errors" group https://github.com/ably/ably-asset-tracking-android/issues/371.

We're going to hold off from landing this PR until we've done the Beta 7 release.


feat: [v0.8-develop] account self call restrictions

Motivation
In ERC-6900 v0.8, we’re planning on explicitly defining account self-calls to bypass validation. Previously in 6900 v0.7, this behavior was left up to the runtime validation function, but we depended on this behavior for things that the core account needed to do - like batching internal calls by setting the target to self.
Self-calls are also necessary for 6900 v0.8 to efficiently support two new workflows: executeUserOp, the function introduced in EntryPoint v0.7 to allow accounts to access user op contents in the execution phase, and executeWithAuthorization, a workflow to allow selecting between different runtime validation functions & to provide data to the runtime validation function and its hooks.
In both of those functions, a self-call is used after the “validation” checks are complete. Then, the account is able to execute the function(s) as regular native functions or functions routed through the fallback. Doing so lets us avoid having internal routing for every external function. Internal routing is difficult, un-idiomatic solidity because it involves reimplementing the automatically generated function dispatcher. This would also increase implementation complexity of 6900 v0.8.
However, there is a notable issue with self-call authorization:  If a validation function is added to either standard execute functions (execute or executeBatch), then that validation function effectively gets “root” access. Any execution function, including execution functions that the validation function is not allowed to call directly, may instead be called by performing a self-call and encoding the execution function invocation into calldata.
We want to prevent the privilege escalation, while still allowing self-calling for the purposes of batching actions, and handling executeWithAuthorization and executeUserOp.
Solution
When running user op and runtime validation, add an extra check:

If the function is execute, disallow a target address of the account. This is unnecessary wrapping, and the inner call may instead be pulled up to the entire calldata itself.
If the function is executeBatch, then:

for each Call where the target is the account, inspect the selector in calldata:

the validation currently being used must apply to that selector
the selector must not be another recursing call to the account's execute or executeBatch functions.

This preserves the ability to use self-calls for batched actions, executeUserOp, and executeWIthAuthorization, while preventing privilege escalation.
Also add a test that shows these different use cases with ComprehensivePlugin.
Design Questions
In earlier attempts to solve this problem, I suggested allowing arbitrarily-deep recursion via execute/executeBatch. This would pose a problem to pre-validation hooks looking to inspect calldata, wherein we must either:

require the hooks to also implement arbitrary-depth recursion
have the account unpack all inner calls, and fire the hooks for each invocation.

However, this PR proposes an approach of entirely disallowing execute to self, and only allowing a max recursion depth of 1 for executeBatch. This simplifies things by capping the depth of any required calldata-inspecting pre validation hooks to max 1, and only for the executeBatch selector. Given this constraint, I think it is reasonable to expect pre-validation hooks that fall into this category of "inspecting calldata selectors + params" to either:

restrict what selectors a validation may call to exclude executeBatch, and not have to worry about this.
allow executeBatch, and unpack + handle the logic for each call in the batch within the hook itself.

Does that seem like a reasonable expectation?

The solution is simple and makes sense to me. I wonder if there are scenarios we missed where a 2 levels down nested self-calls necessary.
I am for this simplicity approach.

Hmm, don't think the runtime path is protected. Someone with callPermitted permissions can call any msg.sig. We're deprecating the callPermitted path so not necessary to have a solution here, but if we add any other forms of runtime validation, it would also need to do this selector check. If thats the case, does it make sense to add the check in wrapNativeFunction instead?
Check I was thinking of:
if (msg.sender == address(this) && selector == execute/executeBatch)) => revert

Someone with callPermitted permissions can call any msg.sig

Ahh shoot, good catch on this. Yes we're deprecating that path, but this PR still has it. I'll make a note to hold off on merging this until we get that change in from #67, and that fix is patched.
As for the inner check - I think within the scope of this PR's change, we're OK without that check, but if we ever re-introduce something like callPermitted (a way to authorize directly calling the account, not through executeWithAuthorization), then we'll need to add a check like that.