Distributed training with wandb.sweep

I'm using wandb for the first time and I'm having a bit of a problem, when running a model with a single multi-GPU, I want to use wandb.sweep to scan for hyperparameters, I'm guessing that the code is running with a new sweep created on top of each GPU due to the part of distributed training being run first and then initializing wandb.sweep, what I'm hoping for I want to have only one sweep_id and train my model on multiple GPUs, what should I do?
The environment I use is pytorch 2.0 and CUDA version 12.2,I trained my model by typing the command "torchrun --nproc_per_node=6 train.py" in the terminal.
Here is the main function entry for my model's train.py code:
if name == "main":
sweep_config = get_wandb_config()
sweep_id = wandb.sweep(sweep_config, project=sweep_config['project_name'])
wandb.agent(sweep_id, run, count=3)
Here is the main code for the run function：
def run():
.....
args = get_args_parser()
nowtime = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
wandb.init(project=sweep_config['project_name'], name=nowtime, save_code=True, config=sweep_config, group="DDP")
args.learning_rate = wandb.config.learning_rate
args.lr_drop_epoch = wandb.config.lr_drop_epoch
args.max_epoch_num = wandb.config.max_epoch_num
args.optim = wandb.config.optim
net = MaskDecoderHQ(args.model_type)
main(net, train_datasets, valid_datasets, args, sweep_config)
wandb.finish()
Here is the code for the first part of the train function：
def main(net, train_datasets, valid_datasets, args, sweep_config):
misc.init_distributed_mode(args)
seed = args.seed + misc.get_rank()
torch.manual_seed(seed)
np.random.seed(seed)
random.seed(seed)
......
Then there is the output log of the model run:
wandb: WARNING Malformed sweep config detected! This may cause your sweep to behave in unexpected ways.
wandb: WARNING To avoid this, please fix the sweep config schema violations below:
wandb: WARNING   Violation 1. Additional properties are not allowed ('metrics', 'project_name' were unexpected)
Create sweep with ID: rqbqivtl
Sweep URL: https://wandb.ai/.../sweeps/rqbqivtl
wandb: WARNING Malformed sweep config detected! This may cause your sweep to behave in unexpected ways.
wandb: WARNING To avoid this, please fix the sweep config schema violations below:
wandb: WARNING   Violation 1. Additional properties are not allowed ('metrics', 'project_name' were unexpected)
Create sweep with ID: 31foef6f
Sweep URL: https://wandb.ai/.../sweeps/31foef6f
wandb: WARNING Malformed sweep config detected! This may cause your sweep to behave in unexpected ways.
wandb: WARNING To avoid this, please fix the sweep config schema violations below:
wandb: WARNING   Violation 1. Additional properties are not allowed ('metrics', 'project_name' were unexpected)
Create sweep with ID: 27tb9vkv
Sweep URL: https://wandb.ai/.../sweeps/27tb9vkv
wandb: WARNING Malformed sweep config detected! This may cause your sweep to behave in unexpected ways.
wandb: WARNING To avoid this, please fix the sweep config schema violations below:
wandb: WARNING   Violation 1. Additional properties are not allowed ('metrics', 'project_name' were unexpected)
Create sweep with ID: 27m6nd76
Sweep URL: https://wandb.ai/../sweeps/27m6nd76
wandb: WARNING Malformed sweep config detected! This may cause your sweep to behave in unexpected ways.
wandb: WARNING To avoid this, please fix the sweep config schema violations below:
wandb: WARNING   Violation 1. Additional properties are not allowed ('metrics', 'project_name' were unexpected)
Create sweep with ID: b0f81ait
Sweep URL: https://wandb.ai/.../sweeps/b0f81ait
wandb: Agent Starting Run: sofplkis with config:
wandb: 	learning_rate: 0.0005
wandb: 	lr_drop_epoch: 80
wandb: 	max_epoch_num: 200
wandb: 	optim: Adam
wandb: Agent Starting Run: o5mmxwkd with config:
wandb: 	learning_rate: 0.0003
wandb: 	lr_drop_epoch: 80
wandb: 	max_epoch_num: 100
wandb: 	optim: Adam
wandb: Agent Starting Run: 2y8wyoo9 with config:
wandb: 	learning_rate: 0.0001
wandb: 	lr_drop_epoch: 40
wandb: 	max_epoch_num: 150
wandb: 	optim: Adam
wandb: Agent Starting Run: mewgkh87 with config:
wandb: 	learning_rate: 0.0001
wandb: 	lr_drop_epoch: 100
wandb: 	max_epoch_num: 100
wandb: 	optim: SGD
wandb: Agent Starting Run: 0ukaa50c with config:
wandb: 	learning_rate: 0.0005
wandb: 	lr_drop_epoch: 100
wandb: 	max_epoch_num: 150
wandb: 	optim: SGD
wandb: WARNING Malformed sweep config detected! This may cause your sweep to behave in unexpected ways.
wandb: WARNING To avoid this, please fix the sweep config schema violations below:
wandb: WARNING   Violation 1. Additional properties are not allowed ('metrics', 'project_name' were unexpected)
Create sweep with ID: lqiseifr
Sweep URL: https://wandb.ai/.../sweeps/lqiseifr
wandb: Currently logged in as: .... . Use wandb login --relogin to force relogin
wandb: WARNING Ignored wandb.init() arg project when running a sweep.
wandb: Currently logged in as: .... . Use wandb login --relogin to force relogin
wandb: WARNING Ignored wandb.init() arg project when running a sweep.
wandb: Currently logged in as: .... . Use wandb login --relogin to force relogin
wandb: WARNING Ignored wandb.init() arg project when running a sweep.
wandb: Currently logged in as: .... . Use wandb login --relogin to force relogin
wandb: WARNING Ignored wandb.init() arg project when running a sweep.
wandb: Agent Starting Run: mjo15l5x with config:
wandb: 	learning_rate: 0.0004
wandb: 	lr_drop_epoch: 60
wandb: 	max_epoch_num: 200
wandb: 	optim: SGD
wandb: Currently logged in as: .... . Use wandb login --relogin to force relogin
wandb: WARNING Ignored wandb.init() arg project when running a sweep.
wandb: - Waiting for wandb.init()...
wandb: - Waiting for wandb.init()...
wandb: \ Waiting for wandb.init()...
wandb: \ Waiting for wandb.init()...
wandb: Currently logged in as: .... . Use wandb login --relogin to force relogin
wandb: WARNING Ignored wandb.init() arg project when running a sweep.
wandb: Tracking run with wandb version 0.17.1
wandb: Run wandb offline to turn off syncing.
wandb: Syncing run 2024-06-18 02:10:19
wandb: ⭐ View project at https://wandb.ai/...
wandb: 🧹 View sweep at https://wandb.ai/.../sweeps/lqiseifr
wandb: 🚀 View run at https://wandb.ai/.../runs/mjo15l5x
wandb: Tracking run with wandb version 0.17.1
wandb: Run wandb offline to turn off syncing.
wandb: Syncing run 2024-06-18 02:10:17
wandb: ⭐ View project at https://wandb.ai/...
wandb: 🧹 View sweep at https://wandb.ai/.../sweeps/31foef6f
wandb: 🚀 View run at https://wandb.ai/.../runs/o5mmxwkd
From the output logs, my guess is that each GPU running the model code creates a new sweat id, and each sweat id in turn scans all the hyperparameter combinations I've set up, but I actually only need one sweat id that scans a set of hyperparameter combinations, but since I'm going to be going into my run in the sweat.agent() function part of the code function part of the code, so it's a bit of an ordering problem, but there's no solution yet!

Jason Davenport commented: Hello! To make sure I can best assist you, may I please ask for more information? A copy of the code in question would be the best place to start, along with a detailed rundown of what environment you are running in.
Let me know! Thanks 🙂
Hi, I've updated my question, can you look at it for me or is there any more information I need to provide?

I'm using wandb for the first time and I'm having a bit of a problem, when running a model with a single multi-GPU, I want to use wandb.sweep to scan for hyperparameters, I'm guessing that the code is running with a new sweep created on top of each GPU due to the part of distributed training being run first and then initializing wandb.sweep, what I'm hoping for I want to have only one sweep_id and train my model on multiple GPUs, what should I do?
The environment I use is pytorch 2.0 and CUDA version 12.2,I trained my model by typing the command "torchrun --nproc_per_node=6 train.py" in the terminal.
Here is the main function entry for my model's train.py code: if name == "main": sweep_config = get_wandb_config() sweep_id = wandb.sweep(sweep_config, project=sweep_config['project_name']) wandb.agent(sweep_id, run, count=3)
Here is the main code for the run function： def run(): ..... args = get_args_parser() nowtime = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S") wandb.init(project=sweep_config['project_name'], name=nowtime, save_code=True, config=sweep_config, group="DDP") args.learning_rate = wandb.config.learning_rate args.lr_drop_epoch = wandb.config.lr_drop_epoch args.max_epoch_num = wandb.config.max_epoch_num args.optim = wandb.config.optim net = MaskDecoderHQ(args.model_type) main(net, train_datasets, valid_datasets, args, sweep_config) wandb.finish()
Here is the code for the first part of the train function： def main(net, train_datasets, valid_datasets, args, sweep_config): misc.init_distributed_mode(args) seed = args.seed + misc.get_rank() torch.manual_seed(seed) np.random.seed(seed) random.seed(seed) ......
Then there is the output log of the model run:
wandb: WARNING Malformed sweep config detected! This may cause your sweep to behave in unexpected ways. wandb: WARNING To avoid this, please fix the sweep config schema violations below: wandb: WARNING Violation 1. Additional properties are not allowed ('metrics', 'project_name' were unexpected) Create sweep with ID: rqbqivtl Sweep URL: https://wandb.ai/.../sweeps/rqbqivtl wandb: WARNING Malformed sweep config detected! This may cause your sweep to behave in unexpected ways. wandb: WARNING To avoid this, please fix the sweep config schema violations below: wandb: WARNING Violation 1. Additional properties are not allowed ('metrics', 'project_name' were unexpected) Create sweep with ID: 31foef6f Sweep URL: https://wandb.ai/.../sweeps/31foef6f wandb: WARNING Malformed sweep config detected! This may cause your sweep to behave in unexpected ways. wandb: WARNING To avoid this, please fix the sweep config schema violations below: wandb: WARNING Violation 1. Additional properties are not allowed ('metrics', 'project_name' were unexpected) Create sweep with ID: 27tb9vkv Sweep URL: https://wandb.ai/.../sweeps/27tb9vkv wandb: WARNING Malformed sweep config detected! This may cause your sweep to behave in unexpected ways. wandb: WARNING To avoid this, please fix the sweep config schema violations below: wandb: WARNING Violation 1. Additional properties are not allowed ('metrics', 'project_name' were unexpected) Create sweep with ID: 27m6nd76 Sweep URL: https://wandb.ai/../sweeps/27m6nd76 wandb: WARNING Malformed sweep config detected! This may cause your sweep to behave in unexpected ways. wandb: WARNING To avoid this, please fix the sweep config schema violations below: wandb: WARNING Violation 1. Additional properties are not allowed ('metrics', 'project_name' were unexpected) Create sweep with ID: b0f81ait Sweep URL: https://wandb.ai/.../sweeps/b0f81ait wandb: Agent Starting Run: sofplkis with config: wandb: learning_rate: 0.0005 wandb: lr_drop_epoch: 80 wandb: max_epoch_num: 200 wandb: optim: Adam wandb: Agent Starting Run: o5mmxwkd with config: wandb: learning_rate: 0.0003 wandb: lr_drop_epoch: 80 wandb: max_epoch_num: 100 wandb: optim: Adam wandb: Agent Starting Run: 2y8wyoo9 with config: wandb: learning_rate: 0.0001 wandb: lr_drop_epoch: 40 wandb: max_epoch_num: 150 wandb: optim: Adam wandb: Agent Starting Run: mewgkh87 with config: wandb: learning_rate: 0.0001 wandb: lr_drop_epoch: 100 wandb: max_epoch_num: 100 wandb: optim: SGD wandb: Agent Starting Run: 0ukaa50c with config: wandb: learning_rate: 0.0005 wandb: lr_drop_epoch: 100 wandb: max_epoch_num: 150 wandb: optim: SGD wandb: WARNING Malformed sweep config detected! This may cause your sweep to behave in unexpected ways. wandb: WARNING To avoid this, please fix the sweep config schema violations below: wandb: WARNING Violation 1. Additional properties are not allowed ('metrics', 'project_name' were unexpected) Create sweep with ID: lqiseifr Sweep URL: https://wandb.ai/.../sweeps/lqiseifr wandb: Currently logged in as: .... . Use wandb login --relogin to force relogin wandb: WARNING Ignored wandb.init() arg project when running a sweep. wandb: Currently logged in as: .... . Use wandb login --relogin to force relogin wandb: WARNING Ignored wandb.init() arg project when running a sweep. wandb: Currently logged in as: .... . Use wandb login --relogin to force relogin wandb: WARNING Ignored wandb.init() arg project when running a sweep. wandb: Currently logged in as: .... . Use wandb login --relogin to force relogin wandb: WARNING Ignored wandb.init() arg project when running a sweep. wandb: Agent Starting Run: mjo15l5x with config: wandb: learning_rate: 0.0004 wandb: lr_drop_epoch: 60 wandb: max_epoch_num: 200 wandb: optim: SGD wandb: Currently logged in as: .... . Use wandb login --relogin to force relogin wandb: WARNING Ignored wandb.init() arg project when running a sweep. wandb: - Waiting for wandb.init()... wandb: - Waiting for wandb.init()... wandb: \ Waiting for wandb.init()... wandb: \ Waiting for wandb.init()... wandb: Currently logged in as: .... . Use wandb login --relogin to force relogin wandb: WARNING Ignored wandb.init() arg project when running a sweep. wandb: Tracking run with wandb version 0.17.1 wandb: Run wandb offline to turn off syncing. wandb: Syncing run 2024-06-18 02:10:19 wandb: ⭐ View project at https://wandb.ai/... wandb: 🧹 View sweep at https://wandb.ai/.../sweeps/lqiseifr wandb: 🚀 View run at https://wandb.ai/.../runs/mjo15l5x wandb: Tracking run with wandb version 0.17.1 wandb: Run wandb offline to turn off syncing. wandb: Syncing run 2024-06-18 02:10:17 wandb: ⭐ View project at https://wandb.ai/... wandb: 🧹 View sweep at https://wandb.ai/.../sweeps/31foef6f wandb: 🚀 View run at https://wandb.ai/.../runs/o5mmxwkd
From the output logs, my guess is that each GPU running the model code creates a new sweat id, and each sweat id in turn scans all the hyperparameter combinations I've set up, but I actually only need one sweat id that scans a set of hyperparameter combinations, but since I'm going to be going into my run in the sweat.agent() function part of the code function part of the code, so it's a bit of an ordering problem, but there's no solution yet!

Jason Davenport 评论道： 嗨，内部人员，
由于尚未收到您的回复，我们希望就您的支持请求与您联系。如果我们可以提供进一步的帮助或您的问题已得到解决，请告知我们。
最佳、 权重和偏差

Sorry about that, I'm busy with other things these days, I'll be the first to try out what you've suggested when it's done, and I'll be the first to let you know of any other problems or successful runs, thank you very much for your help!

Jason Davenport commented: Hi Internal,
We wanted to follow up with you regarding your support request as we have not heard back from you. Please let us know if we can be of further assistance or if your issue has been resolved.
Best, Weights & Biases

Sorry about that, I'm busy with other things these days, I'll be the first to try out what you've suggested when it's done, and I'll be the first to let you know of any other problems or successful runs, thank you very much for your help!


Mattermost Notifications - Test Works / No Actual Notifications

⚠ Please verify that this bug has NOT been raised before.

[X] I checked and didn't find similar issue

🛡 Security Policy

[X] I agree to have read this project Security Policy

📝 Describe your problem
Mattermost Notifications are enabled using a Webhook in Mattermost.  Uptime Kuma test notifications work:

This notification is the default enabled and apply on all existing:

I use various TCP and HTTPS probes that have the notification enabled:

I've had several state changes, but no notifications.

This is not a new issue.  I setup Uptime Kuma in May 2023, have not had a single notification yet.
📝 Error Message(s) or Log
No error messages are logged.
🐻 Uptime-Kuma Version
1.22.1
💻 Operating System and Arch
Ubuntu 22.04 X86
🌐 Browser
Firefox 114.0.1 (64-bit)
🐋 Docker Version
Containerd / K3s v1.26.6+k3s1
🟩 NodeJS Version
No response

What kind of retry-policy have you set?

Note that the Mattermost provider has a lot of code which is different between these two notifications:
https://github.com/louislam/uptime-kuma/blob/19873e5b9e069050dcb68fc0aae590782aa3b146/server/notification-providers/mattermost.js#L15-L19
vs
https://github.com/louislam/uptime-kuma/blob/19873e5b9e069050dcb68fc0aae590782aa3b146/server/notification-providers/mattermost.js#L23-L101
If mattermost changed their API, could you potentially run tests which of these parameters caused this regression? (I don't have a working mattermost instance)
(I suspect it could be monitorJSON.name + " " + mattermostUserName being passed as username instead of mattermostUserName)
Their Docs are not super clear about this parameter:

The Enable integrations to override usernames configuration setting must be enabled for the username override to take effect.

I found this issue: https://github.com/louislam/uptime-kuma/issues/3273
@ankitjilka what version of mattermost are you running?

What kind of retry-policy have you set?

* What do the logs say when delivering the notifications?

There is nothing obvious in the logs about notifications with default logging:
==> Performing startup jobs and maintenance tasks
==> Starting application with user 0 group 0
Welcome to Uptime Kuma
Your Node.js version: 16
2023-07-05T11:05:05-04:00 [SERVER] INFO: Welcome to Uptime Kuma
2023-07-05T11:05:05-04:00 [SERVER] INFO: Node Env: production
2023-07-05T11:05:05-04:00 [SERVER] INFO: Importing Node libraries
2023-07-05T11:05:05-04:00 [SERVER] INFO: Importing 3rd-party libraries
2023-07-05T11:05:06-04:00 [SERVER] INFO: Creating express and socket.io instance
2023-07-05T11:05:06-04:00 [SERVER] INFO: Server Type: HTTP
2023-07-05T11:05:06-04:00 [SERVER] INFO: Importing this project modules
2023-07-05T11:05:06-04:00 [NOTIFICATION] INFO: Prepare Notification Providers
2023-07-05T11:05:06-04:00 [SERVER] INFO: Version: 1.22.1
2023-07-05T11:05:06-04:00 [DB] INFO: Data Dir: ./data/
2023-07-05T11:05:06-04:00 [SERVER] INFO: Connecting to the Database
2023-07-05T11:05:06-04:00 [DB] INFO: SQLite config:
[ { journal_mode: 'wal' } ]
[ { cache_size: -12000 } ]
2023-07-05T11:05:06-04:00 [DB] INFO: SQLite Version: 3.41.1
2023-07-05T11:05:06-04:00 [SERVER] INFO: Connected
2023-07-05T11:05:06-04:00 [DB] INFO: Your database version: 10
2023-07-05T11:05:06-04:00 [DB] INFO: Latest database version: 10
2023-07-05T11:05:06-04:00 [DB] INFO: Database patch not needed
2023-07-05T11:05:06-04:00 [DB] INFO: Database Patch 2.0 Process
2023-07-05T11:05:06-04:00 [SERVER] INFO: Load JWT secret from database.
2023-07-05T11:05:06-04:00 [SERVER] INFO: Adding route
2023-07-05T11:05:06-04:00 [SERVER] INFO: Adding socket handler
2023-07-05T11:05:06-04:00 [SERVER] INFO: Init the server
2023-07-05T11:05:06-04:00 [SERVER] INFO: Listening on 3001
Start cloudflared
2023-07-05T15:05:07Z INF Starting tunnel tunnelID=<redacted>
2023-07-05T15:05:07Z INF Version 2023.5.1
2023-07-05T15:05:07Z INF GOOS: linux, GOVersion: go1.19.6, GoArch: amd64
2023-07-05T15:05:07Z INF Settings: map[no-autoupdate:true token:*****]
2023-07-05T15:05:07Z INF cloudflared will not automatically update if installed by a package manager.
2023-07-05T15:05:07Z INF Generated Connector ID: <redacted>
2023-07-05T15:05:07Z INF Initial protocol quic
2023-07-05T15:05:07Z INF ICMP proxy will use <IP_ADDRESS> as source for IPv4
2023-07-05T15:05:07Z INF ICMP proxy will use fe80::7c34:34ff:fe6c:7e3a in zone eth0 as source for IPv6
2023-07-05T15:05:07Z INF Starting metrics server on <IP_ADDRESS>:40669/metrics
2023-07-05T15:05:07Z WRN Your version 2023.5.1 is outdated. We recommend upgrading it to 2023.6.1
2023-07-05T15:05:07Z INF Registered tunnel connection connIndex=0 connection=30a80d0b-a385-40ea-8a86-cb78d7199e57 event=0 ip=<IP_ADDRESS> location=ORD protocol=quic
2023-07-05T15:05:07Z INF Updated to new configuration config="{\"ingress\":[{\"hostname\":\"uptime.<redacted>",\"originRequest\":{},\"service\":\"http://uptime-kuma.uptime-kuma.svc:3001\"},{\"service\":\"http_status:404\"}],\"warp-routing\":{\"enabled\":false}}" version=2
2023-07-05T15:05:07Z INF Registered tunnel connection connIndex=1 connection=<redacted> event=0 ip=<IP_ADDRESS> location=IAD protocol=quic
2023-07-05T15:05:08Z INF Registered tunnel connection connIndex=2 connection=<redacted> event=0 ip=<IP_ADDRESS> location=ORD protocol=quic
2023-07-05T15:05:09Z INF Registered tunnel connection connIndex=3 connection=<redacted> event=0 ip=<IP_ADDRESS> location=IAD protocol=quic
2023-07-05T14:05:31-04:00 [AUTH] INFO: Login by token. IP=<IP_ADDRESS>
2023-07-05T14:05:31-04:00 [AUTH] INFO: Username from JWT: <redacted>
2023-07-05T14:05:32-04:00 [AUTH] INFO: Successfully logged in user <redacted>. IP=<IP_ADDRESS>
2023-07-05T14:06:07-04:00 [AUTH] INFO: Login by token. IP=<IP_ADDRESS>
2023-07-05T14:06:07-04:00 [AUTH] INFO: Username from JWT: <redacted>
2023-07-05T14:06:07-04:00 [AUTH] INFO: Successfully logged in user <redacted>. IP=<IP_ADDRESS>
2023-07-05T14:12:07-04:00 [MONITOR] INFO: Get Monitor: 3 User ID: 1
2023-07-05T14:12:34-04:00 [MONITOR] INFO: Get Monitor: 7 User ID: 1
2023-07-05T14:29:01-04:00 [MONITOR] INFO: Get Monitor: 7 User ID: 1
2023-07-05T14:33:45-04:00 [MONITOR] INFO: Get Monitor: 7 User ID: 1
2023-07-05T16:33:08-04:00 [AUTH] INFO: Login by token. IP=<IP_ADDRESS>
2023-07-05T16:33:08-04:00 [AUTH] INFO: Username from JWT: <redacted>
2023-07-05T16:33:08-04:00 [AUTH] INFO: Successfully logged in user <redacted>. IP=<IP_ADDRESS>
2023-07-05T16:33:25-04:00 [MONITOR] INFO: Get Monitor: 7 User ID: 1

The log excerpt you showed is not overlapping with the log in the screenshot above. (could you update the out of date screenshot to make this correlatable?)
What mattermost version are you running?

Mattermost Version:
Mattermost Version: 7.10.1
Database Schema Version: 108
Database: postgres

WebHook Config:

The log excerpt you showed is not overlapping with the log in the screenshot above. (could you update the out of date screenshot to make this correlatable?)

That was 100% of the log I have.  I upgraded to latest version before opening issue which seems to have reset my log.   I'll get another log capture within an outage range.

Hmm...
I just went through the Mattermost changelog ⇒ no recent, relevant change

you can provoke an "outage" by for example, adding a monitor for doesnotexist.com and then "fixing it" by changing the monitored site to google.com
Is the mattermost log displaying any errors?
My hunch is still that this is about the username field. Could you try:

enabling this setting
Try changing your mattermostUserName to monitorJSON.name + " " + mattermostUserName

Thank you for the suggestions.  I'll work on this tomorrow and report back.

you can provoke an "outage" by for example, adding a monitor for doesnotexist.com and then "fixing it" by changing the monitored site to google.com

Hah... well.  doesnotexist.com does exist and gave me an "UP". :)    I then I changed the URL to break it.  The  following was logged:
2023-07-06T08:32:39-04:00 [MONITOR] WARN: Monitor #23 'doesnotexistatall.com': Pending: getaddrinfo ENOTFOUND doesnotexistatall.com | Max retries: 1 | Retry: 1 | Retry Interval: 60 seconds | Type: http

2023-07-06T08:33:40-04:00 [MONITOR] WARN: Monitor #23 'doesnotexistatall.com': Failing: getaddrinfo ENOTFOUND doesnotexistatall.com | Interval: 60 seconds | Type: http | Down Count: 0 | Resend Interval: 0

And rec'd my 1st ever Mattermost Uptime Kuma alert:

I then changed it to google.com, and got an alert:

There is nothing logged about notifications....
2023-07-06T08:31:57-04:00 [MONITOR] INFO: Get Monitor: 23 User ID: 1
2023-07-06T08:32:21-04:00 [MONITOR] INFO: Get Monitor: 23 User ID: 1
2023-07-06T08:32:39-04:00 [MANAGE] INFO: Resume Monitor: 23 User ID: 1
2023-07-06T08:32:39-04:00 [MONITOR] INFO: Get Monitor: 23 User ID: 1
2023-07-06T08:32:39-04:00 [MONITOR] WARN: Monitor #23 'doesnotexistatall.com': Pending: getaddrinfo ENOTFOUND doesnotexistatall.com | Max retries: 1 | Retry: 1 | Retry Interval: 60 seconds | Type: http
2023-07-06T08:33:40-04:00 [MONITOR] WARN: Monitor #23 'doesnotexistatall.com': Failing: getaddrinfo ENOTFOUND doesnotexistatall.com | Interval: 60 seconds | Type: http | Down Count: 0 | Resend Interval: 0
2023-07-06T08:34:40-04:00 [MONITOR] WARN: Monitor #23 'doesnotexistatall.com': Failing: getaddrinfo ENOTFOUND doesnotexistatall.com | Interval: 60 seconds | Type: http | Down Count: 0 | Resend Interval: 0
2023-07-06T08:35:40-04:00 [MONITOR] WARN: Monitor #23 'doesnotexistatall.com': Failing: getaddrinfo ENOTFOUND doesnotexistatall.com | Interval: 60 seconds | Type: http | Down Count: 0 | Resend Interval: 0
2023-07-06T08:36:11-04:00 [MONITOR] INFO: Get Monitor: 23 User ID: 1
2023-07-06T08:36:31-04:00 [MANAGE] INFO: Resume Monitor: 23 User ID: 1
2023-07-06T08:36:31-04:00 [MONITOR] INFO: Get Monitor: 23 User ID: 1

So I have no idea why I haven't rec'd actual alerts before.   I'll keep an eye on services and report back on next outage.
Thank you for the assistance.

given that I think this issue is resolved, could you close this issue and repopen it if you find that the issue persists?

Sure. Thanks again.

I got the same problem and don't know how to fix. Test messages comes up but breakdown is not no report nothing any idea?


[MLIR] add dot offloads with manual tuning support

This commit adds dot + pointwise fusion support
along with manual tuning using rocMLIR.
Usage
Non-tuning (heuristic mode) default flow
MIGRAPHX_ENABLE_MLIR=1 ./bin/migraphx-driver perf --onnx ../models/model_torch_export_fp32.onnx --fill1 input_ids --input-dim @input_ids 1 384

This would show warnings that the current compilation is not using tuning db as follows :
Compiling ...
Reading: ../models/model_torch_export_fp32.onnx
WARNING: MLIR tuning db not found. Please set MIGRAPHX_MLIR_TUNING_DB for optimal performance.
fails to set param ongfx90a:sramecc+:xnack-	-transA false -transB false -g 1 -m 384 -n 768 -k 768 -t f32
WARNING: MLIR tuning db not found. Please set MIGRAPHX_MLIR_TUNING_DB for optimal performance.
....

The manual tuning process
Obtain the tuning configuration for the model
MIGRAPHX_ENABLE_MLIR=1 MIGRAPHX_MLIR_TUNING_CFG=bert.cfg ./bin/migraphx-driver compile --onnx ../models/model_torch_export_fp32.onnx --fill1 input_ids --input-dim @input_ids 1 384

This will create at most two files:

bert.cfg.gemm
bert.cfg.conv (if fused convs were present in the model -- no for bert case)

Tune using helper python scripts of rocMLIR

checkout https://github.com/ROCmSoftwarePlatform/rocMLIR
build using the target : ninja check-rocmlir-build-only ci-performance-scripts
tune using the configs from the previous step

cd build
./bin/tuningRunner.py --op=gemm --configs_file=/var/mkarunar/work/AMDMIGraphX/build/bert.cfg.gemm --output=bt.tsv --verify-mode=none
# if convs were present
./bin/tuningRunner.py --op=conv --configs_file=/var/mkarunar/work/AMDMIGraphX/build/bert.cfg.conv --output=bt.tsv --verify-mode=none

Note : even if the .cfg has duplicated lines, the tuning will not perform duplicated tuning and it will append .tsv files. Therefore, one could do this for several models and obtain a single database file.
Use tuning db with MIGraphX
MIGRAPHX_ENABLE_MLIR=1 MIGRAPHX_MLIR_TUNING_DB=/var/mkarunar/work/rocMLIR/build/bt.tsv ./bin/migraphx-driver perf --onnx ../models/model_torch_export_fp32.onnx --fill1 input_ids --input-dim @input_ids 1 384

Ideally the above command should not give any warning as we expect all the problem configs to be found in the tuned database.
closes : https://github.com/ROCmSoftwarePlatform/llvm-project-private/issues/823 (more like not needed now if we can make this work)

Also, make sure make tidy is clean on this PR.

Thanks @pfultz2 for detailed review. much appreciated.. (Im also picking part of this code up).
I've addressed all comments except the tuning table lifetime concern. From what I can see, mlir compiler is a static set of functions to be called through out compiling the whole graph.

Actually this should be a static variable so we only read the db file once and not everytime we do a mlir compile.

Whilst I agree with you we should only be creating the tuning table once per compilation, I dont see an immediate way to to such an init and destroy -- also personally not a fan of global static here but then I dont see non-invasive way (i.e. outside the build ifdef guard) to inject mlir things to compile flow.
Any suggestions ?
(I've added the destroy tuning table functionality for now -- so it doesn't live beyond a single mlir_program)

Whilst I agree with you we should only be creating the tuning table once per compilation, I dont see an immediate way to do such an init and destroy -- also personally not a fan of a static var here but then I dont see non-invasive way (i.e. outside the build ifdef guard) to inject mlir things to compile flow. If you insist, I could add that.

Just add it as a static variable to get_module_tuned:
bool get_module_tuned() const
{
    static auto tuning_table = create_tuning_table();
    if(!mlirRockTuningSetFromTable(tuning_table.get(), mmodule.get()))
    {
        const char* prob_config = mlirRockTuningGetKey(tuning_table, mmodule.get());
        std::stringstream key(prob_config);
        std::cerr << "fails to set param on" << prob_config << std::endl;
        dump_tuning_cfg(prob_config);
        return false;
    }
    return true;
}

Just add it as a static variable to get_module_tuned:

Done.
This change requires a bump to rocMLIR commit as well (which is done here).
Will the CI build the docker images ?

Lately we've been clearing the cache manually.  Not sure why it hasn't been doing that automatically

@causten I did clear the caches w.r.t this branch (though it wasn't that much roughly 300ish mbs).
Although, if you look at GH actions they just fail in post-run docker caching step -- IIUC, the checks have passed.
What are the next steps here ?


Add MxxUniversity

@MxxUniversity I am sorry, this request has signs of fraud. I have to close it without merging. If you are a student of this school, please apply with official document ("OFFICIAL DOCUMENT" tab at https://www.jetbrains.com/shop/eform/students).


Relax spawn_after parameter

With RTIC 1.0 if you use embedded_time on your Monotonic impl any call to task::spawn_after(...) has to put a .into() after the time type.
task::spawn_after(Milliseconds(250).into())

This is because the implementation of Monotonic requires using embedded_time::duration::Generic for the Duration associated type. This PR changes the bounds on the spawn_after function to take any type that can be converted into the target duration type. Removing the need to type all the into()s.
There are some backward-compatibility concerns since any code that previously used .into() will now fail the type inference. I'm also not sure how this affects the type inference for any Monotonic using fugit since I don't have a firmware repo to test with that.

This seems fine to me.
But it would be good to check if this had any negative effects such as increased size when the concrete type is not available anymore and must go through a trait.
Both for embedded time and fugit.

Also, could you add a changelog line so it passes CI?

Sure thing! I've pushed the update.

Was there any size increase when using embedded time or fugit in this way?

fugit will not work with Into


Unable to change log level in hass addon

Description of the issue
Bulk logging by zigbee2mqtt is killing my sd cards.
zigbee2mqtt docs state that log level is adjusted by config entry
advanced:
  log_level: warn

I have Pi with hass os and I've tried to go into addon config, edit as yaml and add that entry but it doesn't seem to have any effect and supervisor logs show that
22-09-11 22:52:59 WARNING (MainThread) [supervisor.addons.options] Option 'advanced' does not exist in the schema for Zigbee2MQTT (45df7312_zigbee2mqtt)

So how do I set it?
Addon version
v1.27.2-1
Platform
Home Assistant 2022.9.4
Supervisor 2022.08.6
Operating System 9.0
Frontend 20220907.2 - latest
Logs of the issue (if applicable)
No response

You can change it via the z2m frontend


DNS over TCP not working with targetPort names

https://github.com/pascaliske/helm-charts/blob/2032965517ddfe74f04093db7acc7f1efd33103d/charts/cloudflared/templates/service-dns-tcp.yaml#L22
I just upgraded to the latest version of the chart, and noticed that DNS via TCP was no longer working.
$ dig @<IP_ADDRESS> suse.de +tcp
;; Connection to <IP_ADDRESS>#53(<IP_ADDRESS>) for suse.de failed: connection refused.

Editing the service and changing targetPort: dns-tcp to targetPort: 5053 immediately restores the connectivity.
Funnily enough, for dns-udp it is working even with the name for the targetPort... :-)

Somehow the deployment was stuck on an old state, where the port was called dns and not dns-tcp.
Deleting the deployment and upgrading via helm and everything was fine again.


Jvega/reshape rm on device

Ticket
Solves the following issues (and potentially others, still going through and testing opened issues):
https://github.com/tenstorrent/tt-metal/issues/13889
https://github.com/tenstorrent/tt-metal/issues/12153
https://github.com/tenstorrent/tt-metal/issues/14676
https://github.com/tenstorrent/tt-metal/issues/15048
https://github.com/tenstorrent/tt-metal/issues/15269
https://github.com/tenstorrent/tt-metal/issues/14515
https://github.com/tenstorrent/tt-metal/issues/14513
Problem description
Reshape OP was re-written from scratch and has no host fallback during legal uses
What's changed
Complete re-write of reshape OP - Sweep pass rate is 98.57%
Checklist

[ ] Post commit CI passes https://github.com/tenstorrent/tt-metal/actions/runs/12088953624
[ ] Blackhole Post commit (if applicable)
[ ] Model regression CI testing passes (if applicable)
[ ] Device performance regression CI testing passes (if applicable) https://github.com/tenstorrent/tt-metal/actions/runs/12088938158
[ ] New/Existing tests provide coverage for changes

Sweep tests are showing 98.57% on this branch for reshape

Update to those waiting on this PR. This generality push while in the average case has been found to improve in perf (no host fallback!), some perf tests have slightly diminished perf compared to the previous implementation. This is partially due to the fact some of the bug fixes unavoidably increase compute time and thus I hope the other enhancements will compensate. I have a group of optimizations I have envisioned to be applied, one was pushed last week which implements this in multiple cores that brought us very close to passing all tests. Hopefully will be able to reach the targets when all have been implemented.

In particular the biggest culprit is fixing the PCC errors. We were in an unsafe manner doing only metadata changes when only a small, but not zero, amount of data movement was required. This means it was a coin flip if enough data corruption would occur to trigger a PCC assertion or not. However removing this super unsafe error resulting in corruption means some functions went from a 0 cost metadata change to an on-device reshape which is more expensive (not as bad as in-host but still pretty bad).

I believe the perf issue is really a non-issue. I have checked the code of the device perf test and it looks like it uses tracy to record only the device execution times without consideration for host fallback and synchronization delays. As we have moved reshape to being always on device, in the old code, the times when it would rely on host fallback would have recorded a device execution time of 0ns even though the model overall took much much longer to run. I have reduced the expected device times to account for this.

It means in every case that torch would also support, that is that the logical volume does not change

To highlight the prevalence of host fallback, according to sweeps 11% of all sweep tests from the models team required fallback on host in the implementation currently on main. This is after the previously merged view operation eliminated many of them.

37 commits :) , squash to 1 commit?
e.g.,
"#0 : beast mode re-shape re-write for perf improvements and 98.57% pass rate"

37 commits :) , squash to 1 commit?
e.g., "#issue : beast mode re-shape re-write for perf improvements and 98.57% pass rate"

Yup, doing a squash and merge now

37 commits :) , squash to 1 commit?
e.g.,
"#issue : beast mode re-shape re-write for perf improvements and 98.57% pass rate"

This would be an amazing commit message


[BUG] Fix duplicate test_remove_columns_strange_cols()

Brief Description

There are two test_remove_columns_strange_cols(). The second one should be testing (and named?) for multilevel dataframes.

Currently the second defined test runs, but when renamed, the first test fails. Perhaps @dave-frazzetto  or someone else could look into why the first test fails.

@hectormz if necessary, please feel free to disable the test by marking it as pytest.mark.skip, and then note in the reason field why (and saying "Not sure why it's failing" is totally ok). We can then repurpose this issue as a code sprint issue.

@ericmjl will do. Should I leave this issue open until the sprint, or just remember to revisit any skipped tests at that time?

@hectormz whoopsies, I totally left this thread hanging!
Yes, let's leave this issue open for the time being. Seeing as there's no sprint, we can just leave it hanging for the moment. (I don't mind having long-standing issues on the repo at this moment in time, though that might change.)

No worries, I forgot about it too!

@ericmjl I looked at it a bit. So this was introduced in #217 . At that point, both tests were added, and the second test overwrote the first, so there was no issue.
The test in question fails, because we're trying to drop a list containing a string and another list:
def test_remove_columns_strange_cols(dataframe):
    df = dataframe.remove_columns(
        column_names=[
            "a",
            ["Bell__Chart", "decorated-elephant", "animals@#$%^", "cities"],
        ]
    )

The expected behavior is to have all of these columns dropped.
But pandas drop() seems to only be able to drop a string, or a list of strings.
I'm not sure what an acceptable solution to this (one is to delete the test 😊). We could flatten any sequences intended to be dropped. But the test underneath is intended to test the ability to drop multilevel dataframe columns:
    df = multilevel_dataframe.remove_columns(
        column_names=[("bar", "one"), ("baz", "two")]
    )

Something like this would satisfy the tests:
    for col in column_names:
        df.drop(columns=col, inplace=True)
    return df

But I don't think we want to do inplace=True, and we also need to check if column_names is a str, and not a sequence, and needs to be packaged in a list first.
Incidentally, I don't think #189 was ever closed as a result of the original PR, although it should have been.
Function:
https://github.com/ericmjl/pyjanitor/blob/56c6f48cab5f1c2878b5ee8e4c9f5b0d17f3735c/janitor/functions.py#L1522
Tests:
https://github.com/ericmjl/pyjanitor/blob/7333b0ce1e28bb1422c89b30810e54f2aa6d2541/tests/functions/test_remove_columns.py#L36


canceledQuantity of event Cancel wrong

Bug is find in function cancel in class OrderBook:
public void cancel(long orderId, long size) {
        Order order = orders.get(orderId);
        if (order == null)
            return;

        long remainingQuantity = order.getRemainingQuantity();

        if (size >= remainingQuantity)
            return;

        if (size > 0) {
            order.resize(size);
        } else {
            delete(order);

            orders.remove(orderId);
        }

        listener.cancel(orderId, remainingQuantity - size, size);
    }

Because remainingQuantity in Order get from Long2ObjectOpenHashMap<Order> orders difference with Order get from Long2ObjectRBTreeMap<PriceLevel> bids or Long2ObjectRBTreeMap<PriceLevel> asks. Then, value return canceledQuantity = remainingQuantity - size is wrong.

huge risk, it can return 2 event and the remain will make balance do not match exactly. :( poor you guys. Pls check order in both bid and ask before returning the event cancel

Closing this issue due to inactivity.


Test

Description
Please include the following:

A meaningful PR title guidelines
A summary of the change
Which issue is fixed (if there is one)
Relevant motivation and context

How can this be tested?
Please include some guiding steps on how to test this change during a review.

What environment is necessary for the change to be noticeable ?
What needs to be enabled/applied for the change to be noticeable ?

Checklist

[ ] Unit tests have been updated/added
[ ] PR is labeled accordingly with a single label
[ ] I have read and understood the contribution guidelines

Codecov Report

Merging #2075 (adf6daa) into main (84be803) will not change coverage.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the GitHub App Integration for your organization. Read more.
@@           Coverage Diff           @@
##             main    #2075   +/-   ##
=======================================
  Coverage   63.13%   63.13%
=======================================
  Files         242      242
  Lines       15321    15321
=======================================
  Hits         9673     9673
  Misses       4908     4908
  Partials      740      740


No Integration to HomeKit with Homebridge v1.6.1

The plugin can be integrated into Homebridge v1.6.1 and you can see all devices in Homebridge.
As soon as you want to integrate the bridge into Homekit, the error "Device cannot be added. Device is not compatible" ("Gerät kann nicht hinzugefügt werden. Gerät ist nicht kompatibel").
With the Homebridge v1.4.1 everything runs stable.

I have finally managed to provide a new version 0.3.0 of the plugin, which is compatible with the current versions of Homebridge.


quality setting is not respected in imagick converter

Oh, I was too quick there. It WAS and IS respected. Just misunderstood my own code, when looking at it :)


modifed user model and add jwt generation process

Modified the user model, validation using validator, generation of jwt added.

@sounak07 can you submit another PR and fix all the linting issues created by this PR?

I guess for that i have to use editorconfig and eslint, i saw these two being added in the recent commit. But i don't know how to use them. can you please tell me how to use those ?

Yes, install editorconfig and eslint plugins in your IDE and enable them.


Support Android R/API 30 DisplayCutout Rects

Continued from https://github.com/flutter/flutter/issues/56599
Android R includes new API getBoundingRect<direction>() to get rects that are obscured by cutouts. We should look to expose this in a way that is also compatible with iOS, which may not yet be possible.

Specifically https://developer.android.com/reference/android/view/DisplayCutout#getBoundingRects()

Any updates on this? I believe this could solve the problem of the issue: https://github.com/flutter/flutter/issues/46486#issuecomment-799790415
So it would be more of a bug than a new feature request.

@Piinks @pedromassangocode @TahaTesser
This is still an issue also when using the in Flutter 2.5.x release new SystemChrome.setEnabledSystemUIMode(SystemUiMode.immersive) mode. The mode works correctly, but not on notched Android devices. Same situation if trying with Channel master, 2.6.0-12.0.pre.758.
I did a test using SystemChrome.setEnabledSystemUIMode(SystemUiMode.immersive) mode with:

Emulator Pixel 3XL (Android 11, SDK30) - FAIL
Emulator Pixel 3XL (Android 10, SDK29) - FAIL
Emulator Pixel 3XL (Android 9, SDK28) - FAIL
Emulator Pixel 3XL (Android 8.1, SDK27) - OK

Expected results
Expected to see the top status bar icons removed and UI reclaimed like on Android 8.1 SDK API 27 level example. Where it probably works because the API level is not aware of any notched screens at all.
Actual results
Instead we get a black bar on top where the top system status UI icons were, on the side of the notch, and not the fully expected immersive look.

On a device without a notch the  SystemChrome.setEnabledSystemUIMode(SystemUiMode.immersive) works well though and I get a full screen without status bar and system navigation bar, all the way down to a Nexus 7, with Android 6.01 API SDK 23.

Code sample
Used the standard counter app with SystemChrome.setEnabledSystemUIMode(SystemUiMode.immersive) added to it.
import 'package:flutter/material.dart';
import 'package:flutter/services.dart';

void main() {
  WidgetsFlutterBinding.ensureInitialized();
  SystemChrome.setEnabledSystemUIMode(SystemUiMode.immersive);
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(primarySwatch: Colors.blue),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({Key? key, required this.title}) : super(key: key);
  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  int _counter = 0;

  void _incrementCounter() {
    setState(() {
      _counter++;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            const Text('ANDROID 11 - SDK30'),
            const Text('You have pushed the button this many times:'),
            Text('$_counter', style: Theme.of(context).textTheme.headline4),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child: const Icon(Icons.add),
      ), // This trailing comma makes auto-formatting nicer for build methods.
    );
  }
}

Flutter doctor
> flutter doctor -v
[√] Flutter (Channel master, 2.6.0-12.0.pre.758, on Microsoft Windows [Version 10.0.19043.1348], locale en-US)
    • Flutter version 2.6.0-12.0.pre.758 at
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 570e39d38b (2 hours ago), 2021-11-19 03:03:04 +0900
    • Engine revision a3ef1d5351
    • Dart version 2.16.0 (build 2.16.0-20.0.dev)
    • DevTools version 2.8.0

[√] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at C:\Users\mryds\AppData\Local\Android\sdk
    • Platform android-30, build-tools 30.0.3
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Community 2019 16.10.4)
    • Visual Studio at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
    • Visual Studio Community 2019 version 16.10.31515.178
    • Windows 10 SDK version 10.0.19041.0

[√] Android Studio (version 2020.3)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

[√] IntelliJ IDEA Community Edition (version 2021.2)
    • IntelliJ at C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2018.3.1
    • Flutter plugin version 62.0.3
    • Dart plugin version 212.5632

[√] VS Code (version 1.62.2)
    • VS Code at C:\Users\mryds\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.27.0

[√] Connected device (6 available)
    • Nexus 7 (mobile)                 • 0a99f5e8      • android-arm    • Android 6.0.1 (API 23)
    • SM T510 (mobile)                 • R52N906MLAV   • android-arm    • Android 11 (API 30)
    • sdk gphone x86 64 arm64 (mobile) • emulator-5554 • android-x64    • Android 11 (API 30) (emulator)
    • Windows (desktop)                • windows       • windows-x64    • Microsoft Windows [Version 10.0.19043.1348]
    • Chrome (web)                     • chrome        • web-javascript • Google Chrome 95.0.4638.69
    • Edge (web)                       • edge          • web-javascript • Microsoft Edge 95.0.1020.53
    ! Device 69ed84cd is offline.

• No issues found!

Hey @rydmike! This is a known issue: https://github.com/flutter/flutter/issues/89601
We should probably close one or the other.
From what I understand the display cutout flags are separate from the UI overlay flags, which is why it was not part of the SystemChrome updates.
I understand right now that the letterboxing is the default, https://developer.android.com/guide/topics/display-cutout. The issue I linked has a few other references as well. I think the cutout flags and the overlay flags should be used together cohesively as you suggest, it will just require implementing them in the engine and exposing them to the user so they can choose something other than the default when desired. I don't know if it should also be part of SystemChrome, will be interesting to see. :)

Hi @Piinks ok that's cool with me. I did not find the other issue, so I dropped my findings here. Great that you are already looking into it, and have already recorded the issue at a wonderful level of detail.
If your newer issue is the base for working on it, I think we could close this issue and just refer to the newer case in this situation. Normally it is the other way around, but your new issue properly documents the needed action with respect to SystemChrome.setEnabledSystemUIMode(SystemUiMode.immersive) and the cut outs.
Your newer issue will also properly solve the already closed, but not really solved old issue https://github.com/flutter/flutter/issues/46486, but actually looking closer at this one
Thanks for the wonderfully prompt reply and comment too - amazing!
BR Mike

@rydmike just to point out one thing here, while immersive mode appears to be working on SDK 27, it looks like AppBar's SafeArea is not respected (AppBar should be placed under the notch)

@vishna Good point, it is actually not fully working on SDK27. It is probably just a bit "better" because it is here being used on a phone with a cutout, with an SDK level that has no knowledge about the cut-out concept. It is probably not so likely that there are many (any?) users with a phone that has a cutout and that they would also be using SDK 27. It is probably a pretty theoretical scenario that I made with the emulators to test this.


feat(dashboard): Add thumbnails to dashboard edit draggable chart list

SUMMARY

This PR adds thumbnails to the sidebar of draggable charts in the edit dashboard view and modifies the design of the cards with and without thumbnails enabled.  Thumbnails are shown when the THUMBNAILS feature flag is enabled.  If no thumbnail has been generated, the same placeholder that's used on the chart list card view is shown.  Other changes include:

Layout updates for the text and the Added badge, when thumbnails are enabled and when they aren't.
Text is truncated and shows a tooltip when it's too long to fit in the layout.
The human-readable chart viz type is displayed instead of the machine-readable name.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Before:
https://user-images.githubusercontent.com/13007381/178516532-8830f90c-24fd-441c-a864-47c74b618df8.mov
After (thumbnails enabled):
https://user-images.githubusercontent.com/13007381/178517080-023dd336-7c35-4784-9efb-28c822a1bf08.mov
After (thumbnails disabled):
https://user-images.githubusercontent.com/13007381/178517519-89811718-34e0-4a97-85f3-17f040885f25.mov
TESTING INSTRUCTIONS

Note: Thumbnail generation is currently broken (see #20673).  In addition, there's a bug preventing the chart metadata from being downloaded (see #20684), so even if thumbnails are generated, any items in the draggable chart list with missing metadata won't show thumbnails either.

Run Superset with feature flag THUMBNAILS=False and ensure that the updated cards look and work as expected when added and not added to the dashboard.
Run Superset with THUMBNAILS=True and ensure that thumbnails appear (or at least that their placeholders do) as expected and that the updated cards look and work as expected when added and not added to the dashboard.

ADDITIONAL INFORMATION

[ ] Has associated issue:
[x] Required feature flags: THUMBNAILS
[x] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[x] Introduces new feature or API
[ ] Removes existing feature or API

@kasiazjc here's the PR!

@codyml please rebase master to fix the code coverage issue.

/testenv up FEATURE_THUMBNAILS=true

I think we need to make some layout adjustments here... I'll ping you on a separate thread to save everyone the notification headaches :)

I can't get chart snapshot on Dashboard edit list, but gets it on Charts List.
https://user-images.githubusercontent.com/2016594/176653301-6c6ccd50-06f4-47aa-bcec-b5de59d7b3eb.mov

I can't get chart snapshot on Dashboard edit list, but gets it on Charts List.
chart.snapshot.in.Dashboard.mov

Ah thanks, will look into this.

I can't get chart snapshot on Dashboard edit list, but gets it on Charts List.
chart.snapshot.in.Dashboard.mov

@zhaoyongjie Finally got around to looking into this, and it's another symptom of the missing metadata bug, which I'm going to tackle separately.  TBD if this is going to be the final fix, but if you comment out this line you should see all thumbnails and metadata appear.

/testenv up FEATURE_THUMBNAILS=true

this PR should wait for merging this.

/testenv up FEATURE_THUMBNAILS=true

@codyml the editor bar on the Dashboard cannot preview the thumbnails, but I can preview in the dashboard list.

@codyml the editor bar on the Dashboard cannot preview the thumbnails, but I can preview in the dashboard list.

@zhaoyongjie Replied about this issue above, I think this is unrelated and fixed by https://github.com/apache/superset/pull/20684, which just got merged yesterday.  Just rebased over it, can or @geido run /testenv up FEATURE_THUMBNAILS=true and see if it's fixed?

@geido found an issue with metadata still being missing, need to look into it:

/testenv up FEATURE_THUMBNAILS=true

/testenv up FEATURE_THUMBNAILS=true FEATURE_THUMBNAILS_SQLA_LISTENERS=true

/testenv up FEATURE_THUMBNAILS=true FEATURE_THUMBNAILS_SQLA_LISTENERS=true

/testenv up FEATURE_THUMBNAILS=true

@geido @zhaoyongjie Confirmed that missing metadata in ephemeral environment was due to ephemeral environment being spun up before PR was rebased over https://github.com/apache/superset/pull/20684.


update webpack and svgo dependencies

This updates to svgo 3. Because optimize now throws instead of returning an error result, error handling has been removed.
This also removes support for Webpack 4. This allows to use this.getOptions() instead of loader-utils. Also the Webpack configuration files have been updated for Webpack 5.
As of npm 9 the default lockfile format version is 3. This is now explicitly specified in .npmrc for compatibility between npm 8 and 9.
Closes #53

Hey! Thank you for taking time to do this.
@TrySound could you check whether all changes needed to upgrade to SVGO 3 are done?

I tested this manually, but that’s not ideal. Also I noticed some inconsistencies regarding code style. I could add tests (using node:test), Prettier, strict mode, type definitions, and / or GitHub actions if you like. I refrained from doing so, because IMO all is out of scope for this PR.

I was trying to keep dev setup as simple as possible because I don't want to maintain it.
On the other hand it would be good to have tests that are run on GitHub actions, if we can add them with minimal dev dependencies (ideally none). I'd turn examples into tests and maybe added some extra ones.
If you can do this as a separate PR, that would be a great help!

Released 4.0.0 with the changes. Sorry it took so long!


Meta tags data from API

Hi,
I am using razzle for SSR and I have helmet configured in my project.
For pages where I want to set content that never changes it works fine. For example on main landing page I have i.e:
<Helmet>
    <title>This is a title</title>
    <meta property="og:title" content='This is also a title' />
</Helmet>

But in case where I open a page of one post posts/:postId I want to show title and other meta tag values dynamically. The title would be the title of that post etc. but I have to wait for API response and it takes some time to fetch data and then in page source I never see meta tags with values of that post.
Here's an example of render method in Post component (I also use redux)
render() {
    const { loading, post } = this.props;

    if (loading) return <PageLoaderComponent />;

    return (
        <div>
            <Helmet><title>{post.title}</title></Helmet>
           ...
        </div>
    )
}

Once the post is fetched I see in my browser that title and other meta tags are changed but page source is 'empty' because of the that is rendered  while the post is loading.
And when I share that link to facebook or somewhere else, it doesn't pick up the meta tags, basically it's empty, there's nothing in page source.

Did you find any solution for the same? I am facing the same issue.

@avinash-tiwari Nah, not really. You need SSR to get different meta tags and static data on each 'page', and that's ok. Bit when it comes to dynamic data in meta tags, like in this case, where I need the data from the API first and then populate meta tags I faced an issue. I couldn't make it work and at the end I gave up.

@mishkeTz , I am able to solve the same issue using next.js https://nextjs.org/docs/api-reference/data-fetching/getInitialProps method. You can also take a look at this. Now I am thinking of moving to Next.js for all my future react projects.


Add patch to meta-freescale to fix fsl-image-mfgtool-initramfs

Fixes the creation of the initramfs needed by uuu/mfgtools (for initial flashing via serial downloader).
bitbake mc:imx8mp-evk:fsl-image-mfgtool-initramfs

This will create fsl-image-mfgtool-initramfs-imx8mpevk-[timestamp].rootfs.cpio.gz.u-boot in the deploy directory.

Please also bring this upstream if possible!

Please also bring this upstream if possible!

Part of this patch is already upstream https://github.com/Freescale/meta-freescale/commit/c72cb38b891cb916d3d71d86bfd0787ba947de2c but not backported to the dunfell branch.
The other fix is probably a non-issue for meta-freescale, because the uboot-imx and uboot-imx-mfgtool recipe would normally be exclusive. An image will only use one of them, avoiding the deploy conflict. The irma6-uuu recipes pose an edge case by (indirectly) depending on both recipes.


Replace API with django-rest-framework or similar

On further thought - API should be removed entirely. Not our job to provide IMO - people can address this with multiple external means (tastyppie, django-rest-framework, SQL, custom Python code). I'm going to add deprecation warnings then remove it entirely next month.

I can recommend https://github.com/izimobil/django-rest-framework-datatables if you want to migrate your datables views to django-rest-framework as well. I'm in the process of converting legacy datatables views to rest framework and the resulting code  is usually much simpler.

Wasn't aware of that django app, thanks for the recommend! Sounds like something to be considered in the future when get to tackling the API.

Any updates on this?
If can be helpful a rest documentation from another OSS helpdesk https://www.opensupports.com/apidoc/

@Mte90 I personally have not had time to investigate or implement this, I welcome volunteers to work on it and submit a PR though!

So it is moving on :-D
To me is enough to add the user rest endpoints and I am fine :-D

Yes an API based on django-rest-framework should be available in the next release 0.3.4 which should come soon once we've cleaned up some testing and what not.

Will close this ticket as part of getting ready for the next release. Thanks!


Change review comments table to group comments by submission

Issue #:
https://github.com/bcgov/met-public/issues/740
Description of changes:
Changnes review comment table to group records by submission
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the met-public license (Apache 2.0).

Codecov Report

Merging #817 (2f174dd) into main (644721f) will decrease coverage by 0.25%.
The diff coverage is 54.16%.

@@            Coverage Diff             @@
##             main     #817      +/-   ##
==========================================
- Coverage   73.79%   73.54%   -0.26%
==========================================
  Files         169      170       +1
  Lines        4293     4354      +61
  Branches      268      268
==========================================
+ Hits         3168     3202      +34
- Misses       1092     1119      +27
  Partials       33       33

Flag
Coverage Δ

metapi
78.43% <54.16%> (-0.58%)
:arrow_down:

metweb
67.17% <ø> (ø)

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

Impacted Files
Coverage Δ

met-web/src/apiManager/endpoints/index.ts
100.00% <ø> (ø)

met-api/src/met_api/models/submission.py
59.09% <38.09%> (-10.48%)
:arrow_down:

met-api/src/met_api/resources/submission.py
61.84% <56.25%> (-2.10%)
:arrow_down:

met-api/src/met_api/services/submission_service.py
81.13% <60.00%> (-2.21%)
:arrow_down:

met-api/src/met_api/resources/comment.py
66.17% <100.00%> (ø)

met-api/src/met_api/schemas/submission.py
100.00% <100.00%> (ø)

met-api/src/met_api/resources/__init__.py
100.00% <0.00%> (ø)

met-api/src/met_api/resources/value_component.py
70.58% <0.00%> (ø)


Code diff viewer doesn't work on updated versions of Chrome or Firefox

Code diff viewer doesn't work on updated versions of Chrome or Firefox. Looks like the stylesheet doesn't take any effect. Tested on OSX and Windows 10.

It looks like the problem is with accessing it over an HTTPS connection


Fix export cache issue

Resolve #1551 and #1020.
We are never returning the result of solved operations so Buildkit could not
cache the layer.
This commit implements a simple system to forward operations' result to the
main build to cache it.
Copy of #1839 but required with the public migration
Signed-off-by: Vasek - Tom C<EMAIL_ADDRESS>

Looks like it's finally possible to merge #1839 (I've hit an issue), I close this PR and we will reopen it if it's really necessary.


Allow local file access in Android webview

Required since API level 30, as they changed the default from True to False.
https://developer.android.com/reference/android/webkit/WebSettings#setAllowFileAccess(boolean)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

You can use setNativePropery for this. Do it right after creating the WebView.


Update README.md

Updated it to avoid a pitfall as seen in this issue

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks, I decided to just change the default behavior to a [yes] instead of [no] in f838eee812cb811dabf528870c434f7fbfc95a43, I think that will be even less confusing.

That would indeed be even better :)


Creating users

Bug Description
I implemented it in Docker and everything is working, I can configure the api store but when trying to create a user I receive the error:
"Error when adding new user
Method Not Allowed"
I have already carried out the local test and also installing locally but I still continue to receive this error.
I am using Chrome browser
Reproduction
Log in to the web interface.
Create a new user.
Expected behavior
Make the creation of new users go smoothly.
Who can help?
No response
Operating System
Ubuntu Server 24 and Docker
Langflow Version
1.0.16
Python Version
3.12
Screenshot

Flow File
No response

Hey @suggsadc, @Techno-Trek
Please follow up this PR: #3538
It will likely be included in the next release.
Apologies for any inconvenience.
Thank you.


code editor clears styles

Whenever you use the code editor and click save, it clears any styles that have been applied through the style manager.
I think the issue is that editor.setComponents(html); replaces any css that grapesjs had created for the page.
Is there a way to fix this?

@drexelroth which version of the package are you using?

We're using the recent version.

3.4


:seedling: Combine SAST probes into single probe

What kind of change does this PR introduce?
(Is it a bug fix, feature, docs update, something else?)

[X] PR title follows the guidelines defined in our pull request documentation

What is the current behavior?
There is one probe per SAST tool
What is the new behavior (if this is a feature change)?**
There is only one probe, and a "tool" value which describes the tool.

[X] Tests for the changes have been added (for bug fixes/features)

Which issue(s) this PR fixes
Fixes #3824

Special notes for your reviewer
Does this PR introduce a user-facing change?
For user-facing changes, please add a concise, human-readable release note to
the release-note
(In particular, describe what changes users might need to make in their
application as a result of this pull request.)

The SAST probes have been combined into a single probe. The various tools are specified by the "tool" value.

This is just a draft for now, to show the approach, as it's still being discussed in #3824.
@laurentsimon you had left a comment to me privately about how this affects remediation.

is there a way to keep the remediation tool-specific if we made the proposed changes? It's still useful if we want to be able to expand the remediation section. Also, we'd like to have a way to "auto-remediate" (piece of code that creates a diff, for example). Any thoughts how that'd work?

This is what I had in mind for the remediation aspect.
It includes a link to a doc page:
https://github.com/ossf/scorecard/blob/a8675eb9c44e8b9323a6f8ed1627b4310b72bcfd/docs/checks/sast/README.md
While this is pretty sparse, so was the remediation info beforehand. I can add a few more instructions under each entry to match what was there before:
- remediation:
-   effort: Medium
-   text:
-     - Follow the steps in https://github.com/facebook/pysa-action

- remediation:
-   effort: Medium
-   text:
-    - Follow the steps in https://github.com/snyk/actions

/scdiff generate SAST


Follow-ups from introduction of registry+v1 provisioner

AC:

[x] #428
[ ] #429
[x] #430
[ ] #431
[ ] #442 - Incorporate changes from #396

Working on updating the registry+v1 documentation now.

Documentation updated with #424

This issue was brought up in the OLM's Issue Triage Meeting due to this comment by @exdx, which points out that this has been a long living issue pulled from milestone to milestone.
@timflannagan and @tylerslaton were both in favor of closing this tracking issue and tracking each of the individual issues.
There will be a followup to determine and document how sets of issues that implement a feature will be tracked, and the issues described in this ticket will be updated to conform to the new model.


[Badge] Typescript Custom Variant does not work

[X] The issue is present in the latest release.
[X] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

Expected Behavior 🤔
Typescript should not throw error

Steps to Reproduce 🕹

https://codesandbox.io/s/ecstatic-jackson-i6z4j?file=/src/App.tsx
Your Environment 🌎

`npx @material-ui/envinfo`

  System:
    OS: macOS 10.15.6
  Binaries:
    Node: 14.7.0 - /var/folders/7w/t3q6v18575b1rncctdm639040000gn/T/fnm-shell-7427853/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.7 - /var/folders/7w/t3q6v18575b1rncctdm639040000gn/T/fnm-shell-7427853/bin/npm
  Browsers:
    Chrome: 87.0.4280.141
    Edge: Not Found
    Firefox: 84.0.1
    Safari: 14.0
  npmPackages:
    @emotion/react: 11.1.4 => 11.1.4
    @emotion/styled: 11.0.0 => 11.0.0
    @material-ui/core: v5.0.0-alpha.22 => 5.0.0-alpha.22
    @material-ui/icons: v5.0.0-alpha.22 => 5.0.0-alpha.22
    @material-ui/lab: v5.0.0-alpha.22 => 5.0.0-alpha.22
    @material-ui/styled-engine:  5.0.0-alpha.22
    @material-ui/styles:  5.0.0-alpha.22
    @material-ui/system:  5.0.0-alpha.22
    @material-ui/types:  5.1.4
    @material-ui/unstyled:  5.0.0-alpha.22
    @material-ui/utils:  5.0.0-alpha.22
    @types/react: 17.0.0 => 17.0.0
    react: 17.0.1 => 17.0.1
    react-dom: 17.0.1 => 17.0.1
    typescript: 4.1.3 => 4.1.3

Thanks for reporting @xiaoyu-tamu The problem was introduced in https://github.com/mui-org/material-ui/pull/23745 when creating the unstyled component. The problem is that the unstyled component defines the variant as a union of strings, not as overridable string union. I believe we need to move the usage of the OverridableStringUnion from the Badge component tot the BadgeUnstyled. Note that after this, the overriding path for the variant will move to the unstyled package :\  This diff will make this work:
diff --git a/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.d.ts b/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.d.ts
index a2b86fba17..a3427eeaea 100644
--- a/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.d.ts
+++ b/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.d.ts
@@ -1,4 +1,5 @@
 import * as React from 'react';
+import { OverridableStringUnion } from '@material-ui/types';
 import { OverridableComponent, OverridableTypeMap, OverrideProps } from '../OverridableComponent';

 export interface BadgeOrigin {
@@ -6,6 +7,9 @@ export interface BadgeOrigin {
   horizontal: 'left' | 'right';
 }

+export interface BadgePropsVariantOverrides {}
+export type BadgeVariantDefaults = Record<'standard' | 'dot', true>;
+
 export interface BadgeUnstyledTypeMap<P = {}, D extends React.ElementType = 'div'> {
   props: P & {
     /**
@@ -102,7 +106,7 @@ export interface BadgeUnstyledTypeMap<P = {}, D extends React.ElementType = 'div
      * The variant to use.
      * @default 'standard'
      */
-    variant?: 'standard' | 'dot';
+    variant?: OverridableStringUnion<BadgeVariantDefaults, BadgePropsVariantOverrides>;
   };
   defaultComponent: D;
 }
diff --git a/packages/material-ui/src/Badge/Badge.d.ts b/packages/material-ui/src/Badge/Badge.d.ts
index d9446e0534..abb2cd79ea 100644
--- a/packages/material-ui/src/Badge/Badge.d.ts
+++ b/packages/material-ui/src/Badge/Badge.d.ts
@@ -1,6 +1,5 @@
 import * as React from 'react';
 import { SxProps } from '@material-ui/system';
-import { OverridableStringUnion } from '@material-ui/types';
 import {
   ExtendBadgeUnstyledTypeMap,
   BadgeUnstyledTypeMap,
@@ -9,9 +8,6 @@ import {
 import { Theme } from '../styles';
 import { OverridableComponent, OverrideProps } from '../OverridableComponent';

-export interface BadgePropsVariantOverrides {}
-export type BadgeVariantDefaults = Record<'standard' | 'dot', true>;
-
 export type BadgeTypeMap<
   D extends React.ElementType = 'span',
   P = {}
@@ -38,11 +34,6 @@ export type BadgeTypeMap<
      * The system prop that allows defining system overrides as well as additional CSS styles.
      */
     sx?: SxProps<Theme>;
-    /**
-     * The variant to use.
-     * @default 'standard'
-     */
-    variant?: OverridableStringUnion<BadgeVariantDefaults, BadgePropsVariantOverrides>;
   };
   defaultComponent: D;
 }>;

I don't like that we need to move the variants logic to the unstyled component, but for this component, the variant affects the rendered tree of the component itself. Maybe we should try to refactor and move this logic to the styled version 🤷 @oliviertassinari @eps1lon what do you think?

Thanks for reporting @xiaoyu-tamu The problem was introduced in https://github.com/mui-org/material-ui/pull/23745 when creating the unstyled component. The problem is that the unstyled component defines the variant as a union of strings, not as overridable string union. I believe we need to move the usage of the OverridableStringUnion from the Badge component tot the BadgeUnstyled. Note that after this, the overriding path for the variant will move to the unstyled package :\  This diff will make this work:
diff --git a/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.d.ts b/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.d.ts
index a2b86fba17..a3427eeaea 100644
--- a/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.d.ts
+++ b/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.d.ts
@@ -1,4 +1,5 @@
 import * as React from 'react';
+import { OverridableStringUnion } from '@material-ui/types';
 import { OverridableComponent, OverridableTypeMap, OverrideProps } from '../OverridableComponent';

 export interface BadgeOrigin {
@@ -6,6 +7,9 @@ export interface BadgeOrigin {
   horizontal: 'left' | 'right';
 }

+export interface BadgePropsVariantOverrides {}
+export type BadgeVariantDefaults = Record<'standard' | 'dot', true>;
+
 export interface BadgeUnstyledTypeMap<P = {}, D extends React.ElementType = 'div'> {
   props: P & {
     /**
@@ -102,7 +106,7 @@ export interface BadgeUnstyledTypeMap<P = {}, D extends React.ElementType = 'div
      * The variant to use.
      * @default 'standard'
      */
-    variant?: 'standard' | 'dot';
+    variant?: OverridableStringUnion<BadgeVariantDefaults, BadgePropsVariantOverrides>;
   };
   defaultComponent: D;
 }
diff --git a/packages/material-ui/src/Badge/Badge.d.ts b/packages/material-ui/src/Badge/Badge.d.ts
index d9446e0534..abb2cd79ea 100644
--- a/packages/material-ui/src/Badge/Badge.d.ts
+++ b/packages/material-ui/src/Badge/Badge.d.ts
@@ -1,6 +1,5 @@
 import * as React from 'react';
 import { SxProps } from '@material-ui/system';
-import { OverridableStringUnion } from '@material-ui/types';
 import {
   ExtendBadgeUnstyledTypeMap,
   BadgeUnstyledTypeMap,
@@ -9,9 +8,6 @@ import {
 import { Theme } from '../styles';
 import { OverridableComponent, OverrideProps } from '../OverridableComponent';

-export interface BadgePropsVariantOverrides {}
-export type BadgeVariantDefaults = Record<'standard' | 'dot', true>;
-
 export type BadgeTypeMap<
   D extends React.ElementType = 'span',
   P = {}
@@ -38,11 +34,6 @@ export type BadgeTypeMap<
      * The system prop that allows defining system overrides as well as additional CSS styles.
      */
     sx?: SxProps<Theme>;
-    /**
-     * The variant to use.
-     * @default 'standard'
-     */
-    variant?: OverridableStringUnion<BadgeVariantDefaults, BadgePropsVariantOverrides>;
   };
   defaultComponent: D;
 }>;

I don't like that we need to move the variants logic to the unstyled component, but for this component, the variant affects the rendered tree of the component itself. Maybe we should try to refactor and move this logic to the styled version 🤷 @oliviertassinari @eps1lon what do you think?

@mnajdova Did you consider this solution?
diff --git a/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.d.ts b/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.d.ts
index a2b86fba17..48e2b2d5c1 100644
--- a/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.d.ts
+++ b/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.d.ts
@@ -102,7 +102,7 @@ export interface BadgeUnstyledTypeMap<P = {}, D extends React.ElementType = 'div
      * The variant to use.
      * @default 'standard'
      */
-    variant?: 'standard' | 'dot';
+    variant?: string;
   };
   defaultComponent: D;
 }
diff --git a/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.js b/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.js
index 585096889c..3f27c36d8c 100644
--- a/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.js
+++ b/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.js
@@ -206,10 +206,7 @@ BadgeUnstyled.propTypes = {
    * The variant to use.
    * @default 'standard'
    */
-  variant: PropTypes /* @typescript-to-proptypes-ignore */.oneOfType([
-    PropTypes.oneOf(['dot', 'standard']),
-    PropTypes.string,
-  ]),
+  variant: PropTypes.string,
 };

 export default BadgeUnstyled;

On a broader note:

In #24267, Sebastian has been pushing so we only augment the modules of public paths. It's already supported but required to update the documentation. When applied to the reproduction of @xiaoyu-tamu: https://codesandbox.io/s/competent-murdock-rf698.
Regarding how we will scale the solution, and e.g #13875. What are your thoughts on this pattern?

diff --git a/packages/material-ui-types/index.d.ts b/packages/material-ui-types/index.d.ts
index 378e37492a..93de7d3a0c 100644
--- a/packages/material-ui-types/index.d.ts
+++ b/packages/material-ui-types/index.d.ts
@@ -47,7 +47,7 @@ export type Omit<T, K extends keyof any> = T extends any ? Pick<T, Exclude<keyof
 *
 * @internal
 */
-export type OverridableStringUnion<T, U = {}> = GenerateStringUnion<Overwrite<T, U>>;
+export type OverridableStringUnion<T, U = {}> = GenerateStringUnion<Overwrite<Record<T, true>, U>>;

/**
 * Like `T & U`, but using the value types from `U` where their properties overlap.
diff --git a/packages/material-ui/src/Button/Button.d.ts b/packages/material-ui/src/Button/Button.d.ts
index 93b55007f7..36180c5c2f 100644
--- a/packages/material-ui/src/Button/Button.d.ts
+++ b/packages/material-ui/src/Button/Button.d.ts
@@ -4,8 +4,8 @@ import { Theme } from '../styles';
import { ExtendButtonBase, ExtendButtonBaseTypeMap } from '../ButtonBase';
import { OverrideProps, OverridableComponent, OverridableTypeMap } from '../OverridableComponent';

-export interface ButtonPropsVariantOverrides {}
-export type ButtonVariantDefaults = Record<'text' | 'outlined' | 'contained', true>;
+export interface ButtonPropsOverridesVariant {}
+export interface ButtonPropsOverridesColor {}

export type ButtonTypeMap<
  P = {},
@@ -97,7 +97,7 @@ export type ButtonTypeMap<
     * The color of the component. It supports those theme colors that make sense for this component.
     * @default 'primary'
     */
-    color?: 'inherit' | 'primary' | 'secondary';
+    color?: OverridableStringUnion<'inherit' | 'primary' | 'secondary', ButtonPropsOverridesColor>;
    /**
     * If `true`, the component is disabled.
     * @default false
@@ -145,7 +145,7 @@ export type ButtonTypeMap<
     * The variant to use.
     * @default 'text'
     */
-    variant?: OverridableStringUnion<ButtonVariantDefaults, ButtonPropsVariantOverrides>;
+    variant?: OverridableStringUnion<'text' | 'outlined' | 'contained', ButtonPropsOverridesVariant>;
  };
  defaultComponent: D;
}>;

@mnajdova Did you consider this solution?
diff --git a/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.d.ts b/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.d.ts
index a2b86fba17..48e2b2d5c1 100644
--- a/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.d.ts
+++ b/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.d.ts
@@ -102,7 +102,7 @@ export interface BadgeUnstyledTypeMap<P = {}, D extends React.ElementType = 'div
      * The variant to use.
      * @default 'standard'
      */
-    variant?: 'standard' | 'dot';
+    variant?: string;
   };
   defaultComponent: D;
 }
diff --git a/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.js b/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.js
index 585096889c..3f27c36d8c 100644
--- a/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.js
+++ b/packages/material-ui-unstyled/src/BadgeUnstyled/BadgeUnstyled.js
@@ -206,10 +206,7 @@ BadgeUnstyled.propTypes = {
    * The variant to use.
    * @default 'standard'
    */
-  variant: PropTypes /* @typescript-to-proptypes-ignore */.oneOfType([
-    PropTypes.oneOf(['dot', 'standard']),
-    PropTypes.string,
-  ]),
+  variant: PropTypes.string,
 };

 export default BadgeUnstyled;

On a broader note:

In #24267, Sebastian has been pushing so we only augment the modules of public paths. It's already supported but required to update the documentation. When applied to the reproduction of @xiaoyu-tamu: https://codesandbox.io/s/competent-murdock-rf698.
Regarding how we will scale the solution, and e.g #13875. What are your thoughts on this pattern?

diff --git a/packages/material-ui-types/index.d.ts b/packages/material-ui-types/index.d.ts
index 378e37492a..93de7d3a0c 100644
--- a/packages/material-ui-types/index.d.ts
+++ b/packages/material-ui-types/index.d.ts
@@ -47,7 +47,7 @@ export type Omit<T, K extends keyof any> = T extends any ? Pick<T, Exclude<keyof
 *
 * @internal
 */
-export type OverridableStringUnion<T, U = {}> = GenerateStringUnion<Overwrite<T, U>>;
+export type OverridableStringUnion<T, U = {}> = GenerateStringUnion<Overwrite<Record<T, true>, U>>;

/**
 * Like `T & U`, but using the value types from `U` where their properties overlap.
diff --git a/packages/material-ui/src/Button/Button.d.ts b/packages/material-ui/src/Button/Button.d.ts
index 93b55007f7..36180c5c2f 100644
--- a/packages/material-ui/src/Button/Button.d.ts
+++ b/packages/material-ui/src/Button/Button.d.ts
@@ -4,8 +4,8 @@ import { Theme } from '../styles';
import { ExtendButtonBase, ExtendButtonBaseTypeMap } from '../ButtonBase';
import { OverrideProps, OverridableComponent, OverridableTypeMap } from '../OverridableComponent';

-export interface ButtonPropsVariantOverrides {}
-export type ButtonVariantDefaults = Record<'text' | 'outlined' | 'contained', true>;
+export interface ButtonPropsOverridesVariant {}
+export interface ButtonPropsOverridesColor {}

export type ButtonTypeMap<
  P = {},
@@ -97,7 +97,7 @@ export type ButtonTypeMap<
     * The color of the component. It supports those theme colors that make sense for this component.
     * @default 'primary'
     */
-    color?: 'inherit' | 'primary' | 'secondary';
+    color?: OverridableStringUnion<'inherit' | 'primary' | 'secondary', ButtonPropsOverridesColor>;
    /**
     * If `true`, the component is disabled.
     * @default false
@@ -145,7 +145,7 @@ export type ButtonTypeMap<
     * The variant to use.
     * @default 'text'
     */
-    variant?: OverridableStringUnion<ButtonVariantDefaults, ButtonPropsVariantOverrides>;
+    variant?: OverridableStringUnion<'text' | 'outlined' | 'contained', ButtonPropsOverridesVariant>;
  };
  defaultComponent: D;
}>;

@oliviertassinari right I forgot that I shortly scanned https://github.com/mui-org/material-ui/pull/24267, falling a bit behind after the vacation 😄 Yeah, it makes sense to just use string in the unstyled, if we need to support and refactor the overrides as proposed in your comment 👍

@oliviertassinari right I forgot that I shortly scanned https://github.com/mui-org/material-ui/pull/24267, falling a bit behind after the vacation 😄 Yeah, it makes sense to just use string in the unstyled, if we need to support and refactor the overrides as proposed in your comment 👍

I don't like that we need to move the variants logic to the unstyled component, but for this component, the variant affects the rendered tree of the component itself. Maybe we should try to refactor and move this logic to the styled version

Seems to me we haven't gotten to the right abstraction if logic specific to the styled component is part of the unstyled component. I agree that the logic specific to the styled version should be part of the styled implementation. The unstyled component shouldn't know about different variants. In the end, one might want to implement a Badge without variants.

I don't like that we need to move the variants logic to the unstyled component, but for this component, the variant affects the rendered tree of the component itself. Maybe we should try to refactor and move this logic to the styled version

Seems to me we haven't gotten to the right abstraction if logic specific to the styled component is part of the unstyled component. I agree that the logic specific to the styled version should be part of the styled implementation. The unstyled component shouldn't know about different variants. In the end, one might want to implement a Badge without variants.

Seems to me we haven't gotten to the right abstraction if logic specific to the styled component is part of the unstyled component. I agree that the logic specific to the styled version should be part of the styled implementation. The unstyled component shouldn't know about different variants. In the end, one might want to implement a Badge without variants.

I second this, that is why I mentioned it. For the Badge component, the dot vs standard variant affects the rendered tree of the component itself (whether it will show the content or not for example) - it is not strictly a styling matter. On the other hand, having Badge component without this behavior, seems a bit odd, even unstyled Badge, as this seems to be what most of the badge components on the web behave like, that is why I am not sure whether we should strip things like this form the unstyled version. Maybe the problem is that this is part of the variant's logic, if it was any other prop, like a direct dot boolean prop, I wouldn't have doubts and would leave it in the unstyled component, as it somehow affects the business logic of the component.

Seems to me we haven't gotten to the right abstraction if logic specific to the styled component is part of the unstyled component. I agree that the logic specific to the styled version should be part of the styled implementation. The unstyled component shouldn't know about different variants. In the end, one might want to implement a Badge without variants.

I second this, that is why I mentioned it. For the Badge component, the dot vs standard variant affects the rendered tree of the component itself (whether it will show the content or not for example) - it is not strictly a styling matter. On the other hand, having Badge component without this behavior, seems a bit odd, even unstyled Badge, as this seems to be what most of the badge components on the web behave like, that is why I am not sure whether we should strip things like this form the unstyled version. Maybe the problem is that this is part of the variant's logic, if it was any other prop, like a direct dot boolean prop, I wouldn't have doubts and would leave it in the unstyled component, as it somehow affects the business logic of the component.


fix [mle] warnings and errors

#28

Hi @natashawatkins , would you please tell me which block has a warning?

Following 'we'll use robust standard errors'

when I'm running it locally, the jupyter file and its html is fine and I don't get any warnings:

What  version of statsmodels do you have?

@fkazemian could you try updating and rerunning this, because I don't believe I was getting the same output results

This was already done in #60 by the way

@AnjuJoon Could you please review this PR?

@jstac sure, I will review this.

@AnjuJoon If I remember correctly, you said that this pull request can be closed?  Is that right?
Thanks for all your help.

@jstac yes we can close this PR. I have made a pull request regarding this lecture but not related to this issue. This issue is not anymore in the lecture. Thanks!


Feature/cdnc 2263

What Changed?
Added support for locking down a cluster when we don't want to allow domains to be failed over to it if the cluster is already at capacity

Why?
In certain cases where clusters are already running at capacity failing over additional traffic can have harmful effects.

How did you test it?
Unit tests for both a successful failover when cluster isn't in lockdown and unit tests for failed when cluster is in lockdown.
Was also able to spin up 2 clusters using docker ui voodoo to verify end to end on local machine.

Potential Risks
Nothing should happen initially since default value is false and the blocking code will never be reached.

Release notes

Documentation Changes

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Pull Request Test Coverage Report for Build 03ccc362-fad1-4d40-b57c-44edefd7d19e

7 of 11 (63.64%)  changed or added relevant lines in 2 files are covered.
45 unchanged lines in 11 files lost coverage.
Overall coverage increased (+0.01%) to 56.993%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

service/frontend/workflowHandler.go
6
10
60.0%

Files with Coverage Reduction
New Missed Lines
%

client/history/client.go
2
39.33%

client/history/metricClient.go
2
46.37%

common/cache/lru.go
2
92.2%

common/membership/hashring.go
2
83.54%

common/task/fifoTaskScheduler.go
2
87.63%

common/task/weightedRoundRobinTaskScheduler.go
2
89.64%

service/history/handler.go
2
48.72%

service/matching/taskListManager.go
2
74.19%

service/frontend/workflowHandler.go
4
60.46%

service/history/historyEngine.go
9
70.87%

Totals

Change from base Build 8f9b3356-d4c8-414b-9232-0acd0070f65f:
0.01%

Covered Lines:
83720

Relevant Lines:
146894

💛  - Coveralls


Ship is left tilted when one of the powered balloons gets destroyed

https://youtu.be/njpYg_iC5Iw
It would still act like this even though I broke all of the balloons. Even Eureka's helm auto-stabilization couldn't get it up right:

apparently it happens only when you PLACE a balloon for the first time right next to a powered block:
https://youtu.be/mvb3Y-8QgKk


Support refresh tokens

Resolves #12
This adds supports for refresh tokens to the OAuth2 middleware.
It also splits out a dedicated OpenID Connect middleware, because it's session invalidation logic is slightly different. Up to this point I've been using the oauth2 middleware for an OpenID Connect flow, making use of the fact that we can fetch an ID token by sending an idtoken scope and then read that id token out of the session. To add refresh token support we need to be able to figure out when a session has expired though, and here the OAuth2 and OpenID implementations diverge:

For the OAuth2 flow we check the expire time of the access token.
For the OpenID Connect flow we check the expire time of the id token.

I think existing users of the OAuth2 provider probably wouldn't want their sessions to become invalidated because of some id token they might not use or know about. Conversely those looking to rely on ID tokens might not need an access token or be interested in its expiry.
I also added some test for old and new functionality of the OAuth2 and OpenID Connect providers. Happy to look into setting up some CI (maybe based on Travis?) if that seems useful!
Please let me know what you think!

You interested in being a comaintainer of this package?

Sure, happy to help! Thank you for offering!

Invite sent here on Github. What's your Hackage username?

It's JasperWoudenberg

@lehins can you grant @jwoudenberg (and myself if convenient) maintainer access on Hackage?

Done. You are both maintainers of this package on hackage.

Quick update on my radio silence here: I've been wanting to try this out on a local project before calling it 'done'. I've recently started doing that and found a couple of small issues. Working on fixing those, and then I'll get back here!

This seems to work 🎉. @lehins would you be interested in reviewing? I realize that as a maintainer I'm able to move this forward myself, but I'm not sure about the PR etiquette in this repo!

Hi @lehins, thank you so much for your feedback, and sorry for taking so long to make use of it! Going through it now. Will make updates and then release as you suggested!

Addressed feedback, rebased on master, and CI is green! Going to merge, then release!

Released as <IP_ADDRESS>

@jwoudenberg Great job! Thank you for the new release ;)


DalyBMS 8cell: wrong value min Volt

The values on a Raspberry Pi v2.73 with (since?) v0.8beta1 are not the same like the PC Windows App with the same USB-UART cable. (with v0.8 the BMS is not running)
Between the two screenshots are only some seconds apart.
Min/max difference is according v0.8beta1 since days about 0.008V - and according PC-App/Android App 0.003 V.
The min Volt seems to be too low.

additional info:

There are two things I can think of that can influence this on the Daly.
The Daly use seperate commands for each value you want, but the baud rate (speed) is actually low for the overhead. So while for most BMS we retrieve data every second, for the Daly we can only update every 2 seconds or else the data from the previous request has not finished yet. So this 2 second delay could be influencing the values that you see.
The other thing is that the Daly has a command to return just the min/max cell voltages (so not all the cells) and this is what we currently use in the driver. I think this is most likely the reason for the difference as I don't know how fast the min/max values are updated against the cell values inside the BMS.
I'll look at making a test version with the individual cell voltages at that you can check against.

I am waiting also for the individual cell voltages.


Helm operator selector does not pick updates in CR labels

Bug Report
What did you do?
I am running two separate helm operators in a Kubernetes cluster. Both should look at the same type of custom resource but should look for different labels (or a label exists or not). I installed two different selectors in the watches.yml file for both operators, one should look at the label operatorTest, the other one should not:
watches.yml
Operator A:
---
- version: v1alpha1
  group: example.org
  kind: Example
  chart: /opt/helm/helm-charts/example
  selector:
    matchExpressions:
     - {key: operatorTest, operator: In, values: ["true"]}

Operator B:
---
- version: v1alpha1
  group: example.org
  kind: Example
  chart: /opt/helm/helm-charts/example
  selector:
    matchExpressions:
     - {key: operatorTest, operator: NotIn, values: ["true"]}

I installed a custom resource without a label and it was correctly picked up and installed by operator B:
apiVersion: example.com/v1alpha1
kind: Example
metadata:
  name: example
  namespace: example
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: default-node-pool
            operator: In
            values:
            - "true"

A little later I added the operatorTest label with the value "true" to the created custom resource and I expected it to be picked up by operator A which did not happen.
  labels:
    operatorTest: "true"

I had to restart both operators, Operator B to not track the resource anymore, and Operator A to track it.
What did you expect to see?
I expected Operator A to track the resource after I added the label and Operator B to leave the work to Operator A.
What did you see instead? Under which circumstances?
I actually saw Operator B continuing doing the work and Operator A doing nothing. Only after restarting both operators the behavior was as expected.
Environment
/language helm
Kubernetes cluster type:
Kubernetes GKE instance
$ operator-sdk version
"Version","Go Version":"go1.16.8","GOOS":"linux","GOARCH":"amd64","helm-operator":"v1.12.0","commit":"d3b2761afdb78f629a7eaf4461b0fb8ae3b02860"

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.5", GitCommit:"aea7bbadd2fc0cd689de94a54e5b7b758869d691", GitTreeState:"clean", BuildDate:"2021-09-16T02:41:51Z", GoVersion:"go1.16.7", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"20+", GitVersion:"v1.20.9-gke.1001", GitCommit:"1fe18c314ed577f6047d2712a9d1c8e498e22381", GitTreeState:"clean", BuildDate:"2021-08-23T23:06:28Z", GoVersion:"go1.15.13b5", Compiler:"gc", Platform:"linux/amd64"}

Possible Solution
Based on the observations I have made, I assume the resources are only checked for their labels once at the beginning. I would suggest to check the tracked custom resources constantly for label changes if there is a label selector in the watches file for a specific label.

/remove-lifecycle rotten

As a sanity check @jberkhahn and I ran through some of this with the vanilla kube api.
I created a CRD with no labels.
In 2 terminal sessions, I established watches.
curl "<IP_ADDRESS>:8001/apis/stable.example.com/v1/namespaces/default/chonks?watch=1&labelSelector=somelabel%3D%3Da"
curl "<IP_ADDRESS>:8001/apis/stable.example.com/v1/namespaces/default/chonks?watch=1&labelSelector=somelabel%3D%3Db"
When I edited the CR for "a", watch-a received an  ADDED event as expected. watch-b received nothing.
somelabel: a
    foo: "this should be a"

When I edited the CR for "b", watch-a received a DELETED, with foo "this should be a" event as expected. watch-b received an ADDED with foo "this should be b" event.
somelabel: b
    foo: "this should be b"

That looks pretty much like we expected. I have a vague idea of what might be happening though--
When you changed the label such that OperatorB is no longer watching the CR, OperatorB recieved a DELETED event, which will trigger a reconcile. Meanwhile, OperatorA receives an ADDED event. Are the operators you are using the same? In this case, the reconcile triggered by ADDED would be a quick no-op. Keep in mind that even though OperatorA received a DELETED event, the CR isn't actually deleted, meaning that it will not trigger any garbage collection and all the subresources owned by the CR will also not trigger events. Thus, OperatorA never has a need to try to reconcile.
Could you try a few things?

Instead of changing the CR, delete the CR, wait for OperatorB to finish reconcile and then create a new CR with the new labels. This should now trigger a OperatorA I hope?
Im also curious what happens if you follow your reproducer steps and then make another change (non-label) to the CR. If what I'm describing is the cause, I suspect that OperatorA will reconcile, but not B.

Hope that helps, please let us know if you find anything out!

I am facing a similar issue. Any plan to address it?