Cannot upgrade to 0.105.x from 0.104.3

The problem

Upgrade to 0.105.x  from 0.104.3 consistently fails since the launch of 0.105.0.
Environment

Home Assistant release with the issue: 0.105
Last working Home Assistant release (if known):
Operating environment (Hass.io/Docker/Windows/etc.): Hass.io
Integration causing this issue:
Link to integration documentation on our website:

Problem-relevant configuration.yaml

Traceback/Error logs

supervisor's log:
20-02-06 14:04:43 INFO (MainThread) [hassio.homeassistant] Update Home Assistant to version 0.105.2
20-02-06 14:04:43 INFO (SyncWorker_19) [hassio.docker.interface] Update image homeassistant/raspberrypi3-homeassistant:0.104.3 to homeassistant/raspberrypi3-homeassistant:0.105.2
20-02-06 14:04:43 INFO (SyncWorker_19) [hassio.docker.interface] Pull image homeassistant/raspberrypi3-homeassistant tag 0.105.2.
20-02-06 14:09:41 INFO (SyncWorker_19) [hassio.docker.interface] Stop homeassistant application
20-02-06 14:10:35 INFO (MainThread) [hassio.store.git] Update add-on https://github.com/hassio-addons/repository repository
20-02-06 14:10:35 INFO (MainThread) [hassio.store.git] Update add-on https://github.com/sabeechen/hassio-google-drive-backup repository
20-02-06 14:10:35 INFO (MainThread) [hassio.store.git] Update add-on https://github.com/home-assistant/hassio-addons repository
20-02-06 14:10:38 INFO (MainThread) [hassio.store] Load add-ons from store: 63 all - 0 new - 0 remove
20-02-06 14:10:43 INFO (SyncWorker_19) [hassio.docker.interface] Clean homeassistant application
20-02-06 14:10:44 INFO (SyncWorker_10) [hassio.docker.homeassistant] Start homeassistant homeassistant/raspberrypi3-homeassistant with version 0.105.2
20-02-06 14:11:23 DEBUG (MainThread) [hassio.api.security] Passthrough /supervisor/ping
20-02-06 14:11:24 DEBUG (MainThread) [hassio.api.security] /homeassistant/options access from Home Assistant
20-02-06 14:11:24 DEBUG (MainThread) [hassio.api.security] /supervisor/options access from Home Assistant
20-02-06 14:11:24 DEBUG (MainThread) [hassio.api.security] /homeassistant/info access from Home Assistant
20-02-06 14:11:24 DEBUG (MainThread) [hassio.api.security] /ingress/panels access from Home Assistant
20-02-06 14:11:25 INFO (MainThread) [hassio.homeassistant] Home Assistant pip installation in progress
20-02-06 14:14:35 INFO (MainThread) [hassio.homeassistant] Home Assistant pip installation done
20-02-06 14:24:39 WARNING (MainThread) [hassio.homeassistant] Don't wait anymore of Home Assistant startup!
20-02-06 14:24:39 CRITICAL (MainThread) [hassio.homeassistant] HomeAssistant update fails -> rollback!
20-02-06 14:24:39 INFO (MainThread) [hassio.homeassistant] Update Home Assistant to version 0.104.3
20-02-06 14:24:39 INFO (SyncWorker_13) [hassio.docker.interface] Update image homeassistant/raspberrypi3-homeassistant:0.105.2 to homeassistant/raspberrypi3-homeassistant:0.104.3
20-02-06 14:24:39 INFO (SyncWorker_13) [hassio.docker.interface] Pull image homeassistant/raspberrypi3-homeassistant tag 0.104.3.
20-02-06 14:24:40 INFO (SyncWorker_13) [hassio.docker.interface] Stop homeassistant application
20-02-06 14:24:41 INFO (SyncWorker_13) [hassio.docker.interface] Clean homeassistant application
20-02-06 14:24:42 INFO (SyncWorker_2) [hassio.docker.homeassistant] Start homeassistant homeassistant/raspberrypi3-homeassistant with version 0.104.3

Tried to check configuration using Hassio's add on, it fails with the following log, which to me does not seem to come from the configuration itself (check succeeds for 0.104.3).
starting version 3.2.8
[08:35:33] INFO: Don't worry, this temporary installation is not overwriting your current one.
[08:35:33] INFO: Installing Home Assistant: latest...
[08:35:33] INFO: Please be patient, this might take a few minutes...
WARNING: You are using pip version 19.2.2, however version 20.0.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
[08:38:57] INFO: Installed Home Assistant 0.105.2
[08:38:57] INFO: Making a copy of your configuration for checking...
[08:39:06] INFO: Checking your configuration against this version...
[08:44:00] ERROR: The configuration check did not pass!
[08:44:00] ERROR: See the output below for more details.
INFO:homeassistant.util.package:Attempting install of colorlog==4.1.0
Testing configuration at /tmp/config
INFO:homeassistant.util.package:Attempting install of python-nmap==0.6.1
INFO:homeassistant.util.package:Attempting install of getmac==0.8.1
WARNING:homeassistant.components.device_tracker:The 'hide_if_away' option (with value 'False') is deprecated, please remove it from your configuration. This option will become invalid in version 0.107.0
INFO:homeassistant.util.package:Attempting install of pytile==3.0.1
WARNING:homeassistant.components.device_tracker:The 'hide_if_away' option (with value 'False') is deprecated, please remove it from your configuration. This option will become invalid in version 0.107.0
INFO:homeassistant.util.package:Attempting install of av==6.1.2
INFO:homeassistant.util.package:Attempting install of aiohttp_cors==0.7.0
INFO:homeassistant.util.package:Attempting install of home-assistant-frontend==20200130.2
INFO:homeassistant.util.package:Attempting install of defusedxml==0.6.0
INFO:homeassistant.util.package:Attempting install of netdisco==2.6.0
INFO:homeassistant.util.package:Attempting install of hbmqtt==0.9.5
INFO:homeassistant.util.package:Attempting install of paho-mqtt==1.5.0
INFO:homeassistant.util.package:Attempting install of pyatmo==3.2.2
ERROR:homeassistant.scripts.check_config:BURB
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/homeassistant/scripts/check_config.py", line 204, in check
    async_check_ha_config_file(hass)
  File "/usr/local/lib/python3.7/asyncio/base_events.py", line 579, in run_until_complete
    return future.result()
  File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/check_config.py", line 129, in async_check_ha_config_file
    config = config_schema(config)
  File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 272, in __call__
    return self._compiled([], data)
  File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 594, in validate_dict
    return base_validate(path, iteritems(data), out)
  File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 386, in validate_mapping
    cval = cvalue(key_path, value)
  File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 817, in validate_callable
    return schema(data)
  File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 272, in __call__
    return self._compiled([], data)
  File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 594, in validate_dict
    return base_validate(path, iteritems(data), out)
  File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 373, in validate_mapping
    new_key = ckey(key_path, key)
  File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 817, in validate_callable
    return schema(data)
  File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/config_validation.py", line 659, in validator
    value = config[key]
TypeError: string indices must be integers
Fatal error while loading config: string indices must be integers
Failed config
  General Errors:
    - string indices must be integers

Successful config (partial)

Additional information
A forum thread is open with several people having the same issue:
https://community.home-assistant.io/t/cant-update-hassio-to-0-105-x/169466

I have the same problem but my error is different
2020-02-07 11:36:30 INFO (SyncWorker_9) [homeassistant.loader] Loaded alarm_control_panel from homeassistant.components.alarm_control_panel 2020-02-07 11:36:30 ERROR (SyncWorker_9) [concurrent.futures] exception calling callback for <Future at 0x7fe4c473da50 state=finished returned Integration> Traceback (most recent call last):   File "/usr/lib/python3.7/concurrent/futures/_base.py", line 324, in _invoke_callbacks     callback(self)   File "/usr/lib/python3.7/asyncio/futures.py", line 362, in _call_set_state     dest_loop.call_soon_threadsafe(_set_state, destination, source)   File "/usr/lib/python3.7/asyncio/base_events.py", line 728, in call_soon_threadsafe     self._check_closed()   File "/usr/lib/python3.7/asyncio/base_events.py", line 475, in _check_closed     raise RuntimeError('Event loop is closed') RuntimeError: Event loop is closed

I get the same error, the log isn't very helpful is it!?

Same here.

20-02-07 18:26:14 INFO (MainThread) [hassio.store.git] Update add-on https://github.com/home-assistant/hassio-addons repository
20-02-07 18:26:15 INFO (MainThread) [hassio.store] Load add-ons from store: 63 all - 0 new - 0 remove
20-02-07 18:26:46 INFO (MainThread) [hassio.api.security] /snapshots access from cebe7a76_hassio_google_drive_backup
20-02-07 18:28:38 INFO (MainThread) [hassio.homeassistant] Updated Home Assistant API token
20-02-07 18:32:54 INFO (MainThread) [hassio.host.info] Update local host information
20-02-07 18:32:54 INFO (MainThread) [hassio.utils.gdbus] Call org.freedesktop.DBus.Properties.GetAll on /org/freedesktop/hostname1
20-02-07 18:32:54 INFO (MainThread) [hassio.host.services] Update service information
20-02-07 18:32:54 INFO (MainThread) [hassio.utils.gdbus] Call org.freedesktop.systemd1.Manager.ListUnits on /org/freedesktop/systemd1
20-02-07 18:32:54 INFO (MainThread) [hassio.host.network] Update local network DNS information
20-02-07 18:32:54 INFO (MainThread) [hassio.utils.gdbus] Call org.freedesktop.DBus.Properties.GetAll on /org/freedesktop/NetworkManager/DnsManager
20-02-07 18:43:31 INFO (MainThread) [hassio.api.security] /snapshots access from cebe7a76_hassio_google_drive_backup
20-02-07 18:43:32 INFO (MainThread) [hassio.api.security] /homeassistant/info access from cebe7a76_hassio_google_drive_backup
20-02-07 18:43:32 INFO (MainThread) [hassio.api.security] /supervisor/info access from cebe7a76_hassio_google_drive_backup
20-02-07 18:43:32 INFO (MainThread) [hassio.api.security] /snapshots/new/full access from cebe7a76_hassio_google_drive_backup
20-02-07 18:43:32 INFO (MainThread) [hassio.snapshots] Full-Snapshot 78af1752 start
20-02-07 18:43:32 INFO (MainThread) [hassio.snapshots] Snapshot 78af1752 store Add-ons
20-02-07 18:43:32 INFO (MainThread) [hassio.addons.addon] Build snapshot for add-on core_deconz
20-02-07 18:43:32 INFO (MainThread) [hassio.addons.addon] Build snapshot for add-on core_almond
20-02-07 18:43:32 INFO (MainThread) [hassio.addons.addon] Build snapshot for add-on cebe7a76_hassio_google_drive_backup
20-02-07 18:43:32 INFO (MainThread) [hassio.addons.addon] Build snapshot for add-on a0d7b954_adguard
20-02-07 18:43:32 INFO (MainThread) [hassio.addons.addon] Build snapshot for add-on a0d7b954_vscode
20-02-07 18:43:32 INFO (MainThread) [hassio.addons.addon] Build snapshot for add-on a0d7b954_wireguard
20-02-07 18:43:32 INFO (MainThread) [hassio.addons.addon] Build snapshot for add-on core_mosquitto
20-02-07 18:43:32 INFO (MainThread) [hassio.addons.addon] Build snapshot for add-on core_samba
20-02-07 18:43:32 INFO (MainThread) [hassio.addons.addon] Finish snapshot for addon a0d7b954_wireguard
20-02-07 18:43:32 INFO (MainThread) [hassio.addons.addon] Finish snapshot for addon core_samba
20-02-07 18:43:32 INFO (MainThread) [hassio.addons.addon] Finish snapshot for addon core_mosquitto
20-02-07 18:43:32 INFO (MainThread) [hassio.addons.addon] Finish snapshot for addon cebe7a76_hassio_google_drive_backup
20-02-07 18:43:32 INFO (MainThread) [hassio.addons.addon] Finish snapshot for addon a0d7b954_adguard
20-02-07 18:43:33 INFO (MainThread) [hassio.addons.addon] Finish snapshot for addon core_almond
20-02-07 18:43:36 INFO (MainThread) [hassio.addons.addon] Finish snapshot for addon core_deconz
20-02-07 18:43:52 INFO (MainThread) [hassio.addons.addon] Finish snapshot for addon a0d7b954_vscode
20-02-07 18:43:52 INFO (MainThread) [hassio.snapshots] Snapshot 78af1752 store folders
20-02-07 18:43:52 INFO (SyncWorker_4) [hassio.snapshots.snapshot] Snapshot folder addons/local
20-02-07 18:43:52 INFO (SyncWorker_0) [hassio.snapshots.snapshot] Snapshot folder share
20-02-07 18:43:52 INFO (SyncWorker_7) [hassio.snapshots.snapshot] Snapshot folder homeassistant
20-02-07 18:43:52 INFO (SyncWorker_1) [hassio.snapshots.snapshot] Snapshot folder ssl
20-02-07 18:43:52 INFO (SyncWorker_4) [hassio.snapshots.snapshot] Snapshot folder addons/local done
20-02-07 18:43:52 INFO (SyncWorker_0) [hassio.snapshots.snapshot] Snapshot folder share done
20-02-07 18:43:52 INFO (SyncWorker_1) [hassio.snapshots.snapshot] Snapshot folder ssl done
20-02-07 18:44:00 INFO (SyncWorker_7) [hassio.snapshots.snapshot] Snapshot folder homeassistant done
20-02-07 18:44:01 INFO (MainThread) [hassio.snapshots] Full-Snapshot 78af1752 done
20-02-07 18:44:01 INFO (MainThread) [hassio.api.security] /snapshots access from cebe7a76_hassio_google_drive_backup
20-02-07 18:44:01 INFO (MainThread) [hassio.api.security] /snapshots/78af1752/info access from cebe7a76_hassio_google_drive_backup
20-02-07 18:44:01 INFO (MainThread) [hassio.api.security] /snapshots/78af1752/download access from cebe7a76_hassio_google_drive_backup
20-02-07 18:44:01 INFO (MainThread) [hassio.api.snapshots] Download snapshot 78af1752
20-02-07 18:44:02 INFO (MainThread) [hassio.api.security] /snapshots/78af1752/download access from cebe7a76_hassio_google_drive_backup
20-02-07 18:44:02 INFO (MainThread) [hassio.api.snapshots] Download snapshot 78af1752
20-02-07 18:44:22 INFO (MainThread) [hassio.api.security] /snapshots/78af1752/download access from cebe7a76_hassio_google_drive_backup
20-02-07 18:44:22 INFO (MainThread) [hassio.api.snapshots] Download snapshot 78af1752
20-02-07 18:44:51 INFO (MainThread) [hassio.api.security] /snapshots/78af1752/download access from cebe7a76_hassio_google_drive_backup
20-02-07 18:44:51 INFO (MainThread) [hassio.api.snapshots] Download snapshot 78af1752
20-02-07 18:45:20 INFO (MainThread) [hassio.api.security] /snapshots/78af1752/download access from cebe7a76_hassio_google_drive_backup
20-02-07 18:45:20 INFO (MainThread) [hassio.api.snapshots] Download snapshot 78af1752
20-02-07 18:45:50 INFO (MainThread) [hassio.api.security] /snapshots/78af1752/download access from cebe7a76_hassio_google_drive_backup
20-02-07 18:45:50 INFO (MainThread) [hassio.api.snapshots] Download snapshot 78af1752
20-02-07 18:46:19 INFO (MainThread) [hassio.api.security] /snapshots/78af1752/download access from cebe7a76_hassio_google_drive_backup
20-02-07 18:46:19 INFO (MainThread) [hassio.api.snapshots] Download snapshot 78af1752
20-02-07 18:46:48 INFO (MainThread) [hassio.api.security] /snapshots/78af1752/download access from cebe7a76_hassio_google_drive_backup
20-02-07 18:46:48 INFO (MainThread) [hassio.api.snapshots] Download snapshot 78af1752
20-02-07 18:47:07 INFO (MainThread) [hassio.homeassistant] Update Home Assistant to version 0.105.2
20-02-07 18:47:07 INFO (SyncWorker_4) [hassio.docker.interface] Update image homeassistant/qemux86-64-homeassistant:0.104.3 to homeassistant/qemux86-64-homeassistant:0.105.2
20-02-07 18:47:07 INFO (SyncWorker_4) [hassio.docker.interface] Pull image homeassistant/qemux86-64-homeassistant tag 0.105.2.
20-02-07 18:47:22 INFO (MainThread) [hassio.api.security] /snapshots access from cebe7a76_hassio_google_drive_backup
20-02-07 18:49:48 INFO (SyncWorker_4) [hassio.docker.interface] Stop homeassistant application
20-02-07 18:49:50 ERROR (MainThread) [hassio.homeassistant] Error on call http://<IP_ADDRESS>:8123/api/states/binary_sensor.snapshots_stale: Cannot connect to host <IP_ADDRESS>:8123 ssl:None [Connection refused]
20-02-07 18:49:50 ERROR (MainThread) [hassio.api.proxy] Error on API for request states/binary_sensor.snapshots_stale
20-02-07 18:49:55 INFO (SyncWorker_4) [hassio.docker.interface] Clean homeassistant application
20-02-07 18:49:55 INFO (SyncWorker_2) [hassio.docker.homeassistant] Start homeassistant homeassistant/qemux86-64-homeassistant with version 0.105.2
20-02-07 18:50:05 INFO (MainThread) [hassio.homeassistant] Home Assistant pip installation in progress
20-02-07 18:50:30 INFO (MainThread) [hassio.homeassistant] Home Assistant pip installation done
20-02-07 18:50:55 ERROR (MainThread) [hassio.homeassistant] Error on call http://<IP_ADDRESS>:8123/api/states/binary_sensor.snapshots_stale: Cannot connect to host <IP_ADDRESS>:8123 ssl:None [Connection refused]
20-02-07 18:50:55 ERROR (MainThread) [hassio.api.proxy] Error on API for request states/binary_sensor.snapshots_stale
20-02-07 18:53:00 ERROR (MainThread) [hassio.homeassistant] Error on call http://<IP_ADDRESS>:8123/api/states/binary_sensor.snapshots_stale: Cannot connect to host <IP_ADDRESS>:8123 ssl:None [Connection refused]
20-02-07 18:53:00 ERROR (MainThread) [hassio.api.proxy] Error on API for request states/binary_sensor.snapshots_stale
20-02-07 18:57:06 ERROR (MainThread) [hassio.homeassistant] Error on call http://<IP_ADDRESS>:8123/api/states/binary_sensor.snapshots_stale: Cannot connect to host <IP_ADDRESS>:8123 ssl:None [Connection refused]
20-02-07 18:57:06 ERROR (MainThread) [hassio.api.proxy] Error on API for request states/binary_sensor.snapshots_stale
20-02-07 19:00:31 WARNING (MainThread) [hassio.homeassistant] Don't wait anymore of Home Assistant startup!
20-02-07 19:00:31 CRITICAL (MainThread) [hassio.homeassistant] HomeAssistant update fails -> rollback!
20-02-07 19:00:31 INFO (MainThread) [hassio.homeassistant] Update Home Assistant to version 0.104.3
20-02-07 19:00:31 INFO (SyncWorker_4) [hassio.docker.interface] Update image homeassistant/qemux86-64-homeassistant:0.105.2 to homeassistant/qemux86-64-homeassistant:0.104.3
20-02-07 19:00:31 INFO (SyncWorker_4) [hassio.docker.interface] Pull image homeassistant/qemux86-64-homeassistant tag 0.104.3.
20-02-07 19:00:35 INFO (SyncWorker_4) [hassio.docker.interface] Stop homeassistant application
20-02-07 19:00:35 INFO (SyncWorker_4) [hassio.docker.interface] Clean homeassistant application
20-02-07 19:00:36 INFO (SyncWorker_1) [hassio.docker.homeassistant] Start homeassistant homeassistant/qemux86-64-homeassistant with version 0.104.3
20-02-07 19:00:46 INFO (MainThread) [hassio.homeassistant] Home Assistant pip installation in progress
20-02-07 19:01:21 INFO (MainThread) [hassio.homeassistant] Home Assistant pip installation done
20-02-07 19:01:26 INFO (MainThread) [hassio.homeassistant] Home Assistant pip installation in progress
20-02-07 19:02:06 INFO (MainThread) [hassio.homeassistant] Home Assistant pip installation done
20-02-07 19:02:11 ERROR (MainThread) [hassio.homeassistant] Error on call http://<IP_ADDRESS>:8123/api/states/binary_sensor.snapshots_stale: Cannot connect to host <IP_ADDRESS>:8123 ssl:None [Connection refused]
20-02-07 19:02:11 ERROR (MainThread) [hassio.api.proxy] Error on API for request states/binary_sensor.snapshots_stale
20-02-07 19:02:36 INFO (MainThread) [hassio.homeassistant] Detect a running Home Assistant instance
20-02-07 19:02:36 INFO (MainThread) [hassio.homeassistant] Successful run Home Assistant 0.104.3
20-02-07 19:02:36 INFO (SyncWorker_2) [hassio.docker.interface] Cleanup images: ['homeassistant/qemux86-64-homeassistant:0.105.2']
20-02-07 19:07:16 INFO (MainThread) [hassio.homeassistant] Updated Home Assistant API token
20-02-07 19:26:14 INFO (MainThread) [hassio.updater] Fetch update data from https://version.home-assistant.io/stable.json
20-02-07 19:31:44 INFO (MainThread) [hassio.api.proxy] Home Assistant WebSocket API request initialize
20-02-07 19:31:44 INFO (MainThread) [hassio.api.proxy] WebSocket access from a0d7b954_vscode
20-02-07 19:31:44 INFO (MainThread) [hassio.api.proxy] Home Assistant WebSocket API request running```
Same here, also downloads image, looks like it installs, reboot and then fails and roll back! Glad I am not the only one.

Have Proxmox and Hassio on it.

Hi, got the same issue, Fatal error while loading config: string indices must be integers

Same here. Problem in check home assistant log.

For me, not starting up the frontend was fixed by removing the netatmo configuration (before I am going to fix it as described in the release notes).

?? What is the solution?? Or, what causes the not upgrading?
Why closed?

For me, not starting up the frontend was fixed by removing the netatmo configuration (before I am going to fix it as described in the release notes).

Ok will try to temporary removing the Netatmo config item

No success with temporary removing Netatmo config. Still no way to upgrade to 0.105.2
There must be something in the system config that is causing this issue...

I have the same problem even after fixing the Netatmo integration. It starts two times out of five though, and apparently more easily if I set the logger level to debug instead of info. I haven't investigated why (on a RPi3).

20-02-08 15:17:43 INFO (MainThread) [hassio.homeassistant] Updated Home Assistant API token
20-02-08 15:17:43 INFO (MainThread) [hassio.api.proxy] Home Assistant WebSocket API request running
20-02-08 15:17:43 INFO (MainThread) [hassio.api.proxy] Home Assistant WebSocket API request running
20-02-08 15:17:47 INFO (MainThread) [hassio.homeassistant] Detect a running Home Assistant instance
20-02-08 15:17:47 INFO (MainThread) [hassio.homeassistant] Successful run Home Assistant 0.104.3
20-02-08 15:17:47 INFO (SyncWorker_6) [hassio.docker.interface] Cleanup images: ['homeassistant/qemux86-64-homeassistant:0.105.2']
20-02-08 15:35:23 INFO (MainThread) [hassio.api.security] /snapshots access from cebe7a76_hassio_google_drive_backup
20-02-08 15:36:42 INFO (MainThread) [hassio.homeassistant] Update Home Assistant to version 0.105.2
20-02-08 15:36:42 INFO (SyncWorker_4) [hassio.docker.interface] Update image homeassistant/qemux86-64-homeassistant:0.104.3 to homeassistant/qemux86-64-homeassistant:0.105.2
20-02-08 15:36:42 INFO (SyncWorker_4) [hassio.docker.interface] Pull image homeassistant/qemux86-64-homeassistant tag 0.105.2.```

So I can pull and start updating, then it stops. After a reboot the old image is the primary, working image and the newer pull is being wiped

had similiar errors as matthewcky2k and vlebourl on a venv instance updating from 104.3 to 105.2.
after serveral HA restarts and a pi reboot, removing the netatmo integration did actually work for me.

I stuck with the same issue. I tried to remove the netatmo integration. No dice, still the same issue. Anybody have a fix for this? Also is there a was i can get to the hassio panel when home assistant isnt starting up?

@Hellowlol I commented Netatmo integration on 1 other hassio, of family's, and was able to get it upgrading tot 0.105.2
But did same on my own hassio, several tries already, but still no luck. So I commented it, do I need to remove it??? Seems odd

To add the previous comment, so far:

commented Netatmo parts
restarted hassio
tried the upgrade no success
rebooted Proxmox VM and tried upgrading again, no success
rebooted the host sytem and tried upgrading again, no success
reloaded supervisor and tried upgrading again, no success
restarted Proxmox again and tried upgrading again, no success
tried by upgrading through the terminal, no success

My goal is still to upgrade but are out of options... Anyone out there with other thoughts?

same for me, here's the check tool log. running on pi3b+ booting from usb.
Traceback (most recent call last):   File "/usr/local/lib/python3.7/site.py", line 73, in <module>     import os   File "/usr/local/lib/python3.7/os.py", line 27, in <module>     import stat as st ModuleNotFoundError: No module named 'stat'

I think that Netatmo is not the issue...
I don't have the integration, and I'm having the same problem...
Raspberry Pi 4 funning HassOS (problem started with 8, but persists after clean SD flash with 9 - the moment I try to restore my backup from 104.3, it fails)...
More details in the forum (already linked earlier): https://community.home-assistant.io/t/cant-update-hassio-to-0-105-x/169466

Ok,

20-02-09 13:57:42 INFO (MainThread) [hassio.api.proxy] Home Assistant WebSocket API request initialize
20-02-09 13:57:42 INFO (MainThread) [hassio.api.proxy] Home Assistant WebSocket API request initialize
20-02-09 13:57:42 INFO (MainThread) [hassio.api.proxy] WebSocket access from a0d7b954_vscode
20-02-09 13:57:42 INFO (MainThread) [hassio.api.proxy] WebSocket access from core_almond
20-02-09 13:57:42 ERROR (MainThread) [hassio.api.proxy] Client error on WebSocket API Cannot connect to host <IP_ADDRESS>:8123 ssl:False [Connection refused].
20-02-09 13:57:42 ERROR (MainThread) [hassio.api.proxy] Client error on WebSocket API Cannot connect to host <IP_ADDRESS>:8123 ssl:False [Connection refused].
20-02-09 13:57:42 INFO (MainThread) [hassio.api.proxy] Home Assistant WebSocket API request initialize
20-02-09 13:57:42 INFO (MainThread) [hassio.api.proxy] WebSocket access from core_almond
20-02-09 13:57:42 INFO (MainThread) [hassio.api.proxy] Home Assistant WebSocket API request initialize
20-02-09 13:57:42 INFO (MainThread) [hassio.api.proxy] WebSocket access from a0d7b954_vscode
20-02-09 13:57:42 INFO (MainThread) [hassio.homeassistant] Updated Home Assistant API token
20-02-09 13:57:42 INFO (MainThread) [hassio.api.proxy] Home Assistant WebSocket API request running
20-02-09 13:57:42 INFO (MainThread) [hassio.homeassistant] Updated Home Assistant API token
20-02-09 13:57:42 INFO (MainThread) [hassio.api.proxy] Home Assistant WebSocket API request running
20-02-09 13:57:46 INFO (MainThread) [hassio.homeassistant] Detect a running Home Assistant instance
20-02-09 13:57:46 INFO (MainThread) [hassio.homeassistant] Successful run Home Assistant 0.104.3
20-02-09 13:57:46 INFO (SyncWorker_4) [hassio.docker.interface] Cleanup images: ['homeassistant/qemux86-64-homeassistant:0.105.2']

I use HA in virtualenv on OrangePi Zero. For me problem was in upgrade home-assistant-frontend.

pip3 install --upgrade home-assistant-frontend
Collecting home-assistant-frontend
Using cached home-assistant-frontend-20200130.2.tar.gz (35.4 MB)
Installing collected packages: home-assistant-frontend
Attempting uninstall: home-assistant-frontend
Found existing installation: home-assistant-frontend 20200108.2
Uninstalling home-assistant-frontend-20200108.2:
Successfully uninstalled home-assistant-frontend-20200108.2
Running setup.py install for home-assistant-frontend ... error
ERROR: Command errored out with exit status 1:
command: /home/ha/homeassistant/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-ctie4i1v/home-assistant-frontend/setup.py'"'"'; file='"'"'/tmp/pip-install-ctie4i1v/home-assistant-frontend/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' install --record /tmp/pip-record-rme7j3iz/install-record.txt --single-version-externally-managed --compile --install-headers /home/ha/homeassistant/include/site/python3.7/home-assistant-frontend
cwd: /tmp/pip-install-ctie4i1v/home-assistant-frontend/
..........................................................
error: [Errno 28] No space left on device

Apparently size my 'tmp' folder is not enough so i solve this with:

export TMPDIR=$HOME/temp
pip3 install --upgrade home-assistant-frontend

Hope this help someone.

Ok, I've got it!!
Let me explain:
I have Proxmox VM, I do have 2 VM's running. I was working on one of the VM's while I had the other one still running....
Read several logs after the reboots, never saw this one, until just now: There was an unique other one running, so I stopped the other VM, upgrade again and viola! It came up.
Just to clarify, both VM's had unique IP addresses, so no errors there. Apparently the one VM also looked at the other VM ....??

for me commenting out netatmo did not work, but updating to the new configuration did !
netatmo:
  client_id: YOUR_CLIENT_ID
  client_secret: YOUR_CLIENT_SECRET

running on rpi3b+ and still have the issue, even after updating to HassOS 3.10

for me commenting out netatmo did not work, but updating to the new configuration did !
netatmo:
  client_id: YOUR_CLIENT_ID
  client_secret: YOUR_CLIENT_SECRET

This worked also for me even I haven't anymore the Netatmo configuration.

for me commenting out netatmo did not work, but updating to the new configuration did !
netatmo:
  client_id: YOUR_CLIENT_ID
  client_secret: YOUR_CLIENT_SECRET

This worked also for me even I haven't anymore the Netatmo configuration.

Also worked for me.

105.3 works now, but if I use the plugin Check Configuration Tool, it still gives me the same error. So now the problem is the plugin.

Is this still an issue?

I'm now running 105.4 without problem, but for me this tool "Check Home Assistant configuration" doesn't worked. I posted the log above. So I uninstalled it. Maybe this plugin has been replaced by: Configuration .. Server Controls .. CHECK CONFIG button? I do not know.

in <module> import os File "/usr/local/lib/python3.7/os.py", line 27, in <module> import stat as st ModuleNotFoundError: No module named 'stat' [13:29:49] ERROR: An error occurred while installing Home Assistant:

@chris669 looks like your python installation is not complete since it is missing the mentioned stat module which is installed by default as far as I know.

Looks like main issue is closed. If you still experience upgrade issues, please try again with version 105.5 (released today) and open a new issue detailing your problem.


mimalloc 2.0.3: crash app on startup

Hi,
The following scenario:

Windows 10, 17763.379
Visual Studio 2022, 17.0.4
Application (Renga.exe and many our dlls and third party dlls). We link Renga.exe explicitly with the mimalloc DLL.
Sometimes (very rarely, one crash per 13000 launches), the application crashes on startup.

We have the following callstack from the dump:

0000000025ff3980()
ucrtbase.dll!(void)()
ucrtbase.dll!__crt_seh_guarded_call::operator()<<lambda_8369fcb7c4df1e85de37618bd2b85f07>,(void) & ptr64,<lambda_5b7707bd6d7a0c4713179f36c7fd995d>>()
ucrtbase.dll!register_onexit_function()
mimalloc-override.dll!onexit(int()() function) Line 271
at d:\a01_work\20\s\src\vctools\crt\vcstartup\src\utility\utility.cpp(271)
mimalloc-override.dll!atexit(void()() function) Line 275
at d:\a01_work\20\s\src\vctools\crt\vcstartup\src\utility\utility.cpp(275)
[Inline Frame] mimalloc-override.dll!mi_process_load() Line 476
at C:\SRC\mimalloc\src\init.c(476)
mimalloc-override.dll!DllMain(HINSTANCE * inst, unsigned long reason, void * reserved) Line 579
at C:\SRC\mimalloc\src\init.c(579)
mimalloc-override.dll!dllmain_dispatch(HINSTANCE * const instance, const unsigned long reason, void * const reserved) Line 281
at d:\a01_work\20\s\src\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp(281)
ntdll.dll!LdrpCallInitRoutine()
ntdll.dll!LdrpInitializeNode()
ntdll.dll!LdrpInitializeGraphRecurse()
ntdll.dll!LdrpInitializeGraphRecurse()
ntdll.dll!LdrpInitializeProcess()
ntdll.dll!_LdrpInitialize()
ntdll.dll!LdrpInitialize()
ntdll.dll!LdrInitializeThunk()

We couldn't get log when app crashes. But we have log for successful app launch. Output log with MIMALLOC_VERBOSE=3 is attached below:

mimalloc: process init: 0xf8473d9000
mimalloc: secure level: 0
mimalloc: using 1 numa regions
mimalloc: option 'show_errors': 0
mimalloc: option 'show_stats': 3
mimalloc: option 'eager_commit': 1
mimalloc: option 'eager_region_commit': 0
mimalloc: option 'reset_decommits': 0
mimalloc: option 'large_os_pages': 0
mimalloc: option 'reserve_huge_os_pages': 0
mimalloc: option 'reserve_huge_os_pages_at': -1
mimalloc: option 'reserve_os_memory': 0
mimalloc: option 'segment_cache': 0
mimalloc: option 'page_reset': 0
mimalloc: option 'abandoned_page_reset': 0
mimalloc: option 'segment_reset': 0
mimalloc: option 'eager_commit_delay': 4
mimalloc: option 'allow_decommit': 1
mimalloc: option 'reset_delay': 25
mimalloc: option 'segment_decommit_delay': 500
mimalloc: option 'use_numa_nodes': 0
mimalloc: option 'limit_os_alloc': 0
mimalloc: option 'os_tag': 100
mimalloc: option 'max_errors': 16
mimalloc: option 'max_warnings': 16
mimalloc: malloc is redirected.
mimalloc-redirect: trace: build: Nov 22 2019
mimalloc-redirect: trace: checking for target mimalloc.dll
mimalloc-redirect: trace: checking for target mimalloc-override.dll
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\Renga.exe"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\ntdll.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\KERNEL32.DLL"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\KERNELBASE.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\USER32.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\mimalloc-override.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\DxfConverter.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\win32u.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\GDI32.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\ucrtbase.dll"
mimalloc-redirect: trace: resolving "ucrtbase.dll"
mimalloc-redirect: trace: resolve "malloc" at ucrtbase.dll!0x00007FFDEC4DC9E0 to mimalloc!0x00007FFD480B3140 (0)
mimalloc-redirect: trace: resolve "calloc" at ucrtbase.dll!0x00007FFDEC4DAE90 to mimalloc!0x00007FFD480B25D0 (0)
mimalloc-redirect: trace: resolve "realloc" at ucrtbase.dll!0x00007FFDEC4DDC80 to mimalloc!0x00007FFD480B3760 (0)
mimalloc-redirect: trace: resolve "free" at ucrtbase.dll!0x00007FFDEC4DC7B0 to mimalloc!0x00007FFD480B2650 (0)
mimalloc-redirect: trace: resolve "_expand" at ucrtbase.dll!0x00007FFDEC538830 to mimalloc!0x00007FFD480B2600 (0)
mimalloc-redirect: trace: resolve "_recalloc" at ucrtbase.dll!0x00007FFDEC4F2300 to mimalloc!0x00007FFD480B3980 (0)
mimalloc-redirect: trace: resolve "_msize" at ucrtbase.dll!0x00007FFDEC4ED4E0 to mimalloc!0x00007FFD480B3A70 (0)
mimalloc-redirect: trace: resolve "_malloc_base" at ucrtbase.dll!0x00007FFDEC4DC9F0 to mimalloc!0x00007FFD480B3140 (0)
mimalloc-redirect: trace: resolve "_calloc_base" at ucrtbase.dll!0x00007FFDEC4DAEA0 to mimalloc!0x00007FFD480B25D0 (0)
mimalloc-redirect: trace: resolve "_realloc_base" at ucrtbase.dll!0x00007FFDEC4DDC90 to mimalloc!0x00007FFD480B3760 (0)
mimalloc-redirect: trace: resolve "_free_base" at ucrtbase.dll!0x00007FFDEC4DC7D0 to mimalloc!0x00007FFD480B2650 (0)
mimalloc-redirect: trace: resolve "_expand_base" at ucrtbase.dll!0x00007FFDEC53883C to mimalloc!0x00007FFDD5C84D80 (0)
mimalloc-redirect: trace: resolve "_recalloc_base" at ucrtbase.dll!0x00007FFDEC4E04AC to mimalloc!0x00007FFDD5C84DB0 (0)
mimalloc-redirect: trace: resolve "_msize_base" at ucrtbase.dll!0x00007FFDEC4ED4F0 to mimalloc!0x00007FFDD5C84D60 (0)
mimalloc-redirect: trace: resolve "_aligned_malloc" at ucrtbase.dll!0x00007FFDEC4F2390 to mimalloc!0x00007FFD480B1960 (0)
mimalloc-redirect: trace: resolve "_aligned_realloc" at ucrtbase.dll!0x00007FFDEC5383C0 to mimalloc!0x00007FFD480B1A20 (0)
mimalloc-redirect: trace: resolve "_aligned_free" at ucrtbase.dll!0x00007FFDEC4F2C00 to mimalloc!0x00007FFD480B2650 (0)
mimalloc-redirect: trace: resolve "_aligned_recalloc" at ucrtbase.dll!0x00007FFDEC5385C0 to mimalloc!0x00007FFD480B1CB0 (0)
mimalloc-redirect: trace: resolve "_aligned_msize" at ucrtbase.dll!0x00007FFDEC537D20 to mimalloc!0x00007FFDD5C85190 (0)
mimalloc-redirect: trace: resolve "_aligned_offset_malloc" at ucrtbase.dll!0x00007FFDEC537D90 to mimalloc!0x00007FFD480B19E0 (0)
mimalloc-redirect: trace: resolve "_aligned_offset_realloc" at ucrtbase.dll!0x00007FFDEC537E60 to mimalloc!0x00007FFD480B1A50 (0)
mimalloc-redirect: trace: resolve "_aligned_offset_recalloc" at ucrtbase.dll!0x00007FFDEC5380C0 to mimalloc!0x00007FFD480B1CA0 (0)
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\DxfExporter.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\gdi32full.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\RPCRT4.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\msvcp_win.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\CollisionEngine.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\ADVAPI32.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\COMDLG32.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\msvcrt.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\combase.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\sechost.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\TablesEngine.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\SpecsEngine.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\bcryptPrimitives.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\bcrypt.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\SHLWAPI.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\shcore.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\SHELL32.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\Value.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\AecMath.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\cfgmgr32.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\windows.storage.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\FontEngine.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\profapi.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\Geometry.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\powrprof.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\kernel.appcore.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\PluginsSystem.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\MepRelationEngine.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\OLEAUT32.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\RenderEngine.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\cryptsp.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\ole32.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\CRYPT32.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\Exchange3DFormatsConverter.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\ProjectStorage.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\MSASN1.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\HMD.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\Scripting.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\ScriptingEngine.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\Ifc4Import.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\Ifc4Export.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\GeneralizedModel.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\Serialization.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\Reinforcement.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\CollaborationController.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\CollaborationExchange.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\PropertiesGrid.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\EmbeddedPreviewEngine.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\Tables.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\RepresentationEngine.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\Activity.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\CSVExporter.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\Specs.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\MathAttributes.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\Graphics.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\Model.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\APIBackend.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\ItemIdGenerator.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\ProjectController.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\ProjectConverter.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\Expressions.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\ProjectExplorer.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\CrashRpt.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\libglog.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\RengaApp.Libs\Qt5Core.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\System32\WS2_32.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\RengaApp.Libs\Qt5Widgets.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\RengaApp.Libs\Qt5Xml.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\RengaApp.Libs\Qt5Gui.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\RengaApp.Libs\Qt5Svg.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\xsec_2_0.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\QPdfium.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\c3d.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\xerces-c_3_2.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\Pat.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\CollaborationCore.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\ISM_21.2_14.tx"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\PlotSettingsValidator_21.2_14.tx"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\TD_Alloc_21.2_14.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\TD_Db_21.2_14.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\TD_DbRoot_21.2_14.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\TD_DbCore_21.2_14.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\TD_DbEntities_21.2_14.tx"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\TD_Ge_21.2_14.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\TD_Gi_21.2_14.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\TD_Root_21.2_14.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\MSVCP140.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\VCRUNTIME140.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\VCRUNTIME140_1.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\mimalloc-redirect.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\WINSPOOL.DRV"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\tidy.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_5.82.17763.379_none_10e5882c642d5588\COMCTL32.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\DWrite.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\d2d1.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\VCOMP140.DLL"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\MepTrace.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\ZodiacGraph.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\mscoree.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\GFSDK_SSAO.win64.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\XINPUT9_1_0.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\D3DCOMPILER_47.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\d3d11.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\VERSION.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\dwmapi.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\MeshExporter.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\assimp.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\prntvpt.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\IfcMapping.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\IfcPlusPlusIfc4.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\Logging.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\InternalAPI.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\MPR.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\WINMM.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\UxTheme.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\RengaApp.Libs\libGLESv2.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\pdfium.dll"
mimalloc-redirect: trace: module "C:\renga_src0\Bin\Release\TD_SpatialIndex_21.2_14.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\Secur32.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\PROPSYS.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\IPHLPAPI.DLL"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\OPENGL32.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\d3d9.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\dxgi.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\winmmbase.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\GLU32.dll"
mimalloc-redirect: trace: module "C:\WINDOWS\SYSTEM32\SSPICLI.DLL"
mimalloc-redirect: trace: standard malloc is redirected
heap stats:    peak      total      freed    current       unit      count
reserved:  704.0 MiB  704.0 MiB    8.0 KiB  704.0 MiB                        not all freed!
committed:  133.7 MiB  133.7 MiB    8.0 KiB  133.7 MiB                        not all freed!
reset:      0          0          0          0                            ok
touched:  257.0 KiB  257.0 KiB   25.1 MiB  -24.9 MiB                        ok
segments:      2          2          1          1                            not all freed!
-abandoned:      1          1          0          1                            not all freed!
-cached:      0          0          0          0                            ok
pages:    227        304        245         59                            not all freed!
-abandoned:      2          2          0          2                            not all freed!
-extended:      0
-noretire:      0
mmaps:      0
commits:     82
threads:     10         10          1          9                            not all freed!
searches:     0.0 avg
numa nodes:       1
elapsed:       3.910 s
process: user: 0.343 s, system: 0.718 s, faults: 27351, rss: 100.0 MiB, commit: 157.2 MiB
mimalloc: process done: 0xf8473d9000

"one crash per 13000 launches" -- yikes! I hope we can figure this out. Are you able to test this, i.e. run it for 100.000 launches and see if there is a crash?

What is the ucrtbase.dll version? (go to c:\Windows\syswow64 and right click for properties), My system has vs2019 / win10 and the ucrtbase version is 10.0.19041.789.
I see the mimalloc-override.dll is not first in the import table but comes after user32.dll. That might be the culprit, although I do not understand why it is non-deterministic (?). Can you move it to be first?  (Either use a tool like CFF Explorer, or checkout the latest dev-slice branch and in the bin directory is a new tool called minject.exe. It will automatically move mimalloc-override.dll to the top of the DLL import table.)
I wonder if the atexit call is part of the problem (as the crash happens there). Recently we moved initialization to be more early on MSVC and perhaps we need to do our own atexit cleanup as well without using the CRT. Depending on your testing, I can try to do this and we can try if that solves the issue.

Thanks!

I pushed a potential fix to the latest dev-slice branch -- this avoids using atexit when using windows dll. But maybe first try to move the mimalloc-override.dll up in the import table; if you then still observe crashes try the new dev-slice branch (so we can hopefully find the root cause).
(the commit does not show up in this thread as I misspelled the issue number :-( )

Are you able to test this, i.e. run it for 100.000 launches and see if there is a crash?

Yes, sure, we can.
ucrtbase.dll version is 10.0.16299.125.
Regarding import table. I thought it's all right (mimalloc-override.dll is first). Here is output of dumbin and CFF Explorer:
dumpbin_output.txt

I will try the latest version from dev-slice. Thanks !

Thanks! Yes, it seems it is high enough on the list. I will look into this a bit more.
Your ucrtbase.dll version is lower than mine somehow (I also use windows 10 but only vs2019) -- maybe do a windows upgrade it if possible?
Hope the latest version fixes the issue.. fingers crossed.

With the last version from dev-slice app still crashes. Stacktrace:

0000000025ff3980()
ucrtbase.dll!(void)()
ucrtbase.dll!__crt_seh_guarded_call::operator()<<lambda_8369fcb7c4df1e85de37618bd2b85f07>,(void) & __ptr64,<lambda_5b7707bd6d7a0c4713179f36c7fd995d>>()
ucrtbase.dll!_register_onexit_function()
ucrtbase.dll!__crt_state_management::wrapped_invoke<int ()(struct _onexit_table_t ,int ()(void)),struct _onexit_table_t ,int ()(void),int>(int ()(struct _onexit_table_t ,int ()(void)),struct _onexit_table_t ,int ()(void))
msvcp_win.dll!_onexit()
msvcp_win.dll!atexit()
ucrtbase.dll!_initterm()
msvcp_win.dll!__local_stdio_scanf_options()
msvcp_win.dll!__local_stdio_scanf_options()
ntdll.dll!LdrpCallInitRoutine()
ntdll.dll!LdrpInitializeNode()
ntdll.dll!LdrpInitializeGraphRecurse()
ntdll.dll!LdrpInitializeGraphRecurse()
ntdll.dll!LdrpInitializeGraphRecurse()
ntdll.dll!LdrpInitializeGraphRecurse()
ntdll.dll!LdrpInitializeGraphRecurse()
ntdll.dll!LdrpInitializeGraphRecurse()
ntdll.dll!LdrpInitializeGraphRecurse()
ntdll.dll!LdrpInitializeProcess()
ntdll.dll!_LdrpInitialize()
ntdll.dll!LdrpInitialize()
ntdll.dll!LdrInitializeThunk()

Hmm, I have another test to try; will post soon. Just to confirm, the crash still happens only rarely right?  It is so strange it is non-deterministic..

I updated the latest dev/dev-slice with a version of bin/minject that also injects the mimalloc-redirect.dll at the first import table position in the dll. My hope is that this will get to run before USER32 and hopefully prevent the atexit trouble.  Can you try this out? (ie. run minject renga.exe and use the created renga-mi.exe to see if you can still observe a crash?).

Just to confirm, the crash still happens only rarely right?
Yes, only rarely. With commit 44e7eb12d6de483b8894977bcd64bbbb186117c4 one crash per 39000 run.
I'll try the updated version of minject.

Good news ! With the latest version of minject the app doesn't crash ! Is it possible to do the same thing (import mimalloc-redirect.dll and set it to the first import table position) using linker options ? I would not like to inject dll using minject.

Wow! ha, happy to hear this :-)  Nightmare bug with a 1 out 39000 run crash probability -- so glad you were able to test this!
To include the redirect dll directly, link with mimalloc-redirect.lib (make it come first), and use the linker flag /INCLUDE:mi_redirect_enable to force it to be included. Still, not sure if that will make it come first in the import table (at least, I guess before USER32.dll) -- are you able to test this?
(Also, minject will also reorder the import entries though if needed without injecting so you could still run that after forcing mimalloc-redirect to be linked through the command line.  )

It's working. We can close the issue. Thank you !


Dev

Changes to "gt_auto_biped_rigger"
New systems for the character's hand.
Creation of the sine function through nodes.
Bug fixes.

Changes to "gt_auto_biped_rigger"
New systems for the character's hand.
Creation of the sine function through nodes.
Bug fixes.


incorrect grammar [Agent Webhook Settings]

If you want to define a global webhook that will called each time the user talks with your agent then you can do it here.
is wrong.
should be:
If you would like to define a global webhook that will be called each time the user talks with your agent, then you may do it here.

did you mean to create this issue on another repository?


feat: Complete NNReal coercion lemmas

Add a few missing lemmas about the coercion NNReal → Real. Remove a bunch of protected on the existing coercion lemmas (so that it matches the convention for other coercions). Rename NNReal.coe_eq to NNReal.coe_inj
From LeanAPAP

Otherwise LGTM. Thanks!
bors d+


New behavior for read_verilog handling of whiteboxes

    -noblackbox
        do not automatically add a (* blackbox *) attribute to an
        empty module.

    -lib
        only create empty blackbox modules. This implies -DBLACKBOX.
        modules with the (* whitebox *) attribute will be preserved.
        (* lib_whitebox *) will be treated like (* whitebox *).

    -nowb
        delete (* whitebox *) and (* lib_whitebox *) attributes from
        all modules.

Without -lib it automatically deletes (* lib_whitebox *) attributes. You can even do for example (* whitebox, lib_whitebox = 0 *).

Can you explain in what situation the new (* lib_whitebox *) would be beneficial?

Can you explain in what situation the new (* lib_whitebox ) would be beneficial, over the capabilities we get from ( whitebox *) alone?

I think you'd actually use whitebox (or blackbox) very seldom in practice. In most cases you'd use lib_whitebox. For example in techlibs/ice40/cells_sim.v you'd tag SB_LUT4 and SB_CARRY with (* lib_whitebox *). Then, when you read it with read_verilog it's as if the attribute wasn't there, but if you read it with read_verilog -lib then you get a whitebox module.

EDIT: Oh this takes out the -wb flag from read_verilog added in #943

Yes, that's the point. Users would just say "read that lib" by running read_verilog -lib without having to care/know about whiteboxes. And users would just say "read those modules" by running read_verilog without having to worry that some might be whiteboxes and that this may screw up their flow.

EDIT2: I have to say I'm getting confused with the lib_whitebox and whitebox options, and also with techmap -wb and flatten -wb compared to the new wbflip. Is there a need for all of them, or will they only serve to confuse?

There definitely is a need for both of them. wbflip allows you to operate only on whiteboxes or only on non-whiteboxes, whereas -wb allows you to work on both of them at the same time.
You'd use flatten -wb if you wanted to flatten your whiteboxes into the modules instantiating them, but you'd run wbflip; proc; opt -fast; techmap; opt -fast; wbflip if you wanted to do some logic synthesis and optimization on your whitebox modules only.

Haha.

Fixed it.

Confirm fix! Cheers.


Addition of a COLLECTION node

We have decided that we need to add a new type of node called a COLLECTION.
The purposes of this are twofold:

Will help with organising data and filtering searchers for users.
Will maintain consistency with the Paleobiology Database.

Current Design

All COLLECTIONS must have at least one REFERENCE. This is to maintain consistency with Paleobiology Database design.
An empty COLLECTION cannot be made public.
A COLLECTION cannot be deleted if it has child SPECIMEN nodes. The SPECIMEN nodes would have to be deleted first.
A COLLECTION is tied to SPECIMEN nodes, NOT to DESCRIPTION nodes of either OTU or SPECIMEN types.

Outstanding issues

The term COLLECTIONS is used in many different ways in different databases. We have stuck with COLLECTION for consistency with the Paleobiology Database and because other alternatives (e.g., SAMPLE) are also potentially confusing. Are we content with this choice?
A collection in the paleobiology database is primarily a group of what we would call OTUs with secondary support for specimens, but a collection in pbot is primarily a group of specimens with secondary support for OTUs. Is this mismatch a problem?

As a current tentative design, I have made the following preliminary list of Required, Encouraged, Inappropriate, and optional fields for COLLECTIONS.
Passive

pbotID

Required
Stratigraphic Unit -- The most highly resolved stratigraphic unit - e.g., if your section has a known Group, Formation, Member, Submember, and Bed, you would put the Bed name here.
Latitude -- in WGS84 Decimal Degrees
Longitude -- in WGS84 Decimal Degrees
Name -- a free text name (Required for PBDB)
Early Interval -- The earliest geologic interval
Late Interval -- The latest geologic interval
Protected -- Boolean, is this considered a legally protected site
Paleoenvironment -- The paleoenvironment interpretation (indeterminate allowed).
Encouraged
Paleobiology Database Link -- Link to an equivalent PBDB collection
Numeric Max Age -- Age in Myrs if associated with specific geochron measurement
Numeric Min Age -- Age in Myrs if associated with specific geochron measurement
Group -- Geologic Group
Formation -- Geologic Formation
Member -- Geologic Member
Bed -- Geologic Bed
Geography Comments -- Notes on how to find the location
Stratigraphy Comments -- Notes on the stratigraphic nomeclature used
Geologic Comments -- Notes on the lithological context of the section
Preservation Comments Notes on the taphonomic situation
Collectors -- Names of actual field collectors
Inappropriate
collection_no -- would be assigned by pbdb, not our issue
record_type -- is automatically a collection, this is a stupid field
collection_subset -- although we could support this, it is so rarely used in pbdb I don't see it as worth it
collection_aka -- no need for this
n_occs -- implicit
ref_author -- implicit in references node
ref_pubyr -- implicit in references node
reference_no -- implicit in reference node
cc -- country code, implicit in lat long
state -- implicit in lat long
county -- impliict in lat long
paleomodel -- handled by pbdb
paleolng -- handled by pbdb
paleolat -- handled by pbdb
geoplate -- hanlded by gplates
taxonomy comments -- redundant with rest of pbot
optional
Everything else tracked by pbdb but not listed above.

The Current Design described above is in api commits ef0a0936d206d41000df98aabdada7c3190ae38a through 33e5f2d2bf68fdbede9e3af298127828b4337831, and client commits 8982749adf9c86e6775e57821ad3037bca1be56b through 612d9db87a7e024df335681fe3eb7b8faaac7ec0.
I'm  leaving the properties at pbotID and name for now.

Yes... Linnaean at SOME level, not necessarily genus species.

Did we talk previously about having a "Reason for Collection" field? Might be important to know if something was a quantitative census vs. taxonomic collection vs. biostratigraphic investigation (and other categories, too).

@ecurrano I didn't actually know how to interpret "reason for collection"! I would like having the investigations method/purpose info you listed here. We would need to provide clear instructions of what to put in that field, and not to put in that field! I could see someone typing their whole study rationale in that field.

Less specifically than last couple of comments, It sounds like having the flexibility for a collection to mean a myriad of things is necessary to be in line with PBDB and our term collection would port to PBDB. However within PBOT, the highest level of collection could be broken down into sub collections which is dependent on the enterer (we would provide some training set of guidelines).
It does bring up the concern of when a new collection is added as the highest level, but turns out it will later become part of an even higher level collection. But something tells me PBDB has already had experience with this and there is a solution or workaround?

Ellen, Claire, and Rebecca discussed this more on Wednesday. Here is a summary of our discussion, and we look forward to feedback!

Collection node = the fossils collected from a particular hole at a particular point in time by a particular team or individual (inherent in this is that different teams might have different reasons for collection) => we will encourage everyone to enter their data at this resolution.

Super Collection node = amalgamation of all the collections taken from a specific locality (e.g., Colwell Creek Pond, Big Cedar Ridge)

the use of collection & super collection vs sub-collection & collection should match PBDB. We are unsure whether that means PBDB gets the “Collection node” or the “Super Collection node.”

Anything above the level of “Super Collection” will be achieved through querying- e.g., formation-level or specific geographic region.

Allow duplication of nodes so one can adjust minimally Command D:duplicate is our friend!

Req./Rec./etc. for collection properties: pause until we meet with the full team and confirm collection terminology

Also, replying to Dori's comment above. Yes! Maybe we can have a drop-down menu for investigations method/purpose and clear explanation of each category we put in that drop-down menu.

Great, here are some preliminary responses.

Collection node = the fossils collected from a particular hole sample at a particular point in time by a particular team or individual (inherent in this is that different teams might have different reasons for collection) => we will encourage everyone to enter their data at this resolution.

My main concern is with the use of the word encourage above. This implies that it will still be possible for a user to enter data not at this resolution. How do you expect that to work from a technical standpoint?
Conversely, if we do not support alternative resolutions, what do users with data at those other scales do?

Super Collection node = amalgamation of all the collections taken from a specific locality (e.g., Colwell Creek Pond, Big Cedar Ridge

Is there any benefit to calling it a super collection as opposed to a locality?
How does this address the issue of different teams/projects that collect from the same locality? Would each project have the same or different "super collection" nodes?
How will you define a the size of a locality? For example, for my M.S. thesis I had three roadcuts that I broke out as three localities, but they were easily walking distance from each other and could have reasonably been bundled up as one.
It should be understood there can be no validation of any of this on our side because there's no way for us to know what the sizes are or would be. So this will be entirely honor system.

The definition of a collection node, as currently written, seems very specific to a certain collecting style and material. Namely, it makes perfect sense for the discrete quarry-style sampling of compression/impression fossils (currently used by all of us and others in more quantitative paleobotany circles!). I am not sure if that definition is inclusive enough of the range of plant materials/modes of preservation/collection styles for the entire community.
For example, nodules containing plants are not collected from holes or quarries, but often surface collected - what constitutes a sample is, by necessity, going to be determined by the researcher based on the realities of the site and their study aims. There are even many situations where plant compressions/impressions are not collected from distinct holes that are separately recorded - for example, when I did some field work with Nacho and Ruben in Argentina, they just collected all the plants found at the site/locality by many people working on different spots on the hillsides; this is common for groups that are sampling for taxonomic diversity and systematics and not heavily into quantitative paleoecology/paleobotany. There are also many collections of specimens obtained from float. I am also not sure how palynology would work with this description - for example, should a core be divided into time/measured increments as collections? And then there are the historical collections, of course, which are generally/rarely recorded as holes or quarries and were likely just collected from large areas. There are more examples that I am not touching on, like collections from coal balls, from lignite mines, and so on. All of this to basically say that the definition of a collection has to be accommodating to the many various types of preservation/specimens, researcher aims, and messy realities of collecting. I think that means ultimately having to rely on researchers to determine the smallest, meaningful, and realistic partition of their specimens/data, beyond the basic guidelines of being collected by a particular individual/group at a particular time (this speaks a bit to Andrew's question #3).
A possible (but incomplete and needs work) modification:
Collection node = the fossils collected as a sample at a particular place and point in time by a team or individual. The sample should represent the smallest reasonable division of your data (e.g., a single quarry sample, a surface collection of nodules from a single site, .....[need other examples, but you get the gist!]
I like the concept of a "super collection" node for internal PBot use! I am guessing that the smaller-partitioned "collection" concept is what would pipe to/track better with PBDB.

Dori articulated my thoughts so much more clearly. Yes, there are so many different methods of collection out there. We really want to err on the side of inclusivity.

Relevant notes on this topic from meeting with Mark:
"Collections" are the biggest sticky issue in PBDB
-Mark's view is a collection is "temporally-ecologically bound" [note: I like this wording of the concept]
-People should conceptualize them as small as they can
-PBDB does not differentiate collection date - so why make a new collection for different dates? Mark's perspective is that there is no point. But all this is dependent on things like, is it the same spot?? Different collectors can make a difference. [note: my opinion would be that different collection methods should warrant making new collections]
-PBDB is very flexible, which is a blessing and a curse
-"you can never go wrong making more collections, only by making too few"
-"when in doubt, part it out!!"
Andrew: think about the goal of the database. If it is a constrained scientific goal/aim, then what a collection is should be constrained; if the use of the database is broad/unconstrained, then the definition should be unconstrained.
Regarding specimens and/or names not clearly in a collections or names without attached specimens. Mark's rule of thumb when entering data (for global scale analysis): if he can get down to cenozoic epic and a county, he will enter it.
-the data can be in the database at the level that it exists (sometimes crappy), but depending on your analysis and query, it gets filtered out when not relevant!
-for PBot, for filtering based on collection methods see the collections entry form, last tab, called "collecting info". and our system, could say that you must answer these questions! PBDB can add checkboxes or whatnot for us
-From Andrew about nesting collections: we provide in our graph system the ability to have unlimited hierarchy of collections, and the most finely parced goes to PBDB. Mark full-on agrees here.
-Use darwincore for terms! There is a conversion table for PBDB to darwincore, Mark will try to find

We will allow unbounded nesting of collections of collections (as we do with states and characters). The only question is whether we separate out the concept of darwind collection_location as a separate node type or just keep it as a collection type but specify it with a property - like how we distinguish between OTU and Specimen descriptions. I am leaning towards the latter, but we have not decided on this yet.


kick-off event sourcing migration

:recycle: move contribution status into its own file
:recycle: use ContractAddress type for validator address in domain instead of felt
:recycle: change HexPrefixedString implementation to make Event serializable
♻ refactor event unit test to use fixture
♻ use HexPrefixedString as ContributorId internal representation to have proper serde
:sparkles: add ContributionEvent support
:heavy_plus_sign: add eventually crate
:sparkles: create Contribution aggregate
:card_file_box: add events table
:recycle: move contribution aggregate out of entity folder
:sparkles: implement EventStore for Database
:recycle: remove dependency on eventually and re-implement needed traits
:sparkles: translate starknet events into contribution events
:coffin: remove unused event
:recycle: create HexStringWrapper and use it as Contribution aggregate ID
:recycle: event should contain aggregate id

Why did you end up not using eventually? I found it pretty clear tu use, but I'm also ok with having our own traits and implementations since it's not a big part.

It required too many things to implement that were not needed, so it was quicker to create our own traits

From what I understood in the end of the PR, you still need to add actual event sourcing right? Meaning being able to create a ContributionAggregate from an event stream, updating projections etc.

Indeed, but the PR was already big enough :-)

The Aggregate trait shouldn't be located in the events folder IMHO, it is a basic building block in the domain, it should live right in marketplace-domain/src.

You're right, I will change that

It is not in the scope of this PR but at some point you will introduce a ContributionAggregateRepository, needed to perform backend business actions such as apply to contribution. This repository will differ from the projections' ones because it will be fully implemented in the domain, getting injected the EventStore and iteration over the events calling the aggregate's apply – apply event, not apply to contribution. Beware that this repository will obviously not have any write method.

Indeed, it will soon be needed, as well as the event bus trait

Final remark, I don't think it's a good idea to add business checks in the apply method of an aggregate. One must consider that once the event reached the event store, it is valid in the stream of events business-wise. In our case, this is ensured by the blockchain, and by the code we will add to handle contribution application that will make business checks before emitting an event.
Having a check at this point brings the risk of "bricking" a contribution, meaning not being able to recreate the aggregate from the event stream, and thus making any action on this contribution impossible. This is to avoid at any cost.

Got it, I will remove the checks and turn the return value from Result<Event> to Event


Devop/pre render

Devop

[ ] Updated CHANGELOG.md
[ ] Add PR label
[ ] No hard-coded strings

Feature

[ ] Updated CHANGELOG.md
[ ] Is this a user submitted feature request?

[ ] Link to issue:

[ ] Add test cases or procedure
[ ] Add PR label
[ ] No hard-coded strings

Bug

[ ] Updated CHANGELOG.md
[ ] Is this a user submitted bug?

[ ] Link to issue:

[ ] Add PR label
[ ] No hard-coded strings

Release

[ ] Updated CHANGELOG.md
[ ] Created a release

[ ] Link to release:

[ ] Add PR label
[ ] Updated package.json version
[ ] No hard-coded strings

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@7d27352). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master       #1   +/-   ##
=========================================
  Coverage          ?   13.89%
=========================================
  Files             ?      476
  Lines             ?    19185
  Branches          ?     3256
=========================================
  Hits              ?     2665
  Misses            ?    15654
  Partials          ?      866

Continue to review full report at Codecov.

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


Models Unnecessarily Destroyed and Recreated During Plan and Apply Phases

Expected Behavior:
The expected behavior is that the Terraform plan should recognize the existing state of the OpenAI models and not mark them for destruction and re-creation if there are no changes to the model configurations.
Actual Behavior:
During the Terraform plan and apply phases, OpenAI models are being marked for destruction and re-creation, despite no changes to the configuration. The cognitive_account_id and id attributes are shown as forces replacement, which suggests a possible issue with state recognition or configuration drift.
Steps to Reproduce:
It doesn't happens always but the steps are:

Write a Terraform configuration that includes an azurerm_cognitive_deployment resource.
Run terraform apply to create the resources.
Without making any changes to the configuration, run terraform plan or terraform apply again.
Observe that the resources are marked for replacement despite no changes.

@jkfran
Is the note behavior if you build a new OpenAI Service or use an existing one?
Can you confirm if you are building the Service as part of the model deployment, or just a model deployment on an existing service built already outside of the terraform module.

@Pwd9000-ML It happens from time to time when I perform modifications in the OpenAI deployments. The last time was when a adding a new deployment on a new region. All the previous deployments were destroyed and recreated because of this.

@jkfran
This makes sense and thanks for contributing to a fix


fix(cheatcodes): coerce root values

Motivation
Fixes https://github.com/foundry-rs/foundry/issues/6437
Don't know why we wouldn't coerce root values too, cc @odyslam as initial implementer

Solution

Initial implementation for reference: https://github.com/foundry-rs/foundry/blob/ee5d02c3ef5f55a06b069e4a70a820661a9130c8/crates/evm/src/executor/inspector/cheatcodes/ext.rs#L327-L376
root key always encodes as bytes, i don't believe this worked before either


Upgrade Ansible, Terraform and Alpine

Alpine 3.18 -> 3.20
Ansible 9.4.0 -> 10.5.0 Version 9 is EOL next month!
Terraform 1.8.2 -> 1.9.8
I didn't touch opentofu, since I canot test it.
Also, the web interface of the semaphore was broken when I upgraded the go version from 1.22 to 1.23. So I stayed with version 1.22, but there on alpine 3.20.
Terraform and ansible are working fine, but there is one warning for ansible:
[WARNING]: Platform linux on host myvm1 is using the discovered
Python interpreter at /usr/bin/python3.10, but future installation of another
Python interpreter could change the meaning of that path. See
https://docs.ansible.com/ansible-
core/2.17/reference_appendices/interpreter_discovery.html for more information.

@bbaassssiiee In the meantime there is ansible 10.6.0, I have adapted the PR. It includes some security and bugfixes.

Off-topic: Shouldn't Semaphore be configurable with regards to the ansible or ansible-core+collections and versions?

@fiftin Are there any plans for when these changes (or parts of them) will be implemented? In a few days ansible 9 will be EOL. Is there anything against keeping the versions up to date?

Lets create separate PR for each improvement.


Codeium does not work affter auth

affter I authanticate I see no sugestions.
using nvim 0.10

See https://github.com/Exafunction/codeium.vim/issues/376 - using the previous commit works.


Support NFS v3

https://github.com/willscott/go-nfs/

seems the go-nfs is not production ready yet.

is there any possibility to support nfs?

not any time soon


Add timeout to read from channel in GetBlobOperation

Currently, a GetBlobOperation will not be completed when the user does not end up reading from GetBlobResult.  A possible solution is to add a timeout that completes the operation if the user does not read from GetBlobResult in a reasonable timespan.

@cgtz @pnarayanan has referenced this - did that PR fix this bug?

@vgkholla No, this bug has not been addressed yet.


how to remove the ads?

i do not want to use the appodeal ads feature and i do not have the appodeal key. is there a way to completely remove appodeal sdk?

Hello! We've just published new release. Check it out. If you leave appodeal key in config empty - there will not be any ads. Is it help?

yes, it is working now without ads.


[bug] Custom log transport for Home Assistant is causing the zwjs2mqtt container to crash and restart

Version
Checklist:

[x] I am not using HomeAssistant. Or: a developer has told me to come here.
[x] I have checked the troubleshooting section and my problem is not described there.
[x] I have read the changelog problem was not mentioned there.

Build/Run method

[x] Docker
[ ] PKG
[ ] Snap package
[ ] Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: 4.0.0
zwave-js version: 7.3.0
Describe the bug
I'm using the new custom log transport functionality with HA 2021.5.0b3 and as soon as I switch to the new logging tab in HA, HA sends the logging configuration to the server and the zwjs2mqtt container crashes and restarts.  I can reproduce this with the "latest" tag of the Docker hub zwavejs2mqtt container, my own container that I've built from the latest node-zwave-js and zwavejs2mqtt repos, and with the container that firstof9 is using successfully.
The only interesting log messages that I see when this happens are these from zwavejs2mqtt right at the point of failure, after which the container restarts:
This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:
Error: write after end
    at writeAfterEnd (/usr/src/app/node_modules/readable-stream/lib/_stream_writable.js:261:12)
    at PassThrough.Writable.write (/usr/src/app/node_modules/readable-stream/lib/_stream_writable.js:305:21)
    at File.log (/usr/src/app/node_modules/winston/lib/winston/transports/file.js:185:34)
    at File._write (/usr/src/app/node_modules/winston-transport/index.js:103:17)
    at doWrite (/usr/src/app/node_modules/winston-transport/node_modules/readable-stream/lib/_stream_writable.js:428:64)
    at writeOrBuffer (/usr/src/app/node_modules/winston-transport/node_modules/readable-stream/lib/_stream_writable.js:417:5)
    at File.Writable.write (/usr/src/app/node_modules/winston-transport/node_modules/readable-stream/lib/_stream_writable.js:334:11)
    at DerivedLogger.ondata (/usr/src/app/node_modules/readable-stream/lib/_stream_readable.js:681:20)
    at DerivedLogger.emit (node:events:390:22)
    at DerivedLogger.EventEmitter.emit (node:domain:470:12)

I only see normal ZWave traffic prior to that, and then that, and then the container restarts.
The HA logs look like this:
2021-04-30 12:08:16 DEBUG (MainThread) [zwave_js_server] Received message:
WSMessage(type=<WSMsgType.TEXT: 1>, data='{"type":"result","success":true,"messageId":"cbf8b366f65b4fdc81e33a905044536c","result":{"config":{"enabled":true,"level":"debug","logToFile":true,"filename":"/usr/src/app/store/zwavejs_1.log","forceConsole":true}}}', extra='')
2021-04-30 12:08:40 DEBUG (MainThread) [zwave_js_server] Received message:
WSMessage(type=<WSMsgType.TEXT: 1>, data='{"type":"event","event":{"source":"driver","event":"logging","formattedMessage":"2021-04-30T19:08:40.568Z DRIVER   destroying driver instance...","level":"verbose","message":"destroying driver instance...","direction":"  ","label":"DRIVER","timestamp":"2021-04-30T19:08:40.568Z","multiline":false,"secondaryTagPadding":-1}}', extra='')
2021-04-30 12:08:40 DEBUG (MainThread) [zwave_js_server] Listen completed. Cleaning up
2021-04-30 12:08:40 INFO (MainThread) [homeassistant.components.zwave_js] Disconnected from server. Reloading integration

From that, it appears that HA attempted to set the logging parameters, and 24s later it received a message about the driver instance being destroyed.
The log window in the zwavejs2mqtt web UI correctly shows the logs and the log level adjusts based on what I've configured in the web UI, so it seems to only affect interaction with HA over the custom log transport.
It seems like I may be the only one currently seeing this issue, as others on Discord do not.  You can see the full discussion here: https://discord.com/channels/330944238910963714/427516175237382144/837746193193762866.
I suspect that it has something to do with the files in my Store, but I wanted to get some guidance on where to look before going scorched earth on my working, production config.
To Reproduce
Steps to reproduce the behavior:
Using Home Assistant 2021.5.0b3 and a properly configured zwavejs2mqtt container connected through the websocket server, go to Configuration->Integrations->Zwave_js->Configure->Logs.  Note that the only message that appears in the log window is:
2021-04-30T21:36:42.095Z DRIVER   destroying driver instance...
This message indicates that the zwavejs2mqtt container crashed, and will repeat if I refresh the page, or the page loses focus and regains it.  Logging in the zwavejs2mqtt log window appears normally.
Expected behavior
I expect the same logging that shows up in the zwavejs2mqtt logger UI to show up in HA, and for the zwavejs2mqtt container to not crash and restart.
Additional context
Add any other context about the problem here.

Humm I think this bug is on zwave-js side? @AlCalzone


ResourceLoader: Use better error handling for possible engine bugs

As suggested by @akien-mga.

Thanks!

Cherry-pick for 4.3 included in #96606.


Blender is built without draco support

Describe the bug
Blender's glTF exporter supports compressing meshes with draco, but this is disabled at compile time due to WITH_PYTHON_INSTALL=OFF. With WITH_PYTHON_INSTALL=ON, the (vendored) draco library gets built and placed in $out/share/blender/3.3/python/lib/python3.10/site-packages/libextern_draco.so. Opening the glTF export dialog at run time however prints the following message to the console:
ERROR: Draco mesh compression is not available because library could not be found at /nix/store/rimv365v1hlzb5lsjsbkgfh346w7l6na-blender-3.3.1/bin/3.3/python/lib/python3.10/site-packages/libextern_draco.so
Expected behavior
Compression options are available in the glTF exporter like on other platforms.
Notify maintainers
@cillianderoiste @veprbl
Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.2.0, NixOS, 23.05 (Stoat), 23.05.git.d0d55259081M`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.13.2`
 - channels(root): `"nixos"`
 - channels(user): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos

This one just bit me too...


Snyk demo

Just a demo, this should not be merged

 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.


feat: add harper-ls

@Conarius harper now has a non-proprietary license: https://github.com/chilipepperhott/harper/commit/6558880ffa08ea8fdec5bfaf738cfec0dd77f2e3

@mawkler Thanks, will change it

#4690 is the same thing, but a bit more fleshed out and from the harper maintainer


corrupt file handling in ImageFolder

Its frustrating to see entire training stops because of one corrupt file in the dataset folder and This should be a easy fix using PIL's  Image.verify() This method attempts to determine if the file is broken, without actually decoding the image data. I did some checks to see if this can be added
but after reading file folder.py It came to my notice that the method is_image_file is never invoked by ImageFolder and if this can be changed then making this update is easy.

@dhananjayraut , i see here
https://github.com/pytorch/vision/blob/ccbb3221b7f0637f1706df29d2c2995e9d5171bf/torchvision/datasets/folder.py#L86
redirects to
https://github.com/pytorch/vision/blob/ccbb3221b7f0637f1706df29d2c2995e9d5171bf/torchvision/datasets/folder.py#L45
where  has_file_allowed_extension(fname, extensions) is called which is working similiar to the is_image_file .
Here adding this verify condition can be a simple fix.

@surgan12 This code is for parent class DatasetFolder which is more general class than ImageFolder and adding verify there will not be correct as this class can be used at some other place.

@dhananjayraut how much slowdown would it bring to add such check into main torchvision? Parsing the file tree is already fairly slow in some filesystems.
Another solution is to inherit from ImageFolder, and perform an extra pre-processing step that removes invalid images.
class MyDataset(ImageFolder):
    def __init__(self, ...):
        super(MyDataset, self.__init__(...)
        valid_samples = [s for s in self.imgs if Image.verify(s[0])]
        self.imgs = valid_samples

or something like that

I know time can be constrain a quick script shows me average time of 3.08e-05 per image with check then normal 3.68e-07 . This will be one time thing when we are creating a Dataset. The problem with your solution is we need to modify self.samples with list of tuples (path, class_to_idx[target] ) and update bunch of things like self.targets etc this basically means the user has to implement ImageFolder on it own.

@dhananjayraut the user only need to implement the aforementioned 4 lines, and use it instead.
I would be willing to accept a PR that adds greater flexibility in DatasetFolder to specify the if a file is valid or not.
This would probably mean letting the user pass a callable to DatasetFolder which returns True if the file is valid.
So the user would be able to customize as he wants the loading of the files.
Thoughts?

@fmassa That would be a nice addition as a ImageFolder class needs to do more than just checking extension. Would like to work on that. Any points about design will be great to discuss before actually writing
code.

Some points:

extensions become an optional argument in https://github.com/pytorch/vision/blob/ccbb3221b7f0637f1706df29d2c2995e9d5171bf/torchvision/datasets/folder.py#L81
add a is_valid_file or something like that in the constructor
assert that either extensions or is_valid_file is passed
replace https://github.com/pytorch/vision/blob/ccbb3221b7f0637f1706df29d2c2995e9d5171bf/torchvision/datasets/folder.py#L45 with the new function, making sure to keep backwards compatibility

which one will be better

keep extensions compulsory and add a optional is_valid_file which will only be called for valid extension files or
making extensions optional and one of is_valid_file or extension compulsory.

first one will be more natural  plus will not make user handle extensions if he decide to pass optional callable.
second will be more standard for a library .
both will be backward compatible of course.

I think we should make both optional, requiring that one and only one is passed and non-None
This is how it's done for batch_sampler / sampler / batch_size and drop_last in DataLoader

@fmassa the official documentation for dataset folder (link) should say that is_valid_file is a callable I don't know why it is not there(the python file has it). also please remove the Image word it's not correct.


PDF Export is not working

Does this solution to export the presentation to PDF work in your case? I was able to get only first two slides exported into pdf-like view (see the screenshot below).

Thanks for your response and great template,
Ales

@kuchaale Hey yeh it is possible but very tricky! Actually you have to replace the custom.css with the standard theme. The output doesn't look very good though. Here is an example. Anyways, I'm planning to redesign the custom.css and build it on top of the standard theme, so that the export would also look well. Stay tuned!

@kuchaale Check out the new changes!!! ?print-pdf works now but it's not very good. I'm using decktape instead. Check out the generated pdf from the demo. The color are changed as well.


https://discord.gg/wcWETcAkvS

replace w/ never expiring invite link

cc @jpfeuffer.
(i can't edit, it created a pr).


Add support for returning Table ID as a Column (EXTRA_PHYSICAL_TABLE_ID_COL_ID)

Feature Request
Is your feature request related to a problem? Please describe:

In TiDB, table partitioning is implemented by having several physical tables presented as one logical table, where each partition is mapped to a Physical Table ID.
When dynamic prune mode for table partitioning was implemented, a single TableReader was used for all needed partitions, and sent a coprocessor requests which included multiple Physical Table ID ranges resulting in row data could come from several partitions in the result chunk. This works well for handling the data, but if there is an ongoing transaction or pessimistic locks are requested (SELECT FOR UPDATE/SelectLock) then each row needs to have which partition/physical table id it came from, to be able to lookup in TiDBs transaction buffer or to send a lock to TiKV (which both needs the Physical Table ID).
Since the Physical Table ID is encoded in the Key for each row in the KV Store, we could solve this problem if the Physical Table ID could be added as an extra column in the result chunk.
Describe the feature you'd like:

Add a static column id '-3' / EXTRA_PHYSICAL_TABLE_ID_COL_ID, similar to int handle (-1) or EXTRA_PARTITION_ID_COL_ID (-2).
If a column with id -3 is requested, use the Table ID from the Key to fill in its 64 bit integer value. This should be done for both index and table reads.
Describe alternatives you've considered:

Add all partitioning columns to the read request and then recalculate which partition the row came from (a lot of overhead, both data/network wise and processing wise). Would not work for indexes not including all partitioning columns
Get full key for each row and decode the table id on TiDB side. More data and processing overhead, similar implementation and no other use case yet.

Teachability, Documentation, Adoption, Migration Strategy:

Proof of Concept for TiDB UniStore, see the unistore path code changes for details, model.ExtraPhysTblID is what is proposed to be EXTRA_PHYSICAL_TABLE_ID_COL_ID in TiKV.

IMHO we don't have to return EXTRA_PHYSICAL_TABLE_ID_COL_ID for cases when locks are not needed. Would you consider how the 'request' proto can be updated to tell TiKV when the extra ID is requested?
Also, as a reference, the PR that introduces EXTRA_PHYSICAL_TABLE_ID_COL_ID is #8603.

IMHO we don't have to return EXTRA_PHYSICAL_TABLE_ID_COL_ID for cases when locks are not needed. Would you consider how the 'request' proto can be updated to tell TiKV when the extra ID is requested?

TIDB would only add the request for EXTRA_PHYSICAL_TABLE_ID_COL_ID when it is needed, so for an auto-commit query it would not add it to the requested columns.

Also, as a reference, the PR that introduces EXTRA_PHYSICAL_TABLE_ID_COL_ID is #8603.

That would be for the EXTRA_PARTITION_ID_COL_ID, which is a value in a global index 'row' referencing the table partition's physical table id where the table data is stored.
EXTRA_PHYSICAL_TABLE_ID_COL_ID is not yet implemented, which is what this Feature Request.

Yes, it should be EXTRA_PARTITION_ID_COL_ID, my typo!

TIDB would only add the request for EXTRA_PHYSICAL_TABLE_ID_COL_ID when it is needed, so for an auto-commit query it would not add it to the requested columns.

I see, it was described here:

If a column with id -3 is requested ...

Thanks!

I have an implemention related question about this extra column:
After generate this column in TableScan or IndexScan, will this column be treated as a normal column or still a special column in the subsequent processing?
Consider the following query as a example:
select count(id) from partition_table
Then the cop request should be something like this
TableScan(col: id, col: extra_physical_table_id_col_id) => aggregation
If we treated as a normal column, then it's TiDB's job to rewrite the aggregation in cop request to aggregation(agg_func: count(id), group_by: extra_physical_table_id_col_id)
In this case I think current coprocessor protocal can support it directly.
If we treated as a special column, then the aggregation in cop request is aggregation(agg_func: count(id), group by: )
if we still wants to add extra_physical_table_id_col_id for each row returned by the aggregation executor, it will be a little tricky, since we need extra logical to append the extra_physical_table_id_col_id to the result chunk. And things become much more complex for TiFlash, because TiFlash support MPP and BatchCoprocessor, it will batch all the regions in one TiFlash node into one request, that means the TableScan will read data from multiple partitions, and aggregation only return 1 row, so which extra_physical_table_id_col_id should be append to the return row in this case?

@windtalker Thanks for pointing out this, I think the handle of the extra column should be treated as the special column(and we need to handle it very carefully).
It's not just about aggregation, if we decide to apply this proposal, other executors like Limit, TopN should be considered as well, which is non-trivial.

@windtalker The only times the physical table id is needed is:

SelectLock used by SELECT ... FOR UPDATE, when TiDB needs to send pessimistic row lock to TiKV with the correct physical table id
In ongoing transaction in TiDB, where the physical table id per row is needed for checking against the TiDB local transaction buffer, if the row is changed within the transaction.
Both cases is for non-aggregated rows, similar to when ExtraHandleID (-1) is requested.

I did a quick test with begin; insert into t values (1) ; select count(*) from t and TiDB will not use any coprocessor for aggregation, but simply issue a full table scan and go through the UnionScan executor which merges the table scan data with the transaction buffer and then have a StreamAgg on top of the UnionScan. Same with LIMIT (it will add a limit on top of the UnionScan).
So I think it is OK to simply treat extra_physical_table_id_col_id as a normal column, and leave it up to TiDB handle for future aggregation/coprocessor support, where needed.
I assume this is similar to how the ExtraHandleID (-1) is handled by TiDB, so until we find something that would break this assumption, we should be OK to treat the different Extra*ID columns the same. I can see possible optimisation for partitions, but those could probably be done in TiDB instead (similar to how static pruning uses one TableReader per partition, it may be possible to do that dynamically as well for such future enhancements 🤷 )
@qw4990 Is that correct that for SelectLockExec and UnionScanExec it will not use any coprocessor aggregation etc. that would be a problem?

ds to send pessimis

Limit and TopN should not be a big problem since it does not change the result schema, so if the input schema contains extra_physical_table_id_col_id, we can expect the output schema contains extra_physical_table_id_col_id too.
So if the coprocessor request is something like
TableScan => TopN
if the TableScan returns chunk with extra_physical_table_id_col_id, it is straightforward that the TopN returns chunk with extra_physical_table_id_col_id

begin; insert into t values (1) ; select count(*) from t

I think TiDB does not use coprocessor for aggregation because there are uncommited data for t, if you try
begin; select count(*) from t
TiDB should push down aggregation to TiKV.

begin; insert into t values (1) ; select count(*) from t

I think TiDB does not use coprocessor for aggregation because there are uncommited data for t, if you try begin; select count(*) from t TiDB should push down aggregation to TiKV.

Yes that is correct, and then we don't need the physical table id either. This is handled when there are uncommitted data here. So I think it is OK.

begin; insert into t values (1) ; select count(*) from t

I think TiDB does not use coprocessor for aggregation because there are uncommited data for t, if you try begin; select count(*) from t TiDB should push down aggregation to TiKV.

Yes that is correct, and then we don't need the physical table id either. This is handled when there are uncommitted data here. So I think it is OK.

So you mean when reading from a table, the physical table id is only needed if there is uncommitted data for that table? If yes, then things become quite simple because AFAIK if a table has dirty data, only TableScan/IndexScan/Selection can be pushed to the storage layer, we don't need to consider complex executor like aggregation and join.

So you mean when reading from a table, the physical table id is only needed if there is uncommitted data for that table? If yes, then things become quite simple because AFAIK if a table has dirty data, only TableScan/IndexScan/Selection can be pushed to the storage layer, we don't need to consider complex executor like aggregation and join.

Yes, the physical table id is only needed when there is either uncommitted data or there is a need to lock rows (like SELECT FOR UPDATE/SelectLock). So no need to consider complex executors like aggregation or join, since current TiDB planner would not request any of these complex coprocessor executors but handle it in TiDB after handling either transaction data (UnionScan that merges current query with the sessions non-committed transaction buffer) or setting a row lock (SelectLock executor in TiDB).

/type feature-request


Current iteration during build

Is there a way of knowing the name of current iteration during the build? The @CurrentIteration macro doesn't work, at the moment I have to update the value manually the build definition for each sprint.
Could be something like System.TeamProjectIteration/CurrentIteration

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

ID: 9ffebdc8-521c-44b5-cde4-4abdc1bd6f18
Version Independent ID: dc0effda-6d93-62aa-64c5-4e6f283b0826
Content: Predefined variables - Azure Pipelines
Content Source: docs/pipelines/build/variables.md
Product: devops
Technology: devops-cicd
GitHub Login: @andyjlewis
Microsoft Alias: alewis

Hi, I've created a feature request on DeveloperCommunity about it, please vote for it and hopefully it'll get implemented.
Link: https://developercommunity.visualstudio.com/idea/560221/making-the-team-project-iteration-number-available.html

Thanks

Thanks for your question. It looks like your question isn't an issue with the documentation, but an issue or question specific to your implementation or a bug in the product itself.
For help with a specific task, here are a couple of options where you might consider asking your question:

Azure DevOps on Stack Overflow
Azure DevOps Support Bot

If you've encountered an issue with the product itself, to make sure it gets in front of the right people, please submit your bug here.
If you have an idea for improving the product, please submit your idea here.


fix(modal): body content shift

Implements TWBS body padding fix to keep content in an element with a container class from shifting when the body overflow is set to hidden with the modal-open class.
Fixes #2631

Thanks for doing this! We might want to add some tests for the new logic in position service?

Tests are difficult when it comes to DOM interaction.  You will notice most of the tests in the position module actually mock the DOM aspects (see offset test where it returns a mocked clientRect).  I don't know if testing against mocked values really does anything for us?

We need to eventually modify the build system to run tests via SauceLabs/Browserstack and run positioning tests across browsers.

This LGTM