Fail to start after an update

Deployment Method

[ ] Installer
[X] Docker Development
[ ] Docker Production
[ ] Bare metal Development
[ ] Bare metal Production
[ ] Digital Ocean image
[ ] Other (please provide a link Steps to Reproduce

Describe the problem*
After a recent update to a docker devel install (docker-compose pull, docker-compose run inventree-server invoke update) InvenTree fails to start at all. I've got a pretty long stream of errors coming out of things here and not really sure what to make of them.
Steps to Reproduce

Upgrade: docker-compose pull, docker-compose up -d, docker-compose run inventree-server invoke update
Start inventree using docker-compose up and watch the log.

Relevant log output
Starting inventree-db ... done
Starting inventree-server ... done
Starting inventree-worker ... done
Starting inventree-proxy  ... done
Attaching to inventree-db, inventree-server, inventree-proxy, inventree-worker
inventree-db        |
inventree-db        | PostgreSQL Database directory appears to contain a database; Skipping initialization
inventree-db        |
inventree-db        | 2023-03-26 05:44:34.502 UTC [1] LOG:  starting PostgreSQL 13.10 (Debian 13.10-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
inventree-db        | 2023-03-26 05:44:34.502 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
inventree-db        | 2023-03-26 05:44:34.502 UTC [1] LOG:  listening on IPv6 address "::", port 5432
inventree-db        | 2023-03-26 05:44:34.505 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
inventree-db        | 2023-03-26 05:44:34.523 UTC [29] LOG:  database system was shut down at 2023-03-26 05:40:52 UTC
inventree-db        | 2023-03-26 05:44:34.530 UTC [1] LOG:  database system is ready to accept connections
inventree-proxy     | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
inventree-proxy     | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
inventree-proxy     | /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
inventree-proxy     | 10-listen-on-ipv6-by-default.sh: info: can not modify /etc/nginx/conf.d/default.conf (read-only file system?)
inventree-proxy     | /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
inventree-proxy     | /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
inventree-proxy     | /docker-entrypoint.sh: Configuration complete; ready for start up
inventree-server    | Loading config file : /home/inventree/data/config.yaml
inventree-worker    | Loading config file : /home/inventree/data/config.yaml
inventree-proxy     | 2023/03/26 05:44:35 [notice] 1#1: using the "epoll" event method
inventree-proxy     | 2023/03/26 05:44:35 [notice] 1#1: nginx/1.22.1
inventree-proxy     | 2023/03/26 05:44:35 [notice] 1#1: built by gcc 10.2.1 20210110 (Debian 10.2.1-6)
inventree-proxy     | 2023/03/26 05:44:35 [notice] 1#1: OS: Linux 5.10.0-21-amd64
inventree-proxy     | 2023/03/26 05:44:35 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
inventree-proxy     | 2023/03/26 05:44:35 [notice] 1#1: start worker processes
inventree-proxy     | 2023/03/26 05:44:35 [notice] 1#1: start worker process 24
inventree-proxy     | 2023/03/26 05:44:35 [notice] 1#1: start worker process 25
inventree-proxy     | 2023/03/26 05:44:35 [notice] 1#1: start worker process 26
inventree-proxy     | 2023/03/26 05:44:35 [notice] 1#1: start worker process 27
inventree-db        | 2023-03-26 05:44:39.237 UTC [36] ERROR:  column part_bomitem.metadata does not exist at character 29
inventree-db        | 2023-03-26 05:44:39.237 UTC [36] STATEMENT:  SELECT "part_bomitem"."id", "part_bomitem"."metadata", "part_bomitem"."part_id", "part_bomitem"."sub_part_id", "part_bomitem"."quantity", "part_bomitem"."optional", "part_bomitem"."consumable", "part_bomitem"."overage", "part_bomitem"."reference", "part_bomitem"."note", "part_bomitem"."checksum", "part_bomitem"."validated", "part_bomitem"."inherited", "part_bomitem"."allow_variants" FROM "part_bomitem" INNER JOIN "part_part" ON ("part_bomitem"."part_id" = "part_part"."id") INNER JOIN "part_part" T3 ON ("part_bomitem"."sub_part_id" = T3."id") WHERE (NOT "part_part"."trackable" AND T3."trackable")
inventree-db        | 2023-03-26 05:44:39.445 UTC [37] ERROR:  column part_bomitem.metadata does not exist at character 29
inventree-db        | 2023-03-26 05:44:39.445 UTC [37] STATEMENT:  SELECT "part_bomitem"."id", "part_bomitem"."metadata", "part_bomitem"."part_id", "part_bomitem"."sub_part_id", "part_bomitem"."quantity", "part_bomitem"."optional", "part_bomitem"."consumable", "part_bomitem"."overage", "part_bomitem"."reference", "part_bomitem"."note", "part_bomitem"."checksum", "part_bomitem"."validated", "part_bomitem"."inherited", "part_bomitem"."allow_variants" FROM "part_bomitem" INNER JOIN "part_part" ON ("part_bomitem"."part_id" = "part_part"."id") INNER JOIN "part_part" T3 ON ("part_bomitem"."sub_part_id" = T3."id") WHERE (NOT "part_part"."trackable" AND T3."trackable")
inventree-db        | 2023-03-26 05:44:39.506 UTC [38] ERROR:  column part_bomitem.metadata does not exist at character 29
inventree-db        | 2023-03-26 05:44:39.506 UTC [38] STATEMENT:  SELECT "part_bomitem"."id", "part_bomitem"."metadata", "part_bomitem"."part_id", "part_bomitem"."sub_part_id", "part_bomitem"."quantity", "part_bomitem"."optional", "part_bomitem"."consumable", "part_bomitem"."overage", "part_bomitem"."reference", "part_bomitem"."note", "part_bomitem"."checksum", "part_bomitem"."validated", "part_bomitem"."inherited", "part_bomitem"."allow_variants" FROM "part_bomitem" INNER JOIN "part_part" ON ("part_bomitem"."part_id" = "part_part"."id") INNER JOIN "part_part" T3 ON ("part_bomitem"."sub_part_id" = T3."id") WHERE (NOT "part_part"."trackable" AND T3."trackable")
inventree-db        | 2023-03-26 05:44:39.725 UTC [39] ERROR:  column part_bomitem.metadata does not exist at character 29
inventree-db        | 2023-03-26 05:44:39.725 UTC [39] STATEMENT:  SELECT "part_bomitem"."id", "part_bomitem"."metadata", "part_bomitem"."part_id", "part_bomitem"."sub_part_id", "part_bomitem"."quantity", "part_bomitem"."optional", "part_bomitem"."consumable", "part_bomitem"."overage", "part_bomitem"."reference", "part_bomitem"."note", "part_bomitem"."checksum", "part_bomitem"."validated", "part_bomitem"."inherited", "part_bomitem"."allow_variants" FROM "part_bomitem" INNER JOIN "part_part" ON ("part_bomitem"."part_id" = "part_part"."id") INNER JOIN "part_part" T3 ON ("part_bomitem"."sub_part_id" = T3."id") WHERE (NOT "part_part"."trackable" AND T3."trackable")
inventree-worker    | Waiting for database...
inventree-server    | WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
inventree-server    | WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
inventree-server    | [2023-03-26 05:44:41 +0000] [11] [ERROR] Exception in worker process
inventree-server    | Traceback (most recent call last):
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/arbiter.py", line 589, in spawn_worker
inventree-server    |     worker.init_process()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/workers/gthread.py", line 92, in init_process
inventree-server    |     super().init_process()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/workers/base.py", line 134, in init_process
inventree-server    |     self.load_wsgi()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/workers/base.py", line 146, in load_wsgi
inventree-server    |     self.wsgi = self.app.wsgi()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/app/base.py", line 67, in wsgi
inventree-server    |     self.callable = self.load()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/app/wsgiapp.py", line 58, in load
inventree-server    |     return self.load_wsgiapp()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/app/wsgiapp.py", line 48, in load_wsgiapp
inventree-server    |     return util.import_app(self.app_uri)
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/util.py", line 359, in import_app
inventree-server    |     mod = importlib.import_module(module)
inventree-server    |   File "/usr/local/lib/python3.9/importlib/__init__.py", line 127, in import_module
inventree-server    |     return _bootstrap._gcd_import(name[level:], package, level)
inventree-server    |   File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
inventree-server    |   File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
inventree-server    |   File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
inventree-server    |   File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
inventree-server    |   File "<frozen importlib._bootstrap_external>", line 850, in exec_module
inventree-server    |   File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
inventree-server    |   File "/home/inventree/InvenTree/InvenTree/wsgi.py", line 15, in <module>
inventree-server    |     application = get_wsgi_application()  # pragma: no cover
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/django/core/wsgi.py", line 12, in get_wsgi_application
inventree-server    |     django.setup(set_prefix=False)
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/django/__init__.py", line 24, in setup
inventree-server    |     apps.populate(settings.INSTALLED_APPS)
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/django/apps/registry.py", line 122, in populate
inventree-server    |     app_config.ready()
inventree-server    |   File "/home/inventree/InvenTree/plugin/apps.py", line 45, in ready
inventree-server    |     registry.load_plugins()
inventree-server    |   File "/home/inventree/InvenTree/plugin/registry.py", line 115, in load_plugins
inventree-server    |     _maintenance = bool(get_maintenance_mode())
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/maintenance_mode/core.py", line 42, in get_maintenance_mode
inventree-server    |     return backend.get_value()
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/maintenance_mode/backends.py", line 66, in get_value
inventree-server    |     return self.from_str_to_bool_value(statefile.read())
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/maintenance_mode/backends.py", line 21, in from_str_to_bool_value
inventree-server    |     raise ValueError("state value is not 0|1")
inventree-server    | ValueError: state value is not 0|1
inventree-server    | [2023-03-26 05:44:41 +0000] [12] [ERROR] Exception in worker process
inventree-server    | Traceback (most recent call last):
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/arbiter.py", line 589, in spawn_worker
inventree-server    |     worker.init_process()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/workers/gthread.py", line 92, in init_process
inventree-server    |     super().init_process()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/workers/base.py", line 134, in init_process
inventree-server    |     self.load_wsgi()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/workers/base.py", line 146, in load_wsgi
inventree-server    |     self.wsgi = self.app.wsgi()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/app/base.py", line 67, in wsgi
inventree-server    |     self.callable = self.load()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/app/wsgiapp.py", line 58, in load
inventree-server    |     return self.load_wsgiapp()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/app/wsgiapp.py", line 48, in load_wsgiapp
inventree-server    |     return util.import_app(self.app_uri)
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/util.py", line 359, in import_app
inventree-server    |     mod = importlib.import_module(module)
inventree-server    |   File "/usr/local/lib/python3.9/importlib/__init__.py", line 127, in import_module
inventree-server    |     return _bootstrap._gcd_import(name[level:], package, level)
inventree-server    |   File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
inventree-server    |   File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
inventree-server    |   File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
inventree-server    |   File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
inventree-server    |   File "<frozen importlib._bootstrap_external>", line 850, in exec_module
inventree-server    |   File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
inventree-server    |   File "/home/inventree/InvenTree/InvenTree/wsgi.py", line 15, in <module>
inventree-server    |     application = get_wsgi_application()  # pragma: no cover
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/django/core/wsgi.py", line 12, in get_wsgi_application
inventree-server    |     django.setup(set_prefix=False)
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/django/__init__.py", line 24, in setup
inventree-server    |     apps.populate(settings.INSTALLED_APPS)
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/django/apps/registry.py", line 122, in populate
inventree-server    |     app_config.ready()
inventree-server    |   File "/home/inventree/InvenTree/plugin/apps.py", line 45, in ready
inventree-server    |     registry.load_plugins()
inventree-server    |   File "/home/inventree/InvenTree/plugin/registry.py", line 115, in load_plugins
inventree-server    |     _maintenance = bool(get_maintenance_mode())
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/maintenance_mode/core.py", line 42, in get_maintenance_mode
inventree-server    |     return backend.get_value()
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/maintenance_mode/backends.py", line 66, in get_value
inventree-server    |     return self.from_str_to_bool_value(statefile.read())
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/maintenance_mode/backends.py", line 21, in from_str_to_bool_value
inventree-server    |     raise ValueError("state value is not 0|1")
inventree-server    | ValueError: state value is not 0|1
inventree-server    | WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
inventree-server    | WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
inventree-server    | [2023-03-26 05:44:42 +0000] [10] [ERROR] Exception in worker process
inventree-server    | Traceback (most recent call last):
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/arbiter.py", line 589, in spawn_worker
inventree-server    |     worker.init_process()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/workers/gthread.py", line 92, in init_process
inventree-server    |     super().init_process()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/workers/base.py", line 134, in init_process
inventree-server    |     self.load_wsgi()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/workers/base.py", line 146, in load_wsgi
inventree-server    |     self.wsgi = self.app.wsgi()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/app/base.py", line 67, in wsgi
inventree-server    |     self.callable = self.load()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/app/wsgiapp.py", line 58, in load
inventree-server    |     return self.load_wsgiapp()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/app/wsgiapp.py", line 48, in load_wsgiapp
inventree-server    |     return util.import_app(self.app_uri)
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/util.py", line 359, in import_app
inventree-server    |     mod = importlib.import_module(module)
inventree-server    |   File "/usr/local/lib/python3.9/importlib/__init__.py", line 127, in import_module
inventree-server    |     return _bootstrap._gcd_import(name[level:], package, level)
inventree-server    |   File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
inventree-server    |   File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
inventree-server    |   File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
inventree-server    |   File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
inventree-server    |   File "<frozen importlib._bootstrap_external>", line 850, in exec_module
inventree-server    |   File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
inventree-server    |   File "/home/inventree/InvenTree/InvenTree/wsgi.py", line 15, in <module>
inventree-server    |     application = get_wsgi_application()  # pragma: no cover
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/django/core/wsgi.py", line 12, in get_wsgi_application
inventree-server    |     django.setup(set_prefix=False)
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/django/__init__.py", line 24, in setup
inventree-server    |     apps.populate(settings.INSTALLED_APPS)
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/django/apps/registry.py", line 122, in populate
inventree-server    |     app_config.ready()
inventree-server    |   File "/home/inventree/InvenTree/plugin/apps.py", line 45, in ready
inventree-server    |     registry.load_plugins()
inventree-server    |   File "/home/inventree/InvenTree/plugin/registry.py", line 115, in load_plugins
inventree-server    |     _maintenance = bool(get_maintenance_mode())
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/maintenance_mode/core.py", line 42, in get_maintenance_mode
inventree-server    |     return backend.get_value()
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/maintenance_mode/backends.py", line 66, in get_value
inventree-server    |     return self.from_str_to_bool_value(statefile.read())
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/maintenance_mode/backends.py", line 21, in from_str_to_bool_value
inventree-server    |     raise ValueError("state value is not 0|1")
inventree-server    | ValueError: state value is not 0|1
inventree-server    | [2023-03-26 05:44:42 +0000] [13] [ERROR] Exception in worker process
inventree-server    | Traceback (most recent call last):
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/arbiter.py", line 589, in spawn_worker
inventree-server    |     worker.init_process()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/workers/gthread.py", line 92, in init_process
inventree-server    |     super().init_process()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/workers/base.py", line 134, in init_process
inventree-server    |     self.load_wsgi()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/workers/base.py", line 146, in load_wsgi
inventree-server    |     self.wsgi = self.app.wsgi()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/app/base.py", line 67, in wsgi
inventree-server    |     self.callable = self.load()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/app/wsgiapp.py", line 58, in load
inventree-server    |     return self.load_wsgiapp()
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/app/wsgiapp.py", line 48, in load_wsgiapp
inventree-server    |     return util.import_app(self.app_uri)
inventree-server    |   File "/usr/local/lib/python3.9/site-packages/gunicorn/util.py", line 359, in import_app
inventree-server    |     mod = importlib.import_module(module)
inventree-server    |   File "/usr/local/lib/python3.9/importlib/__init__.py", line 127, in import_module
inventree-server    |     return _bootstrap._gcd_import(name[level:], package, level)
inventree-server    |   File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
inventree-server    |   File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
inventree-server    |   File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
inventree-server    |   File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
inventree-server    |   File "<frozen importlib._bootstrap_external>", line 850, in exec_module
inventree-server    |   File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
inventree-server    |   File "/home/inventree/InvenTree/InvenTree/wsgi.py", line 15, in <module>
inventree-server    |     application = get_wsgi_application()  # pragma: no cover
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/django/core/wsgi.py", line 12, in get_wsgi_application
inventree-server    |     django.setup(set_prefix=False)
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/django/__init__.py", line 24, in setup
inventree-server    |     apps.populate(settings.INSTALLED_APPS)
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/django/apps/registry.py", line 122, in populate
inventree-server    |     app_config.ready()
inventree-server    |   File "/home/inventree/InvenTree/plugin/apps.py", line 45, in ready
inventree-server    |     registry.load_plugins()
inventree-server    |   File "/home/inventree/InvenTree/plugin/registry.py", line 115, in load_plugins
inventree-server    |     _maintenance = bool(get_maintenance_mode())
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/maintenance_mode/core.py", line 42, in get_maintenance_mode
inventree-server    |     return backend.get_value()
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/maintenance_mode/backends.py", line 66, in get_value
inventree-server    |     return self.from_str_to_bool_value(statefile.read())
inventree-server    |   File "/root/.local/lib/python3.9/site-packages/maintenance_mode/backends.py", line 21, in from_str_to_bool_value
inventree-server    |     raise ValueError("state value is not 0|1")
inventree-server    | ValueError: state value is not 0|1
inventree-server    | [2023-03-26 05:44:42 +0000] [9] [WARNING] Worker with pid 13 was terminated due to signal 15
inventree-server    | [2023-03-26 05:44:42 +0000] [9] [WARNING] Worker with pid 12 was terminated due to signal 15
inventree-server    | [2023-03-26 05:44:42 +0000] [9] [WARNING] Worker with pid 10 was terminated due to signal 15

I can confirm that the same build with the same docker config runs fine on a fresh database, however, it also fails to restore from one of the backups from before.

It seems like the failure to start might be connected to #3618. But once I delete those files, it comes up with a lot of errors. I'm curious if maybe it crashed during a database operation and corrupted something.
I moved on to trying to restore from a backup ... here's what happens if I invoke restore with one of the recent backup files, including one that is not the most recent (so any database corruption shouldn't exist in it):
Starting inventree-db ... done
Loading config file : /home/inventree/data/config.yaml
Restoring InvenTree database...
Finding latest backup
Restoring backup for database 'default' and server 'None'
Restoring: default-98386126a188-2023-03-20-165050.psql.bin.gz
Restore tempfile created: 609.6 KiB
Traceback (most recent call last):
  File "/home/inventree/InvenTree/manage.py", line 23, in <module>
    execute_from_command_line(sys.argv)
  File "/root/.local/lib/python3.9/site-packages/django/core/management/__init__.py", line 419, in execute_from_command_line
    utility.execute()
  File "/root/.local/lib/python3.9/site-packages/django/core/management/__init__.py", line 413, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/root/.local/lib/python3.9/site-packages/django/core/management/base.py", line 354, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/root/.local/lib/python3.9/site-packages/django/core/management/base.py", line 398, in execute
    output = self.handle(*args, **options)
  File "/root/.local/lib/python3.9/site-packages/dbbackup/management/commands/dbrestore.py", line 68, in handle
    self._restore_backup()
  File "/root/.local/lib/python3.9/site-packages/dbbackup/management/commands/dbrestore.py", line 118, in _restore_backup
    self.connector.restore_dump(input_file)
  File "/root/.local/lib/python3.9/site-packages/dbbackup/db/base.py", line 105, in restore_dump
    return self._restore_dump(dump)
  File "/root/.local/lib/python3.9/site-packages/dbbackup/db/postgresql.py", line 124, in _restore_dump
    stdout, stderr = self.run_command(cmd, stdin=dump, env=self.restore_env)
  File "/root/.local/lib/python3.9/site-packages/dbbackup/db/base.py", line 171, in run_command
    raise exceptions.CommandConnectorError(
dbbackup.db.exceptions.CommandConnectorError: Error running:  pg_restore --dbname=postgresql://pguser:pgpassword@inventree-db:5432/inventree --single-transaction --clean
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 3886; 1259 18090 INDEX django_session_session_key_c0390e0f_like pguser
pg_restore: error: could not execute query: ERROR:  index "django_session_session_key_c0390e0f_like" does not exist
Command was: DROP INDEX public.django_session_session_key_c0390e0f_like;

This has me pretty baffled.

@alexisvl

could you check if you can run inv migrate without errors? The database might be corrupt.
Do you run stable version or dev?

invoke migrate works without issue, other than the usual "fatal: not a git repository" I always get a pile of (attached just in case, but I'm pretty sure they're normal). Bear in mind I am currently trying to restore into a fresh install (though I've also tried on the old one, and have it backed up) and have tried nuking it and starting fresh several times.
This is on the latest tag from dockerhub, so dev.
Starting inventree-db ... done
Loading config file : /home/inventree/data/config.yaml
Running InvenTree database migrations...
========================================
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
Migrations for 'part':
  part/migrations/0104_alter_partpricing_currency.py
    - Alter field currency on partpricing
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
Operations to perform:
  Apply all migrations: InvenTree, account, admin, auth, authtoken, build, common, company, contenttypes, django_q, error_report, exchange, label, order, otp_static, otp_totp, part, plugin, report, sites, socialaccount, stock, user_sessions, users
Running migrations:
  No migrations to apply.
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
Operations to perform:
  Synchronize unmigrated apps: allauth, allauth_2fa, corsheaders, crispy_forms, dbbackup, django_cleanup, django_filters, django_ical, django_otp, djmoney, formtools, import_export, maintenance_mode, markdownify, messages, mptt, rest_framework, staticfiles
  Apply all migrations: InvenTree, account, admin, auth, authtoken, build, common, company, contenttypes, django_q, error_report, exchange, label, order, otp_static, otp_totp, part, plugin, report, sites, socialaccount, stock, user_sessions, users
Synchronizing apps without migrations:
  Creating tables...
    Running deferred SQL...
Running migrations:
  No migrations to apply.
System check identified no issues (1 silenced).
========================================
InvenTree database migrations completed!
Rebuilding Part objects
Rebuilding PartCategory objects
Rebuilding StockItem objects
Rebuilding StockLocation objects
Rebuilding Build objects

@alexisvl do you still have access to the broken state? I know from the CI that latest is working on a fresh install, I am more interested in how/why the update broke.

Oh sorry, yes, I do have the full state from directly after the upgrade. I will try invoke migrate on that with the current version of the docker image it's running. I don't immediately have access to the old state with the old inventree version since that appears to no longer be accessible on dockerhub, so I can try building that locally from an old commit if needed

Running it on a direct copy of the old state brings me back to ValueError: state value is not 0|1. If I run find . -name 'maintenance_mode_state*.txt -delete again as before, I get some pretty unhappy messages:
Creating network "inventree_default" with the default driver
Creating inventree-db ... done
Loading config file : /home/inventree/data/config.yaml
Running InvenTree database migrations...
========================================
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
Traceback (most recent call last):
  File "/home/inventree/InvenTree/manage.py", line 23, in <module>
    execute_from_command_line(sys.argv)
  File "/root/.local/lib/python3.9/site-packages/django/core/management/__init__.py", line 419, in execute_from_command_line
    utility.execute()
  File "/root/.local/lib/python3.9/site-packages/django/core/management/__init__.py", line 395, in execute
    django.setup()
  File "/root/.local/lib/python3.9/site-packages/django/__init__.py", line 24, in setup
    apps.populate(settings.INSTALLED_APPS)
  File "/root/.local/lib/python3.9/site-packages/django/apps/registry.py", line 122, in populate
    app_config.ready()
  File "/home/inventree/InvenTree/plugin/apps.py", line 45, in ready
    registry.load_plugins()
  File "/home/inventree/InvenTree/plugin/registry.py", line 115, in load_plugins
    _maintenance = bool(get_maintenance_mode())
  File "/root/.local/lib/python3.9/site-packages/maintenance_mode/core.py", line 42, in get_maintenance_mode
    return backend.get_value()
  File "/root/.local/lib/python3.9/site-packages/maintenance_mode/backends.py", line 66, in get_value
    return self.from_str_to_bool_value(statefile.read())
  File "/root/.local/lib/python3.9/site-packages/maintenance_mode/backends.py", line 21, in from_str_to_bool_value
    raise ValueError("state value is not 0|1")
ValueError: state value is not 0|1
::carrot:~/e/inventree % sudo docker-compose run inventree-server invoke migrate                                                                                [1] [ 15:40 ]
Starting inventree-db ... done
Loading config file : /home/inventree/data/config.yaml
Running InvenTree database migrations...
========================================
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
/root/.local/lib/python3.9/site-packages/django/core/management/commands/makemigrations.py:105: RuntimeWarning: Got an error checking a consistent migration history performed for database connection 'default': FATAL:  database "inventree" does not exist

  warnings.warn(
Migrations for 'part':
  part/migrations/0104_alter_partpricing_currency.py
    - Alter field currency on partpricing
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
Traceback (most recent call last):
  File "/root/.local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 219, in ensure_connection
    self.connect()
  File "/root/.local/lib/python3.9/site-packages/django/utils/asyncio.py", line 33, in inner
    return func(*args, **kwargs)
  File "/root/.local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 200, in connect
    self.connection = self.get_new_connection(conn_params)
  File "/root/.local/lib/python3.9/site-packages/django/utils/asyncio.py", line 33, in inner
    return func(*args, **kwargs)
  File "/root/.local/lib/python3.9/site-packages/django/db/backends/postgresql/base.py", line 187, in get_new_connection
    connection = Database.connect(**conn_params)
  File "/usr/local/lib/python3.9/site-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
psycopg2.OperationalError: FATAL:  database "inventree" does not exist

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/inventree/InvenTree/manage.py", line 23, in <module>
    execute_from_command_line(sys.argv)
  File "/root/.local/lib/python3.9/site-packages/django/core/management/__init__.py", line 419, in execute_from_command_line
    utility.execute()
  File "/root/.local/lib/python3.9/site-packages/django/core/management/__init__.py", line 413, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/root/.local/lib/python3.9/site-packages/django/core/management/base.py", line 354, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/root/.local/lib/python3.9/site-packages/django/core/management/base.py", line 398, in execute
    output = self.handle(*args, **options)
  File "/root/.local/lib/python3.9/site-packages/django/core/management/base.py", line 89, in wrapped
    res = handle_func(*args, **kwargs)
  File "/root/.local/lib/python3.9/site-packages/django/core/management/commands/migrate.py", line 75, in handle
    self.check(databases=[database])
  File "/root/.local/lib/python3.9/site-packages/django/core/management/base.py", line 419, in check
    all_issues = checks.run_checks(
  File "/root/.local/lib/python3.9/site-packages/django/core/checks/registry.py", line 76, in run_checks
    new_errors = check(app_configs=app_configs, databases=databases)
  File "/root/.local/lib/python3.9/site-packages/django/core/checks/model_checks.py", line 34, in check_all_models
    errors.extend(model.check(**kwargs))
  File "/root/.local/lib/python3.9/site-packages/django/db/models/base.py", line 1303, in check
    *cls._check_indexes(databases),
  File "/root/.local/lib/python3.9/site-packages/django/db/models/base.py", line 1695, in _check_indexes
    connection.features.supports_covering_indexes or
  File "/root/.local/lib/python3.9/site-packages/django/utils/functional.py", line 48, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "/root/.local/lib/python3.9/site-packages/django/db/backends/postgresql/features.py", line 92, in is_postgresql_11
    return self.connection.pg_version >= 110000
  File "/root/.local/lib/python3.9/site-packages/django/utils/functional.py", line 48, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "/root/.local/lib/python3.9/site-packages/django/db/backends/postgresql/base.py", line 329, in pg_version
    with self.temporary_connection():
  File "/usr/local/lib/python3.9/contextlib.py", line 119, in __enter__
    return next(self.gen)
  File "/root/.local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 603, in temporary_connection
    with self.cursor() as cursor:
  File "/root/.local/lib/python3.9/site-packages/django/utils/asyncio.py", line 33, in inner
    return func(*args, **kwargs)
  File "/root/.local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 259, in cursor
    return self._cursor()
  File "/root/.local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 235, in _cursor
    self.ensure_connection()
  File "/root/.local/lib/python3.9/site-packages/django/utils/asyncio.py", line 33, in inner
    return func(*args, **kwargs)
  File "/root/.local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 219, in ensure_connection
    self.connect()
  File "/root/.local/lib/python3.9/site-packages/django/db/utils.py", line 90, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "/root/.local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 219, in ensure_connection
    self.connect()
  File "/root/.local/lib/python3.9/site-packages/django/utils/asyncio.py", line 33, in inner
    return func(*args, **kwargs)
  File "/root/.local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 200, in connect
    self.connection = self.get_new_connection(conn_params)
  File "/root/.local/lib/python3.9/site-packages/django/utils/asyncio.py", line 33, in inner
    return func(*args, **kwargs)
  File "/root/.local/lib/python3.9/site-packages/django/db/backends/postgresql/base.py", line 187, in get_new_connection
    connection = Database.connect(**conn_params)
  File "/usr/local/lib/python3.9/site-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
django.db.utils.OperationalError: FATAL:  database "inventree" does not exist

So, probable corruption I'd say. But I'm much more concerned at this point with why backups from a few days before this point fail to restore...

Alright, ultimately I was able to get something up. I had to restore from a json backup instead (invoke import-records) and then copy the contents of the media directory over manually. It looks like my issue with restore from json before was just not knowing about the -c option to import-records.
I'm still really curious why the normal database backups don't restore. It'd be nice to resolve that in case I need to do this again in the future... I'm still not 100% sure if everything gets restored from json, but I haven't found anything missing yet.
I feel like I must be using all these things completely wrong.

I just tried running invoke backup followed by invoke restore just to make sure the restore mechanism worked at all, and it does. Which I guess would point to the backups themselves being damaged? But I'm very skeptical of that - they are from a time when the system was working fine, and the json dump is from the same time, and it imports ok.

This is really a head-scratcher. Not sure what would corrupt the backups but I hope this does not resurface. An effective hatch against this could be regular exports as yaml - those are pretty hard to be corrupted and DBMS agnostic.

A sorry, I thought of another project. InvenTree has the export-records function putting out json, the rest of the sentence is correct.

I have been thinking of moving to the json exports for records for a while but it adds quite a bit of compute and storage overhead compared to the dumps of the current backup solution.

Well, thank you very much for helping me troubleshoot my silly mystery issue :)


if condition error

else(NOT (CMAKE_BUILD_TYPE OR CMAKE_CONFIGURATION_TYPES))

such command will reported error
for example
if(NOT (CMAKE_BUILD_TYPE OR CMAKE_CONFIGURATION_TYPES))
	set(CMAKE_BUILD_TYPE "Debug" CACHE STRING
		"Choose the type of build, options are: None Debug Release RelWithDebInfo MinSizeRel."
		FORCE)
	message("Setting build type to '${CMAKE_BUILD_TYPE}'")
else(NOT (CMAKE_BUILD_TYPE OR CMAKE_CONFIGURATION_TYPES))
	message("Build type set to '${CMAKE_BUILD_TYPE}'")
endif(NOT (CMAKE_BUILD_TYPE OR CMAKE_CONFIGURATION_TYPES))

What is the error?

What is the error?

Like this one
if(NOT (CMAKE_BUILD_TYPE OR CMAKE_CONFIGURATION_TYPES))
	set(CMAKE_BUILD_TYPE "Debug" CACHE STRING
		"Choose the type of build, options are: None Debug Release RelWithDebInfo MinSizeRel."
		FORCE)
	message("Setting build type to '${CMAKE_BUILD_TYPE}'")
else(NOT (CMAKE_BUILD_TYPE OR CMAKE_CONFIGURATION_TYPES))
	message("Build type set to '${CMAKE_BUILD_TYPE}'")
endif(NOT (CMAKE_BUILD_TYPE OR CMAKE_CONFIGURATION_TYPES))

output is
(source_file [0, 0] - [8, 0]
  (if_condition [0, 0] - [7, 57]
    (if_command [0, 0] - [0, 55]
      (if [0, 0] - [0, 2])
      (argument [0, 3] - [0, 6]
        (unquoted_argument [0, 3] - [0, 6]))
      (argument [0, 8] - [0, 24]
        (unquoted_argument [0, 8] - [0, 24]))
      (argument [0, 25] - [0, 27]
        (unquoted_argument [0, 25] - [0, 27]))
      (argument [0, 28] - [0, 53]
        (unquoted_argument [0, 28] - [0, 53])))
    (normal_command [1, 1] - [3, 8]
      (identifier [1, 1] - [1, 4])
      (argument [1, 5] - [1, 21]
        (unquoted_argument [1, 5] - [1, 21]))
      (argument [1, 22] - [1, 29]
        (quoted_argument [1, 22] - [1, 29]
          (quoted_element [1, 23] - [1, 28])))
      (argument [1, 30] - [1, 35]
        (unquoted_argument [1, 30] - [1, 35]))
      (argument [1, 36] - [1, 42]
        (unquoted_argument [1, 36] - [1, 42]))
      (argument [2, 2] - [2, 88]
        (quoted_argument [2, 2] - [2, 88]
          (quoted_element [2, 3] - [2, 87])))
      (argument [3, 2] - [3, 7]
        (unquoted_argument [3, 2] - [3, 7])))
    (normal_command [4, 1] - [4, 55]
      (identifier [4, 1] - [4, 8])
      (argument [4, 9] - [4, 54]
        (quoted_argument [4, 9] - [4, 54]
          (quoted_element [4, 10] - [4, 53]
            (variable_ref [4, 33] - [4, 52]
              (normal_var [4, 33] - [4, 52]
                (variable [4, 35] - [4, 51])))))))
    (else_command [5, 0] - [5, 56]
      (else [5, 0] - [5, 4])
      (ERROR [5, 5] - [5, 10]
        (argument [5, 5] - [5, 9]
          (unquoted_argument [5, 5] - [5, 9])))
      (argument [5, 10] - [5, 55]
        (unquoted_argument [5, 10] - [5, 55])))
    (ERROR [5, 56] - [5, 57])
    (normal_command [6, 1] - [6, 51]
      (identifier [6, 1] - [6, 8])
      (argument [6, 9] - [6, 50]
        (quoted_argument [6, 9] - [6, 50]
          (quoted_element [6, 10] - [6, 49]
            (variable_ref [6, 29] - [6, 48]
              (normal_var [6, 29] - [6, 48]
                (variable [6, 31] - [6, 47])))))))
    (endif_command [7, 0] - [7, 57]
      (endif [7, 0] - [7, 5])
      (ERROR [7, 6] - [7, 11]
        (argument [7, 6] - [7, 10]
          (unquoted_argument [7, 6] - [7, 10])))
      (argument [7, 11] - [7, 56]
        (unquoted_argument [7, 11] - [7, 56]))))
  (ERROR [7, 57] - [7, 58]))
CMakeLists.txt	0 ms	(ERROR [5, 5] - [5, 10])

Fix with 3d23db47a515852f79bbb7a1c4e61a8cc97ae5d3

Fix with 3d23db4

and you'd better change the line in Cargo.toml to your url
repository = "https://github.com/tree-sitter/tree-sitter-cmake"

done also

and update the version in Cargo.toml,to version0.0.3 I think

I'm not doing versioning for now

I'm not doing versioning for now

Right, But I will update the version to crate. with 0.0.3..

yeah, ok, i'll start doing versioning then

Thanks a lot

and I think
https://crates.io/crates/tree-sitter-cmake/0.0.3
It should be your crate, I think you should also be the owner..

I’m not using Rust often so I’m not gonna maintain it, I don’t have a use case for it myself also.


Race condition when loading or updating project files

The ProjectFile implementation as is today isn't thread safe and has a potential problematic race condition.
This isn't really an issue yet, but will likely become one if we work on API v2 or possibly if something melturbo like ever comes to fruition. This manifested for the first time (afaik) in https://github.com/meltano/meltano/pull/6297. While our Uvicorn implementation is a WIP, I think this issue pop'd up mostly as a side effect of uvicorn allowing more concurrency and exposing the underlying issue.
The easiest way to trigger this was by making concurrent call's to /api/v1/plugins/all, which then typically triggered the race and resulted in intermittent 500's and exceptions like the following being logged:
  File "/Users/syn/projects/meltano/src/meltano/core/project_files.py", line 59, in include_paths
    include_path_patterns = self.meltano.get("include_paths", [])
AttributeError: 'NoneType' object has no attribute 'get'

Indicating that self.meltano has been reset to None. The only thing that should be setting self._meltano = None is reset_cache:
https://github.com/meltano/meltano/blob/859083b8c76c1b5d88ba30dbefb1b475a08f1fc4/src/meltano/core/project_files.py#L84-L86
That in turn gets called in two spots load & update,
https://github.com/meltano/meltano/blob/859083b8c76c1b5d88ba30dbefb1b475a08f1fc4/src/meltano/core/project_files.py#L62-L67
https://github.com/meltano/meltano/blob/859083b8c76c1b5d88ba30dbefb1b475a08f1fc4/src/meltano/core/project_files.py#L69-L82
The load race is always present since the reset is unguarded  and any concurrent calls via self.project_files.load() or update() could trigger it, and high request load or system latency would make it more likely to happen.
And so, any concurrent calls to the path even when using the read lock can still kaboom.
https://github.com/meltano/meltano/blob/859083b8c76c1b5d88ba30dbefb1b475a08f1fc4/src/meltano/core/project.py#L235-L236

/cc @cjohnhanson forgot to ping you on this sorry. Just wanted to give ya heads up that I spun out a tracking issue for this race we ran into.

Still relevant


0.2.9 causes "Parse error while parsing value description: unbalanced source"

Repro: cargo install rerun-cli --locked
See https://github.com/rerun-io/rerun/issues/6865 for details
I can confirm that it worked on 0.2.8

Sorry about that.
I have yanked the version of the crate for now.

 And thanks :)


New portal UI broken, javascript error

I have a function app with some proxies. When I select the proxies in the new portal UI it throws the following javascript error. I'm using chrome
TypeError: t.value.toLowerCase is not a function
    at https://functions.azureedge.net/main.bundle.js?v=1da53bca:1453:5118
    at https://functions.azureedge.net/main.bundle.js?v=1da53bca:107:167
    at Array.map (native)
    at o (https://functions.azureedge.net/main.bundle.js?v=1da53bca:107:144)
    at e.validator (https://functions.azureedge.net/main.bundle.js?v=1da53bca:107:1343)
    at e.t._runValidator (https://functions.azureedge.net/main.bundle.js?v=1da53bca:499:4867)
    at e.t.updateValueAndValidity (https://functions.azureedge.net/main.bundle.js?v=1da53bca:499:4209)
    at e.setValue (https://functions.azureedge.net/main.bundle.js?v=1da53bca:499:7618)
    at e.patchValue (https://functions.azureedge.net/main.bundle.js?v=1da53bca:499:7729)
    at https://functions.azureedge.net/main.bundle.js?v=1da53bca:499:10064
GlobalErrorHandler.ts:12 TypeError: t.value.toLowerCase is not a function
    at https://functions.azureedge.net/main.bundle.js?v=1da53bca:1453:5118
    at https://functions.azureedge.net/main.bundle.js?v=1da53bca:107:167
    at Array.map (native)
    at o (https://functions.azureedge.net/main.bundle.js?v=1da53bca:107:144)
    at e.validator (https://functions.azureedge.net/main.bundle.js?v=1da53bca:107:1343)
    at e.t._runValidator (https://functions.azureedge.net/main.bundle.js?v=1da53bca:499:4867)
    at e.t.updateValueAndValidity (https://functions.azureedge.net/main.bundle.js?v=1da53bca:499:4209)
    at e.setValue (https://functions.azureedge.net/main.bundle.js?v=1da53bca:499:7618)
    at e.patchValue (https://functions.azureedge.net/main.bundle.js?v=1da53bca:499:7729)
    at https://functions.azureedge.net/main.bundle.js?v=1da53bca:499:10064

I might have created the proxies by hand just editing proxies.json, but regardsless of whether I should have made an error when manually editing the proxies.json file, the entire function UI shouldnt break.
my proxies.json looks like this
{
    "proxies": {
        "start": {
            "matchCondition": {
                "route": "/api/start"
            },
            "backendUri": {
                "uri": "https://s9events.azure-automation.net/webhooks?token=<removed>",
                "method": "POST"
            }
        },
        "stop": {
            "matchCondition": {
                "route": "/api/stop"
            },
            "backendUri": {
                "uri": "https://s9events.azure-automation.net/webhooks?token=<removed>",
                "method": "POST"
            }
        }
    }
}

@sjkp, it looks like you edited proxies.json manually.
it should in flowing format:
{
    "proxies": {
        "test": {
            "matchCondition": {
                "methods": [
                    "POST"
                ],
                "route": "test"
            },
            "backendUri": "https://test"
        }
    }
}

@alrod don't agree, I'm trying to convert a incoming get request to a POST request to the backend, which the provided json does and it actually works.
It is just an UI error, because the UI doesn't support the json schema I suppose, or alternatively you forgot to remove some functionality, that you don't want to build UI support for.

@sjkp Agreed, the portal UI needs to handle any valid proxies.json. Reopening.

Turns out this format does not match the latest json schema. We still need to make the UI more defensive but the best way to do that would be to validate proxies.json against the schema, captured in https://github.com/projectkudu/AzureFunctionsPortal/issues/1226


Standardize how we set defaults and clarify egressURL output

What does this PR do?
This PR changes the way we're setting the default values of certain probe parameters (e.g., per-request timeout) such that users of the osd-network-verifier CLI will get an experience that's more consistent with consumers of the API (e.g., OCM). The only concrete change to defaults is the increase of the per-request timeout from 2s to 5s.
This PR also improves probe outputs by replacing "telnet" with "tcp" (since "telnet" is just an implementation detail and might confuse customers) and improves AMI selection with support for the HCP platform type.

Checklist

[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] I have made corresponding change to the default configuration files
[ ] I have added tests that prove my fix is effective or that my feature works
[x] I have tested the functionality against gcp / aws, it doesn't cause any regression
[x] I have added execution results to the PR's readme

How to test this PR
Checkout this PR, run make test build, and then play around with ./osd-network-verifier like you normally would. To test the specific behaviors changed by this PR, try specifying the HCP lists with --platform=hostedcluster or leaving off the --probe flag.
Logs
$ ./osd-network-verifier egress --profile=default --region=$AWS_REGION --subnet-id=$SUBNET --security-group-ids=$SECURITY_GROUP
Using region: eu-west-1
Created instance with ID: i-0d8fe7f1e2384d08e
Deleting instance with ID: i-0d8fe7f1e2384d08e
Summary:
printing out failures:
 - egressURL error: tcp://inputs1.osdsecuritylogs.splunkcloud.com:9997 (Failed to connect to inputs1.osdsecuritylogs.splunkcloud.com port 9997: Connection timed out)
 - egressURL error: tcp://inputs2.osdsecuritylogs.splunkcloud.com:9997 (Failed to connect to inputs2.osdsecuritylogs.splunkcloud.com port 9997: Connection timed out)
 - egressURL error: tcp://inputs4.osdsecuritylogs.splunkcloud.com:9997 (Failed to connect to inputs4.osdsecuritylogs.splunkcloud.com port 9997: Connection timed out)
 - egressURL error: tcp://inputs5.osdsecuritylogs.splunkcloud.com:9997 (Failed to connect to inputs5.osdsecuritylogs.splunkcloud.com port 9997: Connection timed out)
 - egressURL error: tcp://inputs6.osdsecuritylogs.splunkcloud.com:9997 (Failed to connect to inputs6.osdsecuritylogs.splunkcloud.com port 9997: Connection timed out)
 - egressURL error: tcp://inputs7.osdsecuritylogs.splunkcloud.com:9997 (Failed to connect to inputs7.osdsecuritylogs.splunkcloud.com port 9997: Connection timed out)
 - egressURL error: tcp://inputs8.osdsecuritylogs.splunkcloud.com:9997 (Failed to connect to inputs8.osdsecuritylogs.splunkcloud.com port 9997: Connection timed out)
 - egressURL error: tcp://inputs9.osdsecuritylogs.splunkcloud.com:9997 (Failed to connect to inputs9.osdsecuritylogs.splunkcloud.com port 9997: Connection timed out)
 - egressURL error: tcp://inputs10.osdsecuritylogs.splunkcloud.com:9997 (Failed to connect to inputs10.osdsecuritylogs.splunkcloud.com port 9997: Connection timed out)
 - egressURL error: tcp://inputs11.osdsecuritylogs.splunkcloud.com:9997 (Failed to connect to inputs11.osdsecuritylogs.splunkcloud.com port 9997: Connection timed out)
 - egressURL error: tcp://inputs12.osdsecuritylogs.splunkcloud.com:9997 (Failed to connect to inputs12.osdsecuritylogs.splunkcloud.com port 9997: Connection timed out)
 - egressURL error: tcp://inputs13.osdsecuritylogs.splunkcloud.com:9997 (Failed to connect to inputs13.osdsecuritylogs.splunkcloud.com port 9997: Connection timed out)
 - egressURL error: tcp://inputs14.osdsecuritylogs.splunkcloud.com:9997 (Failed to connect to inputs14.osdsecuritylogs.splunkcloud.com port 9997: Connection timed out)
 - egressURL error: tcp://inputs15.osdsecuritylogs.splunkcloud.com:9997 (Failed to connect to inputs15.osdsecuritylogs.splunkcloud.com port 9997: Connection timed out)
 - egressURL error: https://registry.redhat.io:443 (Operation timed out after 5221 milliseconds with 0 out of 0 bytes received)
 - egressURL error: https://api.openshift.com:443 (Operation timed out after 5218 milliseconds with 0 out of 0 bytes received)
 - egressURL error: https://http-inputs-osdsecuritylogs.splunkcloud.com:443 (Operation timed out after 5218 milliseconds with 0 out of 0 bytes received)

printing out exceptions preventing the verifier from running the specific test:
printing out errors faced during the execution:
Failure!

Codecov Report
Attention: Patch coverage is 22.22222% with 14 lines in your changes missing coverage. Please review.

Project coverage is 32.67%. Comparing base (990f9fa) to head (f84d1e2).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #252      +/-   ##
==========================================
- Coverage   32.77%   32.67%   -0.11%
==========================================
  Files          13       13
  Lines        1144     1160      +16
==========================================
+ Hits          375      379       +4
- Misses        751      763      +12
  Partials       18       18

Files
Coverage Δ

pkg/probes/legacy/legacy.go
89.65% <100.00%> (+0.36%)
:arrow_up:

pkg/verifier/package_verifier.go
0.00% <ø> (ø)

pkg/probes/curl/curl_json.go
75.60% <50.00%> (-0.34%)
:arrow_down:

pkg/verifier/aws/entry_point.go
0.00% <0.00%> (ø)

/lgtm

/approve


Aligned UWP showcard margin with the rest of renderers

Related Issue
fixes #3165.
FYI, will merge after Paul's xaml changes go in.
NOTE: For multiple issues resolved by this PR use the corresponding keywords every time in a comma-delimited list per the reference
page above.
Description
the bottom negative margin wasn't applied if it's ShowCard and it's part of actions.
PR removed such restriction to make it consistent across platforms.
How Verified
before

after

in actions

in body with bleed

Microsoft Reviewers: Open in CodeFlow

closing this PR to avoid merging.


Rename "indianthanks" to "hindithanks"

The language used here is 'Hindi', not 'Indian'. That is not a language; there are many languages in India.
Thank you for making this small change.

hi @Dhruvsr, thanks for your contribution. Will fix this soon

Hi @Dhruvsr fixed and posted new release to Espanso Hub https://github.com/espanso/hub/pull/39 will be available for install once merged there.
If you find this package useful - consider starring this package on GitHub
Alco check out my other espanso packages

btw, @Dhruvsr, if you have any other suggestions to this package (e.g. any other language you know) - feel free to raise PR or issue.


CommandInput needs to be cleared completely to find matches after not finding them

If you go to the Command example and type "c" you'll see results, if you then type a "2" then delete it no results are listed. You need to clear the whole input before results are listed again which seems odd.

I have the same problem.
Solved by:
https://github.com/pacocoursey/cmdk/issues/40#issuecomment-1223397094

I have the same problem. Solved by: pacocoursey/cmdk#40 (comment)

How was it solved?


vsce publish's message about the 5 keywords limit is annoying

I often get the following message after running vsce publish:
The keyword list is limited to 5 keywords; only the following keywords will be in your extension: (...).

This is getting quite annoying for me.
I don't understand, why is the number of keywords even limited?

Unfortunately, the limit is set. I suggest to reduce the number of keywords in your extension. How many do you have?

7, I don't want to remove them just to work around this.
I mean this isn't really important, I could run yes | vsce publish instead of vsce publish, but couldn't vsce just be smarter and not prompt that if the resulting keywords didn't change since the previous release and the current?

You do realize that saying yes will trim the list down to 5, right?

Yes I do.
I also have that list synchronised with GitHub, which doesn't have such limitation. As I said this isn't really important, just an annoyance.

Would an environment var help in this case? VSCE_IGNORE_KEYWORD_LENGTH? Or not worth the hassle?

If there was one I would use it.

Moved to https://github.com/Microsoft/vscode-vsce/issues/296


Cow: Watch annabelquano(?:@gmail.com)?

Cow requests the watch of the watch_keyword annabelquano(?:@gmail\.com)?. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

annabelquano(?:@gmail\.com)? has been seen in 0 true positives, 0 false positives, and 0 NAAs.

Approved by Spevacus in Charcoal HQ


Add a Jekyll Theme Template to the Repository so it is visible as a website

Closed but may need some work


/docs/ should redirect to /docs/myFirstDoc ?

🚀 Feature
Supposing we use docs without any "home doc" (ie there is no doc at path /docs/).
I think it make sense to redirect /docs/ to /docs/myFirstDoc, using a client side redirect.
By "first doc", the existing heuristic is "first doc found in the first sidebar"
I guess it could also make sense to redirect /docs/unknownDoc to /docs/myFirstDoc instead of showing the 404 page? Not sure but curious to have your opinion.

That would be awesome. Also, for every subdirectory in /docs, it would be also great to redirect to a first doc there in the sidebar.
For example:
redirect /docs/cli to /docs/cli/first-doc-under-cli-subdirectory, assuming that in the /docs/cli there is first-doc-under-cli-subdirectory.md file, which is the very first link in the sidebar.

Also, for every subdirectory in /docs, it would be also great to redirect to a first doc there in the sidebar.

There is not a strict correlation between a subfolder and a subpath. 2 docs in the same subfolder might be in different sidebars, different sidebar categories, and at very different URLs (using the slug frontmatter).
There is also no way to assign a URL path segment to a sidebar category currently.
What you are probably looking for is the ability to have a category index doc, cf https://github.com/facebook/docusaurus/issues/2643
This can be seen as a way to bind a category to a given URL, but it requires to create a doc (ie, we should be able to display something at that URL but in practice you would be able to use a <Redirect> component in that doc through MDX if you really want to)

Building an API for this is not worthwhile IMO, since we can always use slug or the client-side redirect plugin with some very simple configuration or even <Redirect>. The API is going to disrupt the predictability of the docs plugin behavior and just makes the plugin take up work it shouldn't care about in the first place (client-side redirects).


Error installing the package

I am trying to install the package on Python 3.8 and I am getting this error.
pip install rejson
  ERROR: Failed building wheel for rejson Failed to build rejson ERROR: Could not build wheels for rejson which use PEP 517 and cannot be installed directl

I had the same problem with redisearch library, it seems that the library was deprecated some hours ago.
As a temporal solution I had to force the version 2.0.0 on my requirements file.
redisearch==2.0.0


[Backport] [2.x] Bump com.google.api.grpc:proto-google-common-protos from 2.25.0 to 2.25.1 in /plugins/repository-gcs (#10298)

Backport of https://github.com/opensearch-project/OpenSearch/pull/10298 to 2.x

@kotwanikunal @andrross @dblock looking for approval please, thank you


Problem on variant price when changing the currency

Type: minor
Describe the bug
May be a reaction-admin bug.
I create a product with somes variants in $ currency.
If I want to chang the currency to € in reaction-admin, I have a storefront issue in variant price
To Reproduce
Steps to reproduce the behavior:

Go to reaction-admin, create a product in $ currency
change the currency to €
try to display the product in storefront
See error "Unhandled Runtime Error
Error: Failed to load static props"

Expected behavior
Don't store currency in price ?
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: Kubuntu 20.04
Browser Chrome
Version : 83.0.4103.116 (Build officiel) (64 bits)

Additional context
Custom log in VariantItem.js render() function  :
null = priceByCurrencyCode(EUR, [{"compareAtPrice":null,"price":null,"currency":{"code":"USD"},"displayPrice":"$23.70"}])

It seem to be a cache problem.
If I update the price in admin, It will not change in the frontend GraphQL query result, like the currency.
If I add a variant in my product in admin, everything work again in frontend, price and currency are ok in the graphQL query result. So currency shop and currency variant is matching and the result of priceByCurrencyCode function is ok


[BUG] WIldcard query behavior for text fields changed in an backward-incompatible way

Describe the bug
It appears that PR #5462 changed the behavior for wildcard queries against text fields. Queries that previously worked (due to the behavior documented in https://github.com/opensearch-project/OpenSearch/issues/5461) now no longer return any results. IMO, this is backwards-incompatible change that should not have been backported to 2.x
To Reproduce
This can be repro'd using the OpenSearch docker images. First, start a node container:
docker run -d -p 9200:9200 -p 9600:9600 -e "discovery.type=single-node" opensearchproject/opensearch:2.5.0

Then, create a test index with a test field of type text and add data to this:
curl -X PUT -H 'Content-Type: application/json' 'localhost:9200/test_index?pretty' -d'
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "test_field": { "type": "text" }
    }
  }
}'

curl -X POST "localhost:9200/test_index/_doc?pretty" -H 'Content-Type: application/json' -d'
{
  "test_field": "1A2B3C"
}'

Now perform a wildcard search and observe that no hits are returned:
curl -H 'Content-Type: application/json' localhost:9200/test_index/_search --data '{
"query": {
    "wildcard": {
      "test_field": {
        "value": "1A*"
    }
  }
 }
}'

Next, repeat the same steps with the previous minor release Docker image - opensearchproject/opensearch:2.4.1 - and observe that the wildcard query returns a result
Expected behavior
Unclear. The PR seems to fix erroneous behavior but introduces a breaking change.
Plugins
N/A
Screenshots
N/A
Host/Environment (please complete the following information):

OS: [e.g. iOS] MacOS 12.6.6
Version [e.g. 22] OpenSearch 2.5.0

Additional context
A workaround for this bug is to use a query_string query instead:
curl -H 'Content-Type: application/json' localhost:9200/test_index/_search --data '{
"query": {
    "query_string": {
      "default_field": "test_field",
      "query": "1A*"
    }
  }

Finally, this bug only affects analyzed/normalized fields types. AFAIK, this means only keyword and text are affected. The PR updates KeywordFieldMapper to override this value since keyword fields are always normalized so keyword field types are not affected by this change.

@nknize can you take a look at this please? It looks related to #5462

@kartg looks broken :( if you have time, write a YAML REST test for this next

This is expected behavior. The default tokenizer first lower cases the input string at index time. So running a query_string wildcard query with an uppercase will not (and should not) yield any matches. The prior behavior was a bug and fixed in #5462. If you want exact wildcard matches, the user should use a different "analyzer" that doesn't normalize the input strings.
That patch did yield another change that also provides the behavior you seek along w/ a yaml test.

Thanks @nknize, sounds like I'm wrong on it being a regression, should we close this?

Thanks @nknize, ...should we close this?

Yes. I'm marking as a non-issue and closing.  @kartg feel free to re-open for additional discussion if you have specific downstream breaking functionality.

The prior behavior was a "false positive" bug and fixed in https://github.com/opensearch-project/OpenSearch/pull/5462. If you want exact wildcard matches, the user should use a different "analyzer" that doesn't normalize the input strings.

@nknize reopening because i'd like to discuss if such a behavior change breaks semver.
As I outlined in the repro steps above, a user query on a text field which previously returned hits no longer does so after a minor version update. Asking the user to be aware that the standard analyzer lower-cases the stored string thus their search queries must now also be in lower case (or they must now supply .caseInsensitive(true)) is a breaking, backwards-incompatible change IMO. There's also override logic for keyword field types so that such values continue to match in a case-insensitive manner, so this behavior is inconsistent between analyzed types.

So running a query_string wildcard query with an uppercase will not (and should not) yield any matches.

Note that the use-case i'm describing in this issue is for the wildcard query. The query_string logic was updated in the same PR to normalize the search query text so such a query will in fact yield matches and is the basis for the workaround i've documented.

i'd like to discuss if such a behavior change breaks semver.

It doesn't because this is a bug that was fixed. We shouldn't set a precedent of retaining bug compatibility, thats a slippery slope door we should never open.

Asking the user to be aware that the standard analyzer lower-cases the stored string thus their search queries must now also be in lower case (or they must now supply .caseInsensitive(true)) is a breaking, backwards-incompatible change IMO.

Users of Elasticsearch and OpenSearch should already be aware that what they index is not the raw string and what tokens are created by the Standard Analyzer and Standard Tokenizer. If they don't they'll have no idea how what's in their index. This isn't breaking because capital letters should never have matched in the first place - that's why case_insensitive exists at all (not to mention that parameter didn't work for the same reason the bug existed, thus it was fixed).

Note that the use-case i'm describing in this issue is for the wildcard query.

So the user should set case_insensitive to true and it should match. If that's not happening then that bug should be fixed - not opening bwc bug comparatively.

We shouldn't set a precedent of retaining bug compatibility

I whole heartedly agree, which is why my answer to the "expected behavior" section starts with "unclear" 😄

Users of Elasticsearch and OpenSearch should already be aware that what they index is not the raw string and what tokens are created by the Standard Analyzer and Standard Tokenizer. If they don't they'll have no idea what's in their index.

This assumes that the users/clients querying for data are the same (or at least in lock step) as the users/clients indexing data. I don't necessarily agree with this assumption, but that's a separate concern. In the interest of consistent behavior, why do we want wildcard queries on keyword field and query_string queries to behave differently? Shouldn't these queries also accurately reflect the contents of the index?

PS - There's an xkcd comic for this because....of course 🤣

What version was the original bug you fixed, @nknize, introduced?  I think we should document that the bug was introduced in some version, fixed in 2.5, but users may have to change their implementation if the assumption was that the bug was expected behavior.
cc: @kolchfa-aws

+1, this should go into a "breaking changes" section of docs

Created a doc issue: https://github.com/opensearch-project/documentation-website/issues/4788


Added OpenTelemetry Initialization action for Dataproc clusters

Added OpenTelemetry initialization script for installing and configuring otelcol-contrib agent for monitoring purposes. This enables users to collect and export metrics/logs/traces and supports numerous sinks.
Support for GCM exporter (enabled by default)
Support for scraping prometheus metrics from any arbitrary http endpoints passed in prometheus-scrape-endpoints metadata property
Added README for the new init script

/gcbrun

/gcbrun

/gcbrun


dom-module simple-element has style outside template on IE11

dom-module simple-element has style outside template on IE11
Example:

clone polymer shop at branch 2.0-preview-class
install  dependencies
build
http-server build/bundled-compiled

IE11 is only error.

My Project is  same.
Versions

Polymer: 2.0.0-rc.3
webcomponents: 1.0.0-rc.7
polymer 0.18.0-pre.15

Are you saying that Polymer CLI generated elements for you that have styles outside of templates, or that only Shop app has this issue?

Polymer CLI generated elements for me that have styles outside of templates.

I just try on "polymer serve" with out build.
It have same issue.

I wasn't able to repro this with the provided steps. Would you mind verifying and refining or giving alternate repro steps? Thanks.

I was able to reproduce this with polymer-2-starter-kit
Versions

polymer-cli: 0.18.0-pre.15
polymer: 2.0.0-rc.3
webcomponentsjs: 1.0.0-rc.7

Follow these steps:

install polymer-cli 0.18.0-pre.15
polymer init "polymer-2-starter-kit"
polymer serve

I am seeing this problem with polymer --version 1.5.7, the SHOP app, and IE11. After running polymer build, I cd build/es5-bundled and serve the page with Python SimpleHTTPServer.
I'm am seeing this problem with my own apps served by Node 8.9.1 and Express 4.16.2, but that is the least of my problems with IE11, where some pages lock-up repeatedly reloading. (Other problems here with polymer build that I'll report elsewhere.)


Improve error message for FS3022

Originally at CodePlex by slace
I recently hit  FS3022 when working on a  Type Provider. It was solved by  moving a let binding, but this wasn't obvious from the error message, it was pointed out via twitter.
Something to better convey that that was the problem would make it easier to resolve.

I wonder what the original code looked like.
We currently have no test for FS3022 and I'd like to add one.

Search for "InvalidInvokerExpression", which reveals a test very similar to this case which can used as a basis
C:\GitHub\dsyme\visualfsharp\tests\fsharp\typeProviders\negTests\provider.fsx
        |   _, [||] when mb.Name = "get_InvalidInvokerExpression" ->
                Quotations.Expr.WhileLoop(Quotations.Expr.Value(true), Quotations.Expr.Value((), typeof<unit>))

I suggest the error message change to something like "Unsupported constant type '%s'. Quotations provided by type providers can only contain simple constants. You may need to move a value declared outside a provided quotation literal to be a 'let' binding inside the qutoation literal."


BadgeContent Image_Url_4x always returns empty

Within the class BadgeContent, the property "Image_Url_4x" always returns empty.
Changing [JsonProperty(PropertyName = "image_url_3x")] to [JsonProperty(PropertyName = "image_url_4x")]  fixed this issue for me.

Should be resolved now, thanks!


UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 2929: character maps to

code currently mostly only works on Linux. If you want to execute it on windows you would need to use wsl2. I also don't know why a decoder has been called. I'm currently in school but when I get home I'll look into it. Also as a friendly reminder: if you want it easier, a pretrained model of the commonvoice dataset is available for download for enhancing. You would only need to use Mimic recording studio and also add that model for training. It would be training way faster. As it is p
retrained it is unnecessary to do it again for the same dataser


[FIXED] The first DocumentTab to be opened appears as a small square in upper left before expanding to fill the MDICLIENT

BTW -- I have a fix for this issue already in hand -- so I am merely posting this to (a) document the bug, and (b) point out which code needs to be fixed.
So, I have a Visual Studio-like application and it starts out with a DockWindow docked to the left (i.e., DockState==DockLeft).  When I open the first DockingMdi MDI Document tab, the tab appears first as a small square of gray covering the dock window and then it expands to fill the space left over to the right.
This is done even when the Form.Load of the enclosed DockContent does not process a lengthy operation.  It causes a noticeable flicker.  This only happens the first time a Document is opened; all other documents from then on appear automatically to be the correct size.
Here is what I mean: I open up my app and then create a File -> New document.  First, we see the following:

Then, a few seconds later, the form fills the proper amount of the screen real estate:

The desired behavior is for the document tab not to appear until it's the correct size.  I know the solution.  In the original codebase, the DockWindow class overrides the OnLayout method:
// original code
protected override void OnLayout(LayoutEventArgs levent)
{
VisibleNestedPanes.Refresh();
if (VisibleNestedPanes.Count == 0)
{
if (Visible)
Visible = false;
}
else if (!Visible)
{
Visible = true;
VisibleNestedPanes.Refresh();
}
base.OnLayout(levent);

}
I am aware that this is probably not the root cause of the issue, but doing the following code change appears to fix the issue (i.e., the application's first document tab is not displayed until the content window has already had its bounds refreshed to fill the space to the right of the dock-left DockWindow):
// fixed code
protected override void OnLayout(LayoutEventArgs levent)
{
VisibleNestedPanes.Refresh();
if (VisibleNestedPanes.Count == 0)
{
if (Visible)
Visible = false;
}
else if (!Visible)
{
VisibleNestedPanes.Refresh();
Visible = this.DockState != DockState.Document;
}
base.OnLayout(levent);

if (this.DockState != DockState.Document
    || !"Bounds".Equals(levent.AffectedProperty))
{
    return;
}

Visible = true;

}
Basically, the idea is, go ahead and set Visible = true when necessary for anything but a DockState.Document.  Then, call the base class' OnLayout method (which is the ScrollableControl version) and then, test for whether the DockState == Document AND "Bounds" is the value of levent.AffectedProperty.  If so, then it's time to set Visible = true; otherwise, we are done with the method.
Like I said, I realize I may have not fixed the actual root cause of this issue, but I believe it to be well-patched.

As the fix has been documented along with the issue, I have closed it; however, I strongly recommend that this update be put into the master branch.

Please feel free to submit a pull request with the fix for inclusion into master.

With the new mechanism of #369 we can even ship your patch to all users (with a switch to disable it if anything does not work out). So any patch is now welcome.
You can now send a normal PR where I can help put it under patch controller afterwards, or you can check out commits such as 20be7515575d0a1940dd3c0bd1380c2849662665 to integrate with patch controller on your own.


How about adding some control to HttpServletRequestExtractAdapter?

Here's the story: HttpServletRequestExtractAdapter extracts all the header values into a map. Just wondering, what would be the best way for it to skip some specific headers. For instance, I don't want to extract Authorization header (otherwise it's propagated to outgoing requests by some implementations of Tracer).
Does it make sense to add some control to HttpServletRequestExtractAdapter? Like, passing a filter function to the constructor.

It is pity that you cannot register filter which would remove these headers before tracing kicks in.
What you could do is to write a custom Extractor which would filter out these values and then delegate to the actual implementation (it has to be supported by tracer implementation).

This is about the incoming SpanContext correct?
The OT API is only:
io.opentracing.SpanContext.baggageItems()
so the problem here is that because the Filter/Extractor does not know what the vendor uses to transport them, its just providing all headers as baggage items.
This is questionable, but without having access to implementation details its not possible to do otherwise.
And currently because it happens automagically users have no way to blacklist / customize the headers.
This is what @elgris is asking for: some way to interact with the filter to limit what baggage items reach the tracer.


[onednn[core]:x64-linux] build failure

Host Environment

OS: [Ubuntu <IP_ADDRESS>]
Compiler: gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

To Reproduce
Steps to reproduce the behavior:
./vcpkg install onednn[core]:x64-linux [install-x64-linux-dbg-out.log](https://github.com/microsoft/vcpkg/files/6894758/install-x64-linux-dbg-out.log)
Failure logs
The following packages will be built and installed:
    onednn[core]:x64-linux -> 2.0#1
Detecting compiler hash for triplet x64-linux...
Could not locate cached archive: /root/.cache/vcpkg/archives/13/13a8bf92468e78b15ce50b4b18ebec156a3bc3c042d193889ba596f600507a30.zip
Starting package 1/1: onednn:x64-linux
Building package onednn[core]:x64-linux...
-- Using /home/rin/Documents/Workspace/vcpkg/downloads/oneapi-src-oneDNN-v2.0.tar.gz
-- Cleaning sources at /home/rin/Documents/Workspace/vcpkg/buildtrees/onednn/src/v2.0-80e0c80e79.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source /home/rin/Documents/Workspace/vcpkg/downloads/oneapi-src-oneDNN-v2.0.tar.gz
-- Using source at /home/rin/Documents/Workspace/vcpkg/buildtrees/onednn/src/v2.0-80e0c80e79.clean
-- Configuring x64-linux-dbg
-- Configuring x64-linux-rel
-- Building x64-linux-dbg
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:155 (message):
    Command failed: /home/rin/Documents/Workspace/vcpkg/downloads/tools/cmake-3.20.2-linux/cmake-3.20.2-linux-x86_64/bin/cmake --build . --config Debug --target install -- -v -j25
    Working Directory: /home/rin/Documents/Workspace/vcpkg/buildtrees/onednn/x64-linux-dbg
    See logs for more information:
      /home/rin/Documents/Workspace/vcpkg/buildtrees/onednn/install-x64-linux-dbg-out.log

Call Stack (most recent call first):
  scripts/cmake/vcpkg_build_cmake.cmake:104 (vcpkg_execute_build_process)
  scripts/cmake/vcpkg_install_cmake.cmake:44 (vcpkg_build_cmake)
  ports/onednn/portfile.cmake:20 (vcpkg_install_cmake)
  scripts/ports.cmake:141 (include)

Error: Building package onednn:x64-linux failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `./vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: onednn:x64-linux
  Vcpkg version: 2021-07-26-unknownhash

/home/rin/Documents/Workspace/vcpkg/buildtrees/onednn/install-x64-linux-dbg-out.log

Please provide the logs :)

Sorry, I thought I did.
install-x64-linux-dbg-out.log

from the log: collect2: fatal error: ld terminated with signal 9 [Killed], after a few seconds of googling it seems that your system ran out of memory

Oh.. that makes sense.. My system does freeze midway during the build and eventually when it recovers, I see this error.
But then I have a 32 GB RAM..
Is there something I can do to prevent this?

Hm, maybe restart your pc so that the initial memory usage is low. How many cores do you have?

Thanks for binging my attention to the relavent error. I didn't think this line meant anything. I will google and try other solutions like increasing Swap disk or running "cargo run --release --verbose --jobs 1" whatever that does ;)
I have tried restarting and having this as the only frontend process running.
I have 12 cores - an AMD Ryzen 9 3900X.

12 core, 25 jobs, this isn't much average RAM per job. You may try to limit the job count via VCPKG_MAX_CONCURRENCY.

12 core, 25 jobs, this isn't much average RAM per job. You may try to limit the job count via VCPKG_MAX_CONCURRENCY.

12 core, 25 jobs, this isn't much average RAM per job. You may try to limit the job count via VCPKG_MAX_CONCURRENCY.

Thank you for you suggestion @dg0yt. I tried setting this to 8 in the vcpkg.cmake file with the following statement.
set(VCPKG_MAX_CONCURRENCY 8)
It didn't help. The system froze again for a long time before I force rebooted. Am I setting this correctly? Is there anything else I can try?

See https://github.com/microsoft/vcpkg/blob/bec883fef498206f05b20bc0a4ba241637657dba/docs/users/config-environment.md#vcpkg_max_concurrency.

We hope your question was answered to your satisfaction; if it wasn't, you can reopen with more info.

Yes, Thank you. Although I don't recall now what I did to get the build, I'm sure it was your observation that RAM would be split between different threads and limiting concurrency were key in solving it. Thank you! :-)

Last not least, VCPKG_MAX_CONCURRENCY is an environment variable.


[BUG] Neptune_ML widget error in 2.0.9

Describe the bug
Starting in version 2.0.9 the neptune_ml widget is having an issue where the json values being passed in are getting the following error
{'error': JSONDecodeError('Expecting value: line 1 column 1 (char 0)',)}

To Reproduce
Steps to reproduce the behavior:

Run through the 01-Introduction-to-Node-Classification-Gremlin notebook
When you get to the export step the error occurs

Additional context
This is not a problem in version 2.0.7

This appears to be an issue with the versions of ipython that SageMaker is using.  If you update the Lifecycle start script by putting the following code at the bottom (just before EOF) and stopping and starting the notebook.
source activate JupyterSystemEnv
pip install --upgrade ipython==7.16.1
source /home/ec2-user/anaconda3/bin/deactivate

Hi, i have updated the Lifecycle scripts as suggested:
#!/bin/bash
sudo -u ec2-user -i <<'EOF'
echo "export GRAPH_NOTEBOOK_AUTH_MODE=DEFAULT" >> ~/.bashrc
echo "export GRAPH_NOTEBOOK_IAM_PROVIDER=ROLE" >> ~/.bashrc
echo "export GRAPH_NOTEBOOK_SSL=True" >> ~/.bashrc
echo "export GRAPH_NOTEBOOK_HOST=neptunedbcluster-lolvzvcvwqgd.cluster-cqqsvgvoyzlx.us-east-1.neptune.amazonaws.com" >> ~/.bashrc
echo "export GRAPH_NOTEBOOK_PORT=8182" >> ~/.bashrc
echo "export NEPTUNE_LOAD_FROM_S3_ROLE_ARN=arn:aws:iam::504028651370:role/neptuneml-NeptuneBaseStack-Y-NeptuneLoadFromS3Role-1UBUI982ZI077" >> ~/.bashrc
echo "export AWS_REGION=us-east-1" >> ~/.bashrc
echo "export NEPTUNE_ML_ROLE_ARN=arn:aws:iam::504028651370:role/neptuneml-NeptunMLCoreStack-2OGKH-NeptuneMLIAMRole-U8Y193MBESPX" >> ~/.bashrc
echo "export NEPTUNE_EXPORT_API_URI=https://wvxk88hzea.execute-api.us-east-1.amazonaws.com/v1/neptune-export" >> ~/.bashrc
aws s3 cp s3://aws-neptune-notebook/graph_notebook.tar.gz /tmp/graph_notebook.tar.gz
rm -rf /tmp/graph_notebook
tar -zxvf /tmp/graph_notebook.tar.gz -C /tmp
/tmp/graph_notebook/install.sh
aws s3 cp --recursive s3://aws-neptune-customer-samples/v2/notebooks/ ~/SageMaker/Neptune
chmod -R a+rw ~/SageMaker/Neptune/*
source activate JupyterSystemEnv
pip install --upgrade ipython==7.16.1
source /home/ec2-user/anaconda3/bin/deactivate
EOF
but still getting the same error:
{'error': JSONDecodeError('Expecting value: line 1 column 1 (char 0)',)}
can you help or suggest other workaround?
thanks

Hi @Kristof-Neys, can you give a screenshot of the error so we can confirm/reproduce?

Hi @Kristof-Neys, can you give a screenshot of the error so we can confirm/reproduce?

Hi @Kristof-Neys, can you give a screenshot of the error so we can confirm/reproduce?

Hi @Kristof-Neys, can you give a screenshot of the error so we can confirm/reproduce?

hi @austinkline  - thanks for helping me out. So as you can see from the screenshots, it fails to download the data and seems to be adding a backslash...
AWS and certainly Neptune is all new to me, so any help & workaround you can give me is very much appreciated!

Thanks for the info, glad you have a workaround while we reproduce. I'll spend some time reproducing and get back to you

I was not able to reproduce this issue after running a fresh notebook created via cloud-formation found in our public docs

@Kristof-Neys I wonder if the state of the notebook got mixed up somehow? I would suggest creating a fresh notebook instance and trying again. The bug which needed the workaround lifecycle configuration has been resolved and released to pypi so that is not needed anymore

I was not able to reproduce this issue after running a fresh notebook created via cloud-formation found in our public docs

@Kristof-Neys I wonder if the state of the notebook got mixed up somehow? I would suggest creating a fresh notebook instance and trying again. The bug which needed the workaround lifecycle configuration has been resolved and released to pypi so that is not needed anymore

thank you @austinkline . I'll re-run everything from fresh... - meanwhile, how can I figure out which GNN model is actually used and the model specifics in DGL?

thank you @austinkline . I'll re-run everything from fresh... - meanwhile, how can I figure out which GNN model is actually used and the model specifics in DGL?

Checked with the team about this, you should be able to find this information in cloudwatch logs for that particular job in the Sagemaker console.

thank you @austinkline . I'll re-run everything from fresh... - meanwhile, how can I figure out which GNN model is actually used and the model specifics in DGL?

Checked with the team about this, you should be able to find this information in cloudwatch logs for that particular job in the Sagemaker console.

yeah thanks - just found it in the S3, says rgcn which presumably stands for the relational graph convolutional network

thank you @austinkline . I'll re-run everything from fresh... - meanwhile, how can I figure out which GNN model is actually used and the model specifics in DGL?

Checked with the team about this, you should be able to find this information in cloudwatch logs for that particular job in the Sagemaker console.

yeah thanks - just found it in the S3, says rgcn which presumably stands for the relational graph convolutional network

yes. that's correct.

Hi @Kristof-Neys and updates? Did recreating work for you?

Hi @austinkline - thanks for reaching out. I have been caught up in another project but was just about to look at it. I'll update you guys probably tomorrow.

hi @austinkline & Team, i am finally getting around to this. I started everything new but now I cannot export the configuration any more, I get the following error:
{'error': ConnectionError(MaxRetryError("HTTPSConnectionPool(host='none', port=443): Max retries exceeded with url: /neptune-export (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f28f5e81748>: Failed to establish a new connection: [Errno -2] Name or service not known',))",),)}
any ideas? Thanks!!

Let's start by gathering what version you're running again and what your configuration looks like. What we want to figure out is whether the exporter or Neptune is throwing the exception provided. That is to say, was the exporter unable to be called due to a missing auth token, or did the exporter start and then it was unable to communicate with Neptune. You also could take a look at cloudwatch logs for your api gateway on the corresponding exporter resource and see if it has any additional info you can point to. I'll go ahead and provision a fresh stack and see if I get the same issue once we've confirmed your auth setting.
Can you provide your notebook version and configuration by running the following:

What cell did you execute that gave you the above mentioned error?

What version of graph-notebook are you running?

%graph_notebook_version

What is your configuration? Really we just care about the authentication setting
NOTE: PLEASE ERASE OR BLOCK OUT YOUR HOST ENDPOINT FROM YOUR CONFIGURATION WHEN PROVIDING THIS INFO

%graph_notebook_config

Let's start by gathering what version you're running again and what your configuration looks like. What we want to figure out is whether the exporter or Neptune is throwing the exception provided. That is to say, was the exporter unable to be called due to a missing auth token, or did the exporter start and then it was unable to communicate with Neptune. You also could take a look at cloudwatch logs for your api gateway on the corresponding exporter resource and see if it has any additional info you can point to. I'll go ahead and provision a fresh stack and see if I get the same issue once we've confirmed your auth setting.
Can you provide your notebook version and configuration by running the following:
1. What cell did you execute that gave you the above mentioned error?

2. What version of `graph-notebook` are you running?

%graph_notebook_version

1. What is your configuration?  Very much appreciate taking time & effort. Ok, so these are the detail:
cell that I am running:
%%neptune_ml export start --export-url {neptune_ml.get_export_service_host()} --export-iam --wait --store-to export_results ${export_params}
=> this gives me error:
{   "message": "Missing Authentication Token" }
Version graph-notebook: 2.1.0
%graph_notebook_config:
{   "host": "neptunedbcluster-xxxxxx.....xxxxxx.us-east-1.neptune.amazonaws.com",   "port": 8182,   "auth_mode": "DEFAULT",   "load_from_s3_arn": "arn:aws:iam::504028651370:role/neptuneml-NeptuneBaseStack-Y-NeptuneLoadFromS3Role-1UBUI982ZI077",   "ssl": true,   "aws_region": "us-east-1",   "sparql": {     "path": "sparql"   } }
The strange thing is that all worked well two weeks ago, altho I did get wrong predictions, but at least the export worked and I could train model and get predictions etc. Now I cannot get beyond the export....
thank you again

@Kristof-Neys I believe I found the bug we're dealing with. Can you flip IAM auth on in your config and see if the exporter/other components work?
%%graph_notebook_config
{
  "host": "neptunedbcluster-xxxxxx.....xxxxxx.us-east-1.neptune.amazonaws.com",
  "port": 8182,
  "auth_mode": "IAM",
  "load_from_s3_arn": "arn:aws:iam::504028651370:role/neptuneml-NeptuneBaseStack-Y-NeptuneLoadFromS3Role-1UBUI982ZI077",
  "ssl": true,
  "aws_region": "us-east-1",
  "sparql": {
    "path": "sparql"
  }
}

Note that we're changing the auth mode to IAM

@Kristof-Neys I believe I found the bug we're dealing with. Can you flip IAM auth on in your config and see if the exporter/other components work?
%%graph_notebook_config
{
  "host": "neptunedbcluster-xxxxxx.....xxxxxx.us-east-1.neptune.amazonaws.com",
  "port": 8182,
  "auth_mode": "IAM",
  "load_from_s3_arn": "arn:aws:iam::504028651370:role/neptuneml-NeptuneBaseStack-Y-NeptuneLoadFromS3Role-1UBUI982ZI077",
  "ssl": true,
  "aws_region": "us-east-1",
  "sparql": {
    "path": "sparql"
  }
}

Note that we're changing the auth mode to IAM
hey @austinkline  - that worked!, export and training went fine....but still predicting the wrong genre.... - how can this be??

@Kristof-Neys The issue you are seeing is actually one where the text in the notebook is incorrect.  Drama is what is coming back from the model that is generated .  I have created an issue to track this https://github.com/aws/graph-notebook/issues/116 and will address this with the additional feedback on those notebooks in the near future.

@Kristof-Neys The issue you are seeing is actually one where the text in the notebook is incorrect. Drama is what is coming back from the model that is generated . I have created an issue to track this #116 and will address this with the additional feedback on those notebooks in the near future.

ok understood - thank you

Closing this out since we're tracking the reported issue of notebooks being out of date in #116. Please cut us a new ticket if you run into any further issues!

Hi guys, I'm facing a similar issue, I applied your fix(setting "auth_mode": "IAM") but did not work, any suggestions?

Hi @llealgt , is this referring to the same issue mentioned at https://github.com/aws/graph-notebook/issues/445#issuecomment-1426192856?

Hi @michaelnchin, nope, it's not the same, this happens when running notebook
Neptune-ML-01-Introduction-to-Node-Classification-Gremlin
The other errors happen in notebook
Neptune-ML-00-Getting-Started-with-Neptune-ML-Gremlin
I guess it is related but they are different errors in different notebooks.


Fix links in README

I just noticed that there are links in the README that need to be fixed after the package renaming.

Fixed, also updated the example of creating an email, since it was incorrect.

Thanks, @suncelesta—I meant this as a reminder for myself for later, but sooner is better!


Update multi-active-availability.md

This change is

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/045fe1972e49973294266df20b4cf9f5f5f9bbf9/
Edited pages:

v20.1/multi-active-availability.md


KAFKA-12840; Removing compact cleaning on a topic should abort on-going compactions

When compact is removed from the cleanup.policy of a topic, the compactions of that topic should be aborted.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@lbradstreet I have updated the PR based on your feedback.

@dajac the updated changes look good to me overall. It seems like we're hitting some gradle executor errors across multiple runs, so it may not be a coincidence.

Let me check those.

@lbradstreet The last run looks good. It seems that the previous one failed for some other reasons.