Upgrading to v0.5.0 breaks writing some metrics

I've had issues where only a subset of metrics were emitted:
# HELP promitor_runtime_http_request_duration_seconds duration histogram of http responses labeled with: status_code, method, path
# TYPE promitor_runtime_http_request_duration_seconds histogram
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.005"} 2
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.01"} 2
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.025"} 2
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.05"} 3
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.075"} 3
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.1"} 3
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.25"} 5
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.5"} 5
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.75"} 6
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="1"} 6
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="2.5"} 6
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="5"} 6
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="7.5"} 6
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="10"} 6
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="+Inf"} 6
promitor_runtime_http_request_duration_seconds_sum{status_code="200",method="GET",path="/scrape"} 0.9737883
promitor_runtime_http_request_duration_seconds_count{status_code="200",method="GET",path="/scrape"} 6
# HELP promitor_scrape_error Provides an indication that the scraping of the resource has failed
# TYPE promitor_scrape_error gauge
promitor_scrape_error{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="AutomationAccount",resource_name="promitor-sandbox",resource_group="promitor-sources",metric_name="promitor_demo_automation_update_deployment_runs"} 0<PHONE_NUMBER>479
promitor_scrape_error{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="MonitorAutoscale",resource_name="app-service-autoscaling-rules",resource_group="demo",metric_name="promitor_demo_appplan_autoscale_observed_capacity"} 0<PHONE_NUMBER>492
promitor_scrape_error{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="FrontDoor",resource_name="promitor-landscape",resource_group="promitor-landscape",metric_name="promitor_demo_frontdoor_backend_health_per_backend"} 1<PHONE_NUMBER>335
promitor_scrape_error{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="Generic",resource_name="Microsoft.Insights/Components/docker-hub-metrics",resource_group="docker-hub-metrics",metric_name="promitor_demo_app_insights_dependency_duration_200_OK"} 1<PHONE_NUMBER>515
promitor_scrape_error{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="Generic",resource_name="Microsoft.Insights/Components/docker-hub-metrics",resource_group="docker-hub-metrics",metric_name="promitor_demo_app_insights_dependency_duration"} 1<PHONE_NUMBER>465
promitor_scrape_error{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="AppPlan",resource_name="promitor-app-plan",resource_group="promitor-sources",metric_name="promitor_demo_appplan_percentage_cpu"} 1<PHONE_NUMBER>465
promitor_scrape_error{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="AutomationAccount",resource_name="promitor-sandbox",resource_group="promitor-sources",metric_name="promitor_demo_automation_update_deployment_machine_runs"} 0<PHONE_NUMBER>410
promitor_scrape_error{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="AutomationAccount",resource_name="promitor-sandbox",resource_group="promitor-sources",metric_name="promitor_demo_automation_job_count"} 0<PHONE_NUMBER>513
# HELP promitor_scrape_success Provides an indication that the scraping of the resource was successful
# TYPE promitor_scrape_success gauge
promitor_scrape_success{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="AutomationAccount",resource_name="promitor-sandbox",resource_group="promitor-sources",metric_name="promitor_demo_automation_update_deployment_runs"} 1<PHONE_NUMBER>976
promitor_scrape_success{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="MonitorAutoscale",resource_name="app-service-autoscaling-rules",resource_group="demo",metric_name="promitor_demo_appplan_autoscale_observed_capacity"} 1<PHONE_NUMBER>296
promitor_scrape_success{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="FrontDoor",resource_name="promitor-landscape",resource_group="promitor-landscape",metric_name="promitor_demo_frontdoor_backend_health_per_backend"} 0<PHONE_NUMBER>969
promitor_scrape_success{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="Generic",resource_name="Microsoft.Insights/Components/docker-hub-metrics",resource_group="docker-hub-metrics",metric_name="promitor_demo_app_insights_dependency_duration_200_OK"} 0<PHONE_NUMBER>347
promitor_scrape_success{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="Generic",resource_name="Microsoft.Insights/Components/docker-hub-metrics",resource_group="docker-hub-metrics",metric_name="promitor_demo_app_insights_dependency_duration"} 0<PHONE_NUMBER>968
promitor_scrape_success{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="AppPlan",resource_name="promitor-app-plan",resource_group="promitor-sources",metric_name="promitor_demo_appplan_percentage_cpu"} 0<PHONE_NUMBER>968
promitor_scrape_success{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="AutomationAccount",resource_name="promitor-sandbox",resource_group="promitor-sources",metric_name="promitor_demo_automation_update_deployment_machine_runs"} 1<PHONE_NUMBER>869
promitor_scrape_success{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="AutomationAccount",resource_name="promitor-sandbox",resource_group="promitor-sources",metric_name="promitor_demo_automation_job_count"} 1<PHONE_NUMBER>162

So I reverted back to v0.4.0 which gave me the full metrics again:
# HELP azure_logic_apps_failed_run Total amount of failed runs for Azure Logic Apps
# TYPE azure_logic_apps_failed_run gauge
azure_logic_apps_failed_run{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor/providers/Microsoft.Logic/workflows/promitor-automation-github-ci-scraper",resource_group="promitor",instance_name="promitor-automation-github-ci-scraper",geo="china",environment="dev"} 0<PHONE_NUMBER>265
# HELP promitor_demo_appplan_autoscale_observed_capacity Average amount of current instances for an Azure App Plan with Azure Monitor Autoscale
# TYPE promitor_demo_appplan_autoscale_observed_capacity gauge
promitor_demo_appplan_autoscale_observed_capacity{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/demo/providers/Microsoft.Insights/autoscalesettings/app-service-autoscaling-rules",resource_group="demo",metrictriggerrule="unknown",instance_name="app-service-autoscaling-rules",geo="china",environment="dev",app="promitor"} -1<PHONE_NUMBER>052
# HELP promitor_demo_automation_job_count Amount of jobs per Azure Automation account
# TYPE promitor_demo_automation_job_count gauge
promitor_demo_automation_job_count{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor-sources/providers/Microsoft.Automation/automationAccounts/promitor-sandbox",resource_group="promitor-sources",instance_name="promitor-sandbox",geo="china",environment="dev"} -1<PHONE_NUMBER>266
# HELP promitor_demo_automation_update_deployment_machine_runs Amount of jobs per Azure Automation account
# TYPE promitor_demo_automation_update_deployment_machine_runs gauge
promitor_demo_automation_update_deployment_machine_runs{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor-sources/providers/Microsoft.Automation/automationAccounts/promitor-sandbox",resource_group="promitor-sources",instance_name="promitor-sandbox",geo="china",environment="dev"} -1<PHONE_NUMBER>265
# HELP promitor_demo_automation_update_deployment_runs Amount of jobs per Azure Automation account
# TYPE promitor_demo_automation_update_deployment_runs gauge
promitor_demo_automation_update_deployment_runs{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor-sources/providers/Microsoft.Automation/automationAccounts/promitor-sandbox",resource_group="promitor-sources",instance_name="promitor-sandbox",geo="china",environment="dev"} -1<PHONE_NUMBER>264
# HELP promitor_demo_servicebus_messagecount_discovered Average percentage of memory usage on an Azure App Plan
# TYPE promitor_demo_servicebus_messagecount_discovered gauge
promitor_demo_servicebus_messagecount_discovered{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor/providers/Microsoft.ServiceBus/namespaces/promitor-messaging",resource_group="promitor",instance_name="promitor-messaging",geo="europe",environment="dev",entity_name="queue-07",app="promitor"} 0<PHONE_NUMBER>176
promitor_demo_servicebus_messagecount_discovered{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor/providers/Microsoft.ServiceBus/namespaces/promitor-messaging",resource_group="promitor",instance_name="promitor-messaging",geo="europe",environment="dev",entity_name="queue-15",app="promitor"} 0<PHONE_NUMBER>144
promitor_demo_servicebus_messagecount_discovered{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor/providers/Microsoft.ServiceBus/namespaces/promitor-messaging",resource_group="promitor",instance_name="promitor-messaging",geo="europe",environment="dev",entity_name="queue-03",app="promitor"} 2<PHONE_NUMBER>677
promitor_demo_servicebus_messagecount_discovered{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor/providers/Microsoft.ServiceBus/namespaces/promitor-messaging",resource_group="promitor",instance_name="promitor-messaging",geo="europe",environment="dev",entity_name="queue-12",app="promitor"} 0<PHONE_NUMBER>803
promitor_demo_servicebus_messagecount_discovered{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor/providers/Microsoft.ServiceBus/namespaces/promitor-messaging",resource_group="promitor",instance_name="promitor-messaging",geo="europe",environment="dev",entity_name="queue-05",app="promitor"} 0<PHONE_NUMBER>325
promitor_demo_servicebus_messagecount_discovered{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor/providers/Microsoft.ServiceBus/namespaces/promitor-messaging",resource_group="promitor",instance_name="promitor-messaging",geo="europe",environment="dev",entity_name="shipment-requests",app="promitor"} 1<PHONE_NUMBER>834
promitor_demo_servicebus_messagecount_discovered{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor/providers/Microsoft.ServiceBus/namespaces/promitor-messaging",resource_group="promitor",instance_name="promitor-messaging",geo="europe",environment="dev",entity_name="queue-01",app="promitor"} 0<PHONE_NUMBER>944
promitor_demo_servicebus_messagecount_discovered{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor/providers/Microsoft.ServiceBus/namespaces/promitor-messaging",resource_group="promitor",instance_name="promitor-messaging",geo="europe",environment="dev",entity_name="queue-13",app="promitor"} 0<PHONE_NUMBER>646
promitor_demo_servicebus_messagecount_discovered{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor/providers/Microsoft.ServiceBus/namespaces/promitor-messaging",resource_group="promitor",instance_name="promitor-messaging",geo="europe",environment="dev",entity_name="queue-11",app="promitor"} 0<PHONE_NUMBER>004
promitor_demo_servicebus_messagecount_discovered{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor/providers/Microsoft.ServiceBus/namespaces/promitor-messaging",resource_group="promitor",instance_name="promitor-messaging",geo="europe",environment="dev",entity_name="queue-08",app="promitor"} 0<PHONE_NUMBER>478
# HELP promitor_demo_servicebus_messagecount_limited Average percentage of memory usage on an Azure App Plan
# TYPE promitor_demo_servicebus_messagecount_limited gauge
promitor_demo_servicebus_messagecount_limited{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor/providers/Microsoft.ServiceBus/namespaces/promitor-messaging",resource_group="promitor",instance_name="promitor-messaging",geo="europe",environment="dev",entity_name="queue-07",app="promitor"} 0<PHONE_NUMBER>025
promitor_demo_servicebus_messagecount_limited{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor/providers/Microsoft.ServiceBus/namespaces/promitor-messaging",resource_group="promitor",instance_name="promitor-messaging",geo="europe",environment="dev",entity_name="queue-03",app="promitor"} 2<PHONE_NUMBER>102
promitor_demo_servicebus_messagecount_limited{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor/providers/Microsoft.ServiceBus/namespaces/promitor-messaging",resource_group="promitor",instance_name="promitor-messaging",geo="europe",environment="dev",entity_name="queue-05",app="promitor"} 0<PHONE_NUMBER>780
promitor_demo_servicebus_messagecount_limited{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor/providers/Microsoft.ServiceBus/namespaces/promitor-messaging",resource_group="promitor",instance_name="promitor-messaging",geo="europe",environment="dev",entity_name="queue-12",app="promitor"} 0<PHONE_NUMBER>568
promitor_demo_servicebus_messagecount_limited{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor/providers/Microsoft.ServiceBus/namespaces/promitor-messaging",resource_group="promitor",instance_name="promitor-messaging",geo="europe",environment="dev",entity_name="shipment-requests",app="promitor"} 1<PHONE_NUMBER>329
# HELP promitor_ratelimit_arm Indication how many calls are still available before Azure Resource Manager is going to throttle us.
# TYPE promitor_ratelimit_arm gauge
promitor_ratelimit_arm{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",app_id="ceb249a3-44ce-4c90-8863-6776336f5b7e"} 11991<PHONE_NUMBER>416
# HELP promitor_runtime_http_request_duration_seconds duration histogram of http responses labeled with: status_code, method, path
# TYPE promitor_runtime_http_request_duration_seconds histogram
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.005"} 8
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.01"} 8
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.025"} 9
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.05"} 9
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.075"} 11
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.1"} 11
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.25"} 11
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.5"} 11
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="0.75"} 11
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="1"} 11
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="2.5"} 11
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="5"} 11
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="7.5"} 11
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="10"} 11
promitor_runtime_http_request_duration_seconds_bucket{status_code="200",method="GET",path="/scrape",le="+Inf"} 11
promitor_runtime_http_request_duration_seconds_sum{status_code="200",method="GET",path="/scrape"} 0.1317863
promitor_runtime_http_request_duration_seconds_count{status_code="200",method="GET",path="/scrape"} 11
# HELP promitor_scrape_error Provides an indication that the scraping of the resource has failed
# TYPE promitor_scrape_error gauge
promitor_scrape_error{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="AutomationAccount",resource_name="promitor-sandbox",resource_group="promitor-sources",metric_name="promitor_demo_automation_job_count"} 0<PHONE_NUMBER>354
promitor_scrape_error{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="AutomationAccount",resource_name="promitor-sandbox",resource_group="promitor-sources",metric_name="promitor_demo_automation_update_deployment_machine_runs"} 0<PHONE_NUMBER>333
promitor_scrape_error{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="FrontDoor",resource_name="promitor-landscape",resource_group="promitor-landscape",metric_name="promitor_demo_frontdoor_backend_health_per_backend"} 1<PHONE_NUMBER>471
promitor_scrape_error{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="Generic",resource_name="Microsoft.Insights/Components/docker-hub-metrics",resource_group="docker-hub-metrics",metric_name="promitor_demo_app_insights_dependency_duration_200_OK"} 1<PHONE_NUMBER>861
promitor_scrape_error{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="AppPlan",resource_name="promitor-app-plan",resource_group="promitor-sources",metric_name="promitor_demo_appplan_percentage_cpu"} 1<PHONE_NUMBER>860
promitor_scrape_error{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="AutomationAccount",resource_name="promitor-sandbox",resource_group="promitor-sources",metric_name="promitor_demo_automation_update_deployment_runs"} 0<PHONE_NUMBER>304
promitor_scrape_error{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="Generic",resource_name="Microsoft.Insights/Components/docker-hub-metrics",resource_group="docker-hub-metrics",metric_name="promitor_demo_app_insights_dependency_duration"} 1<PHONE_NUMBER>833
promitor_scrape_error{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="MonitorAutoscale",resource_name="app-service-autoscaling-rules",resource_group="demo",metric_name="promitor_demo_appplan_autoscale_observed_capacity"} 0<PHONE_NUMBER>862
# HELP promitor_scrape_success Provides an indication that the scraping of the resource was successful
# TYPE promitor_scrape_success gauge
promitor_scrape_success{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="AutomationAccount",resource_name="promitor-sandbox",resource_group="promitor-sources",metric_name="promitor_demo_automation_job_count"} 1<PHONE_NUMBER>895
promitor_scrape_success{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="AutomationAccount",resource_name="promitor-sandbox",resource_group="promitor-sources",metric_name="promitor_demo_automation_update_deployment_machine_runs"} 1<PHONE_NUMBER>898
promitor_scrape_success{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="FrontDoor",resource_name="promitor-landscape",resource_group="promitor-landscape",metric_name="promitor_demo_frontdoor_backend_health_per_backend"} 0<PHONE_NUMBER>989
promitor_scrape_success{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="Generic",resource_name="Microsoft.Insights/Components/docker-hub-metrics",resource_group="docker-hub-metrics",metric_name="promitor_demo_app_insights_dependency_duration_200_OK"} 0<PHONE_NUMBER>081
promitor_scrape_success{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="AppPlan",resource_name="promitor-app-plan",resource_group="promitor-sources",metric_name="promitor_demo_appplan_percentage_cpu"} 0<PHONE_NUMBER>989
promitor_scrape_success{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="AutomationAccount",resource_name="promitor-sandbox",resource_group="promitor-sources",metric_name="promitor_demo_automation_update_deployment_runs"} 1<PHONE_NUMBER>892
promitor_scrape_success{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="Generic",resource_name="Microsoft.Insights/Components/docker-hub-metrics",resource_group="docker-hub-metrics",metric_name="promitor_demo_app_insights_dependency_duration"} 0<PHONE_NUMBER>988
promitor_scrape_success{tenant_id="c8819874-9e56-4e3f-b1a8-1c0325138f27",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_type="MonitorAutoscale",resource_name="app-service-autoscaling-rules",resource_group="demo",metric_name="promitor_demo_appplan_autoscale_observed_capacity"} 1<PHONE_NUMBER>438

However, when doing the diff I cannot spot the issue: https://github.com/prom-client-net/prom-client-dependencyinjection/compare/v0.4.0...v0.5.0

I will check it

Thank you! I don't really get it but ok... 😐

@tomkerkhove I downgraded Microsoft.Extensions.DependencyInjection.Abstractions to 3.1.16 in v.0.6.0 version. It should be resolve problems

Thank you!

@tomkerkhove I downgraded Microsoft.Extensions.DependencyInjection.Abstractions to 3.1.13. I don't know how to test promitor in local machine, but I still think, that problem with version-conflict

I don't get it either and v0.6.2 doesn't work as well for me but I don't see why :/

Another think, only about this:
Before v0.5.0
services.AddSingleton(new CollectorRegistry() as ICollectorRegistry); // in code different, but should same behaviour
services.AddSingleton<IMetricFactory, MetricFactory>();

After
services.AddSingleton<ICollectorRegistry, CollectorRegistry>();
services.AddSingleton<IMetricFactory, MetricFactory>();

🤯

Hi @tomkerkhove! Is there any chance you start scrapping before configure/create all metrics? I've found a theoretical race condition, that could lead to a problems if a metric is being created while scrapping.

@tomkerkhove @phnx47 I think I can reproduce some similar problem in scenario when multiple threads trying to create a metrics while scrape is happening on another thread. I've created a unit-test to reproduce the issue and prepare a fix soon.
However the affected code was introduced more then a year ago,  and this could be some similar but not the root cause for this exact problem.

Hi @tomkerkhove! Is there any chance you start scrapping before configure/create all metrics? I've found a theoretical race condition, that could lead to a problems if a metric is being created while scrapping.

So the tricky thing is that this is where it's not working as it should:
https://github.com/tomkerkhove/promitor/blob/master/src/Promitor.Core.Scraping/Scraper.cs#L87-L89
The metrics inside ReportScrapingOutcome will be reported, but await _metricSinkWriter.ReportMetricAsync will not.
Looking in detail, they use the same approach though:

RuntimeMetricsCollector - https://github.com/tomkerkhove/promitor/blob/master/src/Promitor.Integrations.Sinks.Prometheus/RuntimeMetricsCollector.cs#L47-L48
PrometheusScrapingEndpointMetricSink through MetricSinkWriter - https://github.com/tomkerkhove/promitor/blob/master/src/Promitor.Integrations.Sinks.Prometheus/PrometheusScrapingEndpointMetricSink.cs#L77-L78

Both are configured with same lifecycle:

https://github.com/tomkerkhove/promitor/blob/f2da6eb311883add48fa582bed0ba56a9fd69066/src/Promitor.Agents.Scraper/Extensions/IServiceCollectionExtensions.cs#L97
https://github.com/tomkerkhove/promitor/blob/f2da6eb311883add48fa582bed0ba56a9fd69066/src/Promitor.Agents.Scraper/Extensions/IServiceCollectionExtensions.cs#L177-L178

@tomkerkhove as we cannot reproduce the issue on our side, could you please help with investigation on the issue? It would be perfect to have something runnable to reproduce the issue on our side. Is there any way to create a promitor version configured to use some mocks so I can pull the version and debug a problem?
Or could you please try to bump Prometheus.Client library one at the time so we can isolate a problem:

bump Prometheus.Client library to 4.5.2
check if problem appears
bump Prometheus.Prometheus.Client.DependencyInjection to 0.6.2
check again.

Also I suspect the problem might be somewhere around of multiple collector registry creation (I have no ideas how, but if the issue is consistently reproducible on your side, it could mean that different parts of code uses different collector registry... somehow). To ensure that there is only one could you please create a component that injects IEnumerable and check how many object is being injected. And finally please check if there is any collectors registered into Metrics.DefaultCollectorRegistry

I'm able to succesfully bump the client & ASP.NET version through https://github.com/tomkerkhove/promitor/pull/1691 with good results.
However, when bumping the DI package to v0.5.0 or latest it is still failing. I'll try to dive deeper into this but the easiest way to run this yourself is through https://github.com/tomkerkhove/promitor/blob/master/development-guide.md#net-development

I'm scratching my head on this one 😅

To ensure that there is only one could you please create a component that injects IEnumerable and check how many object is being injected. And finally please check if there is any collectors registered into Metrics.DefaultCollectorRegistry

Inject IEnumerable of what type exactly? Happy to give it a try.

I gave it a try and I always get 1 instance of the registry which eventually has multiple collectors.
The difference is:

The working approach injects the registry every time in the class
The not working version re-uses it for its entire lifetime

However, this is identical as how it was < v0.5

Magic =)
@tomkerkhove could you please let me know how can I debug the Promitor? As I've got the following error when I run the Scraper project:
Unable to determine the configuration folder. Please ensure that the 'PROMITOR_CONFIG_FOLDER' environment variable is set

How did you run it? Through Docker compose?

Just by running the project. Is there any way to run it without Docker?

Yes, but then you'll have to configure a few things 😅
This should help you get started: https://github.com/tomkerkhove/promitor/blob/master/development-guide.md#running-promitor

Hi @tomkerkhove ! Sorry for such long delay in updates, but I think I finally find a root cause of the problem, that makes sense and perfectly explain what have happened.
The problem in the Promitor code that explicitly makes a call to services.BuildServiceProvider(). According to the documentation this call creates a very new DI container on each call:

Calling BuildServiceProvider creates a second container, which can create torn singletons and cause references to object graphs across multiple containers.

So it means the Promitor works at least with 2 DI containers: the one explicitly created by the code and the default one (created by asp.net runtime). It also means each singleton will be existed in each container. So now it's obvious why simple changing from Register by istance to Register by type broke the metrics:

Register (by instance) we have singleton component that resolved to the pre-created instance (shared between both containers)
Register (by type) we have singleton component that should be created by container on runtime, and it produces different instances in each container.

I hope this makes sense.
So my suggestion here: remove the explicit creation of the container, as it affects not just Prometeus.Client infrastructure, but whole application lifetime logic.

Good point, didn't think about that but did it for a reason.
I'll check when I'm back from holiday and come back to it.

Probably the bootstrap logic that schedules the syncs should be moved into some new service implementing IHostedService, so it will be automatically started by runtime.

Can you elaborate on what piece you are referring to here please?

I meant the code under ScheduleMetricScraping method.
Anyway, could you please double-check if my explanation is right, so we can close the issue on our side? And have a nice holiday =)


Facebook Null Error

Hi,
Can you help me out with the Facebook sharing button, why i'm getting a null error? and where i can put my developer id for facebook?

OK solved, it needs a server web to be tested correctly not with file:/// protocol


Make the release pipeline build the wheel as well

Codecov Report

Merging #45 (3377658) into main (5198bd3) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #45   +/-   ##
=======================================
  Coverage   76.22%   76.22%
=======================================
  Files          21       21
  Lines        1607     1607
=======================================
  Hits         1225     1225
  Misses        382      382

Continue to review full report at Codecov.

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


Have doubt about the software

Hi,
Suppose I have 12 slave devices connected on RTU , how will I select the slave device for whose data I want to read via TCP modbus ?

Easy. Each slave have a different ID or address. So when you make a read from tcp (using for example qmodmaster) you have to specify ip, port and then slave ID.


Fix some warnings (redundant imports, name shadowing)

@Shimuuar: Is this PR of any use? :smile: Obviously it's nothing significant, but...

Sorry for the delay. I was quite busy lately. I'll look at it over weekend

I finally tried to do something about this PR. Problem is I'm sure it breaks build on some old GHC, but I'm unable to test it since tests are broken. So I'm leaving it hanging while I try to fix test suite

I finally tried to do something about this PR. Problem is I'm sure it breaks build on some old GHC, but I'm unable to test it since tests are broken. So I'm leaving it hanging while I try to fix test suite

Gotcha.

I cherry picked commit which fixed shadowing warning. Others quite predictably broken GHC<=7.8.

I cherry picked commit which fixed shadowing warning. Others quite predictably broken GHC<=7.8.

Thanks! I'll try building this branch on older GHC versions just to confirm and then I'll close the PR. :smiley:

Here is CI run with failures
https://travis-ci.org/Shimuuar/statistics/builds/632388942

So I dropped GHC<7.10 and this PR finally found its way into master


Old .desktop files not deleted when rename/move files using Google Drive web interface

Installed master today using go get -u github.com/odeke-em/drive/cmd/drive then ran drive pull for the first time, which amongst other things created some .desktop files.
I then renamed and moved some files using Google Drive's web interface, ran drive pull again and found that new .desktop files were created for each Google Doc but the old .desktop files corresponding to the old Google Doc filenames/locations were not deleted.
Has anyone else encountered this?  Should .desktop files be pruned/regenerated when running drive pull?

Hello there @willfurnass, welcome to drive and thank you for reporting this.
So this is an interesting case, I'll test this out over the weekend with a Linux machine.

Ahhh I now recall why this is happening and it was by design already in, just an unintended side effect. The reason for this is because on Linux and other platforms that use clickable .desktop files. We never want to move, delete, re-upload these files hence I made them ignored by default as you'll see in the source code here
https://github.com/odeke-em/drive/blob/c7ebb65f19038fa803eb3ca9156756db3e321ce5/src/misc.go#L200-L205

The reason for this is like the empty files related to Google Docs, Sheets and Presentations that should not be touched, such files shouldn't even be sent upstream either.


Make work with phoenix >1.3.0

# marcos @ marcos-ThinkPad-T440 in ~/xxx/apps/tools_feed_web on git:master x [10:22:27] C:1
$ mix deps.get
Running dependency resolution...

Failed to use "phoenix" (version 1.3.0-rc.1) because
  phoenix_live_reload (version 1.0.8) requires ~> 1.0 or ~> 1.2-rc
  rummage_phoenix (version 1.0.0) requires ~> 1.2.1
  mix.lock specifies 1.3.0-rc.1

#28 This is work in progress. I hope to get it in soon

@aditya7iyengar Thank you!
I tried to make it work with phoenix 1.3 and rammage_ecto 1.1.0 but there's a work to do in both projetcs...
Some error's that I got and can be fixed with this change:
in file  lib/rummage_phoenix/hooks/views/paginate_view.ex
-    per_page = String.to_integer(paginate_params["per_page"]) || Rummage.Phoenix.default_per_page
+    per_page = if !is_nil(paginate_params["per_page"]), do: String.to_integer(paginate_params["per_page"]), else: Rummage.Phoenix.default_per_page

Here paginate_params["per_page"]) can be null and per_page configuration is an Integer not an String

--
I don't understand how rummage handles a request. using params in url I got and error
Using params like rummage[sort][field]=name.asc&rummage[paginate][page]=1&rummage[paginate][per_page]=3 this
I got in params[rummage] :
%{"paginate" => %{"page" => 1, "per_page" => 3}, "sort" => %{"field" => "name.asc"}}
But changing to this run without error(but the features aren't working properly)
%{"rummage" => %{"paginate" => %{"page" => 1, "per_page" => 3}, "sort" => %{"field" => "name.asc"}}}
note: This module is amazing and can be a reference in hex for sorting, page and search...

Hi @aditya7iyengar I wonder if 1.3 is the reason you stopped your plans on medium.
Im planning on using rummage-phoenix for a pretty simple client database, and with all the 1.3 mystery seems everyone is on a halt.
Let us know your plans, anyways Im guessing if I have a hurry, I should build it in 1.2 and update when there's a clear path for it.

@mbenatti Thanks for the suggestion! I have a PR open in rummage_ecto for this purpose. I was down with a fever last week so couldn't get much done, but this should be all set as soon as I can find 5 hours to work on this. I will update you guys.
@agustif 1.3 is one of the reasons why my plans are on a halt. Hopefully, I can roll this out asap. In the meantime feel free to let me know if you guys have any suggestions.

It's not a suggestion, but I do wonder if rummage and ecto could get along on the same UI, what I mean is, prefer a thousand times the rummage UI/UX which is simple but powerful, exAdmin ads a lot of fields for filtering/search which are not really needed for me in the ux part (I mean, it looks more like PHPMyAdmin, than a custom interface)
BUT. I really like exAdmin for the dashboard/actions/and how it structures diferent models in tabs and such, So I'm guessing I want to use only exAdmin for the layout logic, and rummage for the view/template logic of each model.
I don't know, haven't really tried yet, let me know if you think is achievable and I might try on a PR

@agustif Sounds like a rummage_ex_admin hex package to me. I'm not sure about including it in either rummage_ecto or rummage_phoenix, but if I see people wanting to use it, it could be an a module that acts as an adapter for rummage. I have been flirting with the idea of writing adapters for rummage_ecto and rummage_phoenix being one of them. It could lead to us having more adapters with other hex packages. But it's quite farfetched at this point. 😄

This can now be used with phoenix 1.3 by calling override: true.


[REF-2592] Backend Vars in ComponentState are not independent

All instances of the ComponentState share the same backend vars, apparently
From SyncLinear.com | REF-2592

@masenf do you have an example for this?
This seems to work fine:
import reflex as rx

class ReusableCounter(rx.ComponentState):
    count: int = 0
    _bcount: int = 0

    def increment(self):
        self.count += 1
        self._bcount += 1
        print(f"count: {self.count}, _bcount: {self._bcount}")

    def decrement(self):
        self.count -= 1
        self._bcount -= 1
        print(f"count: {self.count}, _bcount: {self._bcount}")

    @classmethod
    def get_component(cls, **props):
        return rx.hstack(
            rx.button("Decrement", on_click=cls.decrement),
            rx.text(cls.count),
            rx.button("Increment", on_click=cls.increment),
            **props,
        )

reusable_counter = ReusableCounter.create

def index() -> rx.Component:
    return rx.vstack(
        reusable_counter(),
        reusable_counter(),
        reusable_counter(),
    )

app = rx.App()
app.add_page(index)

Is this issue about dirty states/vars?

@benedikt-bartscher i modified your code slightly
import reflex as rx

class ReusableCounter(rx.ComponentState):
    count: int = 0
    _bcount: list[int] = []

    def increment(self):
        self.count += 1
        self._bcount.append(self.count)
        print(f"count: {self.count}, _bcount: {self._bcount}")

    def decrement(self):
        self.count -= 1
        self._bcount.append(self.count)
        print(f"count: {self.count}, _bcount: {self._bcount}")

    @classmethod
    def get_component(cls, **props):
        return rx.hstack(
            rx.button("Decrement", on_click=cls.decrement),
            rx.text(cls.count),
            rx.button("Increment", on_click=cls.increment),
            **props,
        )

reusable_counter = ReusableCounter.create

def index() -> rx.Component:
    return rx.vstack(
        reusable_counter(),
        reusable_counter(),
        reusable_counter(),
    )

app = rx.App()
app.add_page(index)

The issue seems to be when the "default" is a mutable type and accessed directly, as opposed to assigning a new value for self._bcount

Thanks for your fast reply. Indeed, mutable default values are causing issues.
This can be mitigated by using pydantic's default_factory like this:
import reflex as rx
from pydantic.v1 import PrivateAttr

class ReusableCounter(rx.ComponentState):
    count: int = 0
    _bcount: list[int] = PrivateAttr(default_factory=list)

    def increment(self):
        self.count += 1
        self._bcount.append(self.count)
        print(f"count: {self.count}, _bcount: {self._bcount}")

    def decrement(self):
        self.count -= 1
        self._bcount.append(self.count)
        print(f"count: {self.count}, _bcount: {self._bcount}")

    @classmethod
    def get_component(cls, **props):
        return rx.hstack(
            rx.button("Decrement", on_click=cls.decrement),
            rx.text(cls.count),
            rx.button("Increment", on_click=cls.increment),
            **props,
        )

reusable_counter = ReusableCounter.create

def index() -> rx.Component:
    return rx.vstack(
        reusable_counter(),
        reusable_counter(),
        reusable_counter(),
    )

app = rx.App()
app.add_page(index)

However, it would be nice if reflex would copy those mutable defaults by default to prevent crazy issues


Slow performance on bulk insert

Bulk inserts appear to take quadratic time over the number of statements being processed. Using v1.14.16, I find that a bulk insert that finishes quickly for the sqlite3 shell does not finish at all when run in golang.
My supposition is that this is because the sqlite3_prepare_v2 function returns a pointer to the remaining unprocessed sql, which we then copy back into a Go string. On the next run of the loop in exec(), we do another roundtrip of copying strings Go->C->Go. By contrast, the sqlite3 shell performs the same task without copying the underlying buffer, and finishes significantly faster.
A representative stack trace shows indicates time spent in runtime.memmove():
runtime.memmove()
	src/runtime/memmove_amd64.s:432 +0x513 fp=0xc0005db3d0 sp=0xc0005db3c8 pc=0x19fca13
github.com/mattn/go-sqlite3._Cfunc_CString({0xc00a3d6001, 0x9254ac8})
	_cgo_gotypes.go:200 +0x7b fp=0xc0005db400 sp=0xc0005db3d0 pc=0x27ee11b
github.com/mattn/go-sqlite3.(*SQLiteConn).prepare(0xc0010ca000, {0xb2ff30?, 0xc00021a008?}, {0xc00a3d6001?, 0x0?})
	rh/external/com_github_mattn_go_sqlite3/sqlite3.go:1805 +0x5e fp=0xc0005db490 sp=0xc0005db400 pc=0x27fff3e
github.com/mattn/go-sqlite3.(*SQLiteConn).exec(0x0?, {0xb2ff30, 0xc00021a008}, {0xc0177da000?, 0x0?}, {0x3433fd0, 0x0, 0x0})
	rh/external/com_github_mattn_go_sqlite3/sqlite3.go:853 +0x99 fp=0xc0005db5d8 sp=0xc0005db490 pc=0x27f9939
github.com/mattn/go-sqlite3.(*SQLiteConn).ExecContext(0xc0005db6c8?, {0xb2ff30, 0xc00021a008}, {0xc0177da000, 0x9255f37}, {0x3433fd0, 0x0, 0xc0010ca000?})
	sqlite3_go18.go:41 +0xbb fp=0xc0005db670 sp=0xc0005db5d8 pc=0x27edb5b

Is this covered by #1133?

Yes!

This isn't an Go-SQLite3 issue. It's the expected and normal behavior. The default SQLite3 settings are set to safe, and slow.
@josnyder-rh I had the exact same problem on my project (which sole SQLite3 usage is bulk inserts). Google lead me to this amazing C++ SQLite3 performance guide and fortunately, the same techniques worked for me.
Here's the 2 line change that fixed it for me.
Basically the idea is to:

Use transactions, to batch updates in a single database commit (I didn't need it).
Disable SQLite3 synchronous mode, which block until the commit is fully writen to disk.
Set journal_mode to memory.

On production what you want to do is to create a new DB connection just for the bulk inserts, and change the PRAGMA for just those operations.
For me the result was importing 350,000 lines at 10KB/s (13min) to 3.2MB/s (2sec).


Create instascale design document

@dimakis I see that this is ready for review. Is there a Google Doc or ADR that I can take a look at?

@dimakis I see that this is ready for review. Is there a Google Doc or ADR that I can take a look at?

Just that Google doc that we have already been commenting on. I've to get back to it.
By all means, add suggestions etc.

https://docs.google.com/document/d/15t9ha7K8rH0ACPZyBD_F-2CKqBabSBbN1cmzDVkV9Gs/edit#heading=h.swxey7fqzz6d


Datagrid with pagination in a modal not showing lines unless toggling it

Describe the bug
When trying to use a datagrid with pagination in a modal the data does not appear as line items unless using an *ngIf
How to reproduce
https://stackblitz.com/edit/clarity-light-theme-v2-dvgs5q
Steps to reproduce the behavior:

Click Open Modal (data show as missing)
Click Toggle Table (disables table)
Click Toggle Table again (shows table with data)

Expected behavior
Show the line items of a datagrid on modal open
Versions
App

Angular: 8.0.1
Node: 10.13.0
Clarity: 2.0.1

Device:

Type: Dell
OS: Windows 10
Browser: Chrome, Firefox

Another way around it currently is to set the [openModal] to perpetually be true and add an *ngIf on the component tag

This is a known issue and has a few other older issues here. Your workaround is correct, and it is due to lifecycle of how components are instantiated.
Follow https://github.com/vmware/clarity/issues/895 for updates on this, until then apply the workaround.


[BUG] YOLOv5 yaml path ignored

System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 22.04
FiftyOne installed from (pip or source): pip
FiftyOne version (run fiftyone --version): 0.16.3
Python version: 3.9.12

Describe the problem
The 'path' from dataset.yaml in YOLOv5 datasets is ignored/not handled.
Example of dataset.yaml stored
names:
[cars]
nc: 1
train: ./images/train
val: ./images/val
test: ./images/test
path: some/path # ignored

path should be used like a base path for the splits e.g. train path would actually be some/path/images/train. The importer ignores this and the splits are not found. The exporter does not write path: ... in the exported dataset.yaml.
Code to reproduce issue
Provide a reproducible test case that is the bare minimum necessary to generate
the problem.
# read any yolov5 and have values for "path" key in dataset.yaml
yolo_dataset: fo.Dataset = fo.Dataset(name)
for split in splits:
    yolo_dataset.add_dir(
        yaml_path=yaml_path,
        dataset_type=fo.types.YOLOv5Dataset,
        split=split,
        tags=split,
        include_all_data=True
    )

# export the dataset
split_view = self.yolo_dataset.match_tags(split)
split_view.export(export_dir,
                  yaml_path=export_dir + '/dataset.yaml',
                  dataset_type=fo.types.YOLOv5Dataset,
                  label_field='ground_truth',
                  split=split,
                  include_confidence=True
                  )

Other info / logs
What areas of FiftyOne does this bug affect?

[ ] App: FiftyOne application issue
[x] Core: Core fiftyone Python library issue
[ ] Server: Fiftyone server issue

Willingness to contribute
The FiftyOne Community encourages bug fix contributions. Would you or another
member of your organization be willing to contribute a fix for this bug to the
FiftyOne codebase?

[x] Yes. I can contribute a fix for this bug independently.
[ ] Yes. I would be willing to contribute a fix for this bug with guidance
from the FiftyOne community.
[ ] No. I cannot contribute a bug fix at this time.

Hi @victor1cea 👋
Feel free to make a quick PR to add support for an optional path parameter; I wasn't aware that it was a possible parameter in dataset.yaml. Do you have a link for reference?
It'd be great if you could update the link in our YOLOv5 documentation to point to a place that provides more complete documentation for dataset.yaml 🤗
https://github.com/voxel51/fiftyone/blob/develop/docs/source/user_guide/dataset_creation/datasets.rst#yolov5dataset
https://github.com/voxel51/fiftyone/blob/develop/docs/source/user_guide/export_datasets.rst#yolov5dataset

Hi @brimoor
I will gladly make a PR.
This  is the reference from the official repo.
Go to 1. Create Dataset -> Or manually prepare your dataset  -> 1.1 Create dataset.yaml.
They also unofficially support  the optional download parameter as seen here.  If you think that support for this parameter is needed, just let me know.

Cool! Supporting download is fine with me if you'd like to add it. I guess it would download the zip and unpack it to the locations specified by train, val, path, etc.?

Yes,  exactly. I will look into adding support for download too. :smile:

Fixed by https://github.com/voxel51/fiftyone/pull/2016!


[CT-1844] Improve Granularity of Log Configuration

Describe the feature
This is a proposal which would subsume the following four issues:

https://github.com/dbt-labs/dbt-core/issues/6580
https://github.com/dbt-labs/dbt-core/issues/6312
https://github.com/dbt-labs/dbt-core/issues/5208
https://github.com/dbt-labs/dbt-core/issues/6615

The proposal is to modify log configuration so that the following command line help would be accurate, allowing for independent file and console log configuration of color, format, and level:
  --log-format {text,json,default}
  --log-format-file {text,json,default}
                        Specify the log format, overriding the command's
                        default. The standard option will apply the format
                        to both console and file output, unless the -file
                        variant (which can also appear alone) is used to
                        override the log file format.
   --log-level {debug, info, warn, error, none}
   --log-level-file {debug, info, warn, error, none}
                        Set the logging level. Dbt will log events at or above
                        the severity level specified. The standard option will
                        apply to both console and file output, unless the
                        -file variant (which can also appear alone) is used to
                        override the log file format. The 'none' level disables
                        all log output, including log file creation.
  --use-colors          Colorize (or do not colorize when using the 'no'
  --use-colors-file     variants) dbt's log output. Output is colorized by
  --no-use-colors       by default and may also be set in a profile or at
  --no-use-colors-file  the command line. The standard option will apply to
                        to both console and file output, unless the -file
                        variant (which can also appear alone) is used to
                        override the log file colorization.

@jtcohen6 and @MichelleArk I'd be interested in your feedback on the basic ideas here. Do you think it makes the command line options too numerous or confusing?

@peterallenwebb Nice work consolidating the many requests into a single coherent proposal!
The target audience for these configs is CLI users. There have been two (and exactly two) default loggers in dbt-core since the dawn of time: "stdout" + "file." I don't anticipate adding any new ones. These configs would make it possible for CLI users to have more granular control over the two loggers that are set up by default.
If I'm following you correctly:

dbt --log-level none would disable ALL logging
dbt --log-level-file none would disable file logging ONLY
dbt --log-level none --log-level-file debug would disable stdout logging, but preserve debug-level file logging

It would also be possible to pass these flags into a programmatic invocation. For anything else, though—configuring additional loggers, with greater flexibility, etc—there's registering a callback on the EventManager.

@jtcohen6 Your examples capture my intentions, yes.

I think that in general a user should get able to override the entire logging configuration with their own config file.  There is no reason for dbt to have to support every nuance of user preferences around logging.  Just allow a logging config file to be provided using the standard python logging library configuration.  The file logging is the most annoying part.  However, usually when I use a library I define all of the loggers with my own configuration so that all of the logs are formatted the same and can be parsed the same with downstream tools.  If someone wants a more managed approach they can use the existing option.  However, if someone wants to do something else they can provide a log config.
Otherwise you will end up having to reproduce all the options in the python logging config in the cli.

@DustinMoriarty To help us better understand - could you provide a specific example of the logging config file you're imagining? Is it what's outlined in the docs here?
I've just copy-pasted the following from those docs, I'm not specifically endorsing or advocating for something like this:
handlers:
  console:
    class : logging.StreamHandler
    formatter: brief
    level   : INFO
    filters: [allow_foo]
    stream  : ext://sys.stdout
  file:
    class : logging.handlers.RotatingFileHandler
    formatter: precise
    filename: logconfig.log
    maxBytes: 1024
    backupCount: 3

@DustinMoriarty To help us better understand - could you provide a specific example of the logging config file you're imagining? Is it what's outlined in the docs here? (I've just copy-pasted the following from those docs, I'm not specifically endorsing or advocating for something like this:)

handlers:

  console:

    class : logging.StreamHandler

    formatter: brief

    level   : INFO

    filters: [allow_foo]

    stream  : ext://sys.stdout

  file:

    class : logging.handlers.RotatingFileHandler

    formatter: precise

    filename: logconfig.log

    maxBytes: 1024

    backupCount: 3

From my perspective: There is some genuine dbt-specific complexity with the way that our loggers operate, and we've put a lot of thought into its default behaviors and out-of-the-box configuration options, even at the risk of them being somewhat non-standard. For folks who want full control over exactly how to configure and run dbt-core, we are undertaking the work (for v1.5) of supporting a Python API / programmatic invocations for the first time, and providing a clean entry point to register your own callback (https://github.com/dbt-labs/dbt-core/issues/6763), which should enable whichever logging handlers with whatever configuration you want.

@jtcohen6 :  yes I am suggesting allowing the logging config to be passed in.  However, for CLI use a file config is more common and appropriate in my mind.  The dictionary config is for calling directly within python.  A --logging-config-file argument would probably meet all future logging needs.  file config docs

The format of the file config is standardized using INI, not yaml or json.  It is good to use this format because users may be using the same config file to configure other parts of their application.

Also, for python invocation, I would leave logging unconfigured.  Configuration of logging is the job of the top level application.

For the complexity of current log config, as long as all that extra data in JSON structured logging is passed to the extra argument in the log statements then it can be picked up by a structured log formatter.

@DustinMoriarty Ok! Could I ask you to open a new issue requesting that functionality? We're going to move ahead with this issue as presently scoped. At the same time, I can see merit in this feature request: If an end user provides logging config in a log.ini (?) configuration file, we should do our best to respect that file's configuration. I'd be curious to see how many other users / community members would be interested in the same.

This has come up again in a more recent discussion, so I've opened a separate issue to track it, and serve as forum for other folks to weigh in if they'd also be interested: https://github.com/dbt-labs/dbt-core/issues/6993


How to load the model with a pretrained model_final.pt file so that training starts onwards?

I had set the epochs to 100, however, due to disk size limitation, the training was interrupted at epoch 91. Now I want to further train my model say for another 50 epochs using the csv_retinanet_91.pt as starting point. With the Keras-TensorFlow implementation of Retinanet, this can be achieved using the snapshot argument. How can I do this in PyTorch implementation?
Thanks in advance.

okay I got it, it simply works with the following code
retinanet=torch.load('csv_retinanet_91.pt') after laoding the resnet backbone


🐛 Bug Report: JOIN THE NEWSLETTER UI Enhancement

🐛 Bug description
The Text Box and Join button coincide with each other at the end and starting respectively. Below are the Screenshots as a proof.
Screenshots

✨ It would be nice

If there's some gap between the Text Box and Join button.
To change mail icon color in the Text Box from  #52575C to  #CB3364.

👀 Have you spent some time to check if this issue has been raised before?

[x] I checked and didn't find similar issue.

🏢 Have you read the Code of Conduct?

[x] I have read the Code of Conduct.

Hey @lucavallin , If you consider this issue, please assign this to me so that I can make a PR for it.

Hey @nishitxmehta, thanks for the issue! I am about to replace that component with another provider, so no work needed here this time.


AppState: runs on both on the client and the server

I use kadira:flow-router and kadira:flow-router-ssr。
kadira:flow-router-ssr：Write your app in a place it's expose to both client and the server.

Hi @TeemoWan
What's the issue? Do you want AppState in the server?

yes，i use react and kadira:flow-router-ssr，Need to use on the server side

Could you please share an example of an app with server side rendering? Are you using React or Blaze?  Do you need AppState to be reactive in the server side as well (I suppose you don't), or only mimic what is capable of in the client?

for example:
login.jsx:
Login = React.createClass({
mixins: [ReactMeteorData],
getInitialState() {
AppState.set('Auth', {
Login: {
succeed: false,
errorMessage: ''
}
});
return {}

},
getMeteorData() {
return {
errorMessage: AppState.get('Auth.Login.errorMessage'),
loggingIn: Meteor.loggingIn()
}
},
render() {
...
}
})
Dispatcher.register(
function(action){
switch(action.type){
case 'GO_TO_LOGIN':
ReactLayout.render(AuthLayout, { content:  });
break;
case 'LOGIN_SUCCEED':
AppState.set('Auth.Login.succeed', true);
break;
case 'LOGIN_FAILED':
AppState.set('Auth.Login.succeed', false);
AppState.set('Auth.Login.errorMessage', action.error.reason);
break;
}
}
);
Tracker.autorun(function(){
var loginState = AppState.get('Auth.Login.succeed');
if (loginState) {
Dispatcher.dispatch({ type: 'GO_TO_HOME' });
}
});

Ok, so I guess you are fine with a version of AppState which is defined on the server and only sets and gets stuff, without reactivity, for the first render. Is that ok?
By the way, did you get a "Cannot dispatch in the middle of another dispatch" error with the GO_TO_HOME redirection and you avoided it using AppState.set('Auth.Login.succeed', true); or is this by design?

Thank you.
For the first render, if define a version of component on the server without reactivity, then most of components in the project need to define twice.  Is that good?

For the first render, if define a version of component on the server without reactivity, then most of components in the project need to define twice. Is that good?

Could you please explain this in a different way? I don't understand what you are trying to say.

I will close this now but if you have any comment just reopen it.


feat: change tokio UnixStream to not use AsyncFd

Extract the sendmsg/recvmsg handling from the synchronous UnixStream into
a new (internal) BiQueue struct and then use a BiQueue to reimplement the
fd_queue::tokio::UnixStream in terms of the tokio UnixStream instead of
AsyncFd wrapping the sychnounous UnixStream from this crate. This makes
the net_fd and tokio_fd features independant and simplified the dependancies.
Also increase the documentation on tokio::UnixStream since its is now
independant of the synchronous UnixStream so we can't count on its
documentation being available.
This change requires increasing the MRSV to 1.61, which means that we cannot
merge this PR until version 1.63 is released.
This PR also changes to MRSV policy to allow increasing the MRSV on an increase
in the minor part of the version number, instead of the former policy of
treating a change to the MRSV as a breaking change (requiring an increase to
the major version number). The old policy was too restrictive. It would have
required a breaking change to the interface of tokio::UnixStream or a breaking
change to increase the MRSV. A breaking change this close to the release of
version 1.0.0 is not desirable.
The removal of the interdependancy between tokio::UnixStream and the
synchronous UnixStream necessitated some clean-up of the crate features. The
PR also adds some CI tests to make sure the the features can each be
individually enabled.
closes: #35

Note that Rust version 1.63.0 was released on August 11, 2022 so the increased MRSV is no longer blocking having this merged.


wget https://raw.githubusercontent.com/tloen/alpaca-lora/main/alpaca_data_cleaned.json -O data/alpaca_clean.json

I received the below error.  It seems this error means that the specified URL "https://raw.githubusercontent.com/tloen/alpaca-lora/main/alpaca_data_cleaned.json" returned a 404 Not Found HTTP response code, indicating that the requested resource was not found on the server.
This error could occur for several reasons, including:
The URL may be incorrect or outdated, and the resource may have been moved or deleted.
The server hosting the resource may be down or inaccessible.
The resource may have been intentionally removed or blocked.
In this case, it seems that the alpaca_data_cleaned.json file could not be found at the specified location. You may want to check if the file exists at the URL or if the URL has changed.
The file alpaca_data_cleaned.json seems to be no longer available.
wget https://raw.githubusercontent.com/tloen/alpaca-lora/main/alpaca_data_cleaned.json -O data/alpaca_clean.json
--2023-04-10 09:39:10--  https://raw.githubusercontent.com/tloen/alpaca-lora/main/alpaca_data_cleaned.json
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2023-04-10 09:39:11 ERROR 404: Not Found.

https://github.com/declare-lab/flan-alpaca/pull/14
Use wget https://raw.githubusercontent.com/tloen/alpaca-lora/main/alpaca_data_cleaned_archive.json -O data/alpaca_clean.json

Hi, the data links are fixed now, we are hosting the datasets in the release to avoid future broken links in external repos
The download commands are updated in the readme

Thanks for the rapid response!


Remove __internal from types

As our JS and TS generation is separate by now, we can just remove the __internal constructor args from the generated Prisma Client types.

Closed with https://github.com/prisma/prisma/commit/5d0f032843a164f963939bbd1bb85e18313a6a8d


[Question] Export multiple components

Is there a way to export multiple components from one crate?
Use case: Implement game scripting system. Use one crate (one wasm file) for multiple game scripts instead of compile multiple crates (multiple wasm files).
use bindings::test_component;

struct Component;
struct AnotherComponent;

impl test_component::TestComponent for Component {
    fn hello_world() -> String {
        "Hello, World!".to_string()
    }
}

impl test_component::TestComponent for AnotherComponent {
    fn hello_world() -> String {
        "Another Hello, World!".to_string()
    }
}

bindings::export!(Component);
bindings::export!(AnotherComponent);

> cargo component build
   Compiling test_component v0.1.0 (C:\Dev\RustProjects\test_component)
error[E0428]: the name `__FORCE_SECTION_REF` is defined multiple times
  --> src\lib.rs:18:1
   |
18 | bindings::export!(Component);
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `__FORCE_SECTION_REF` redefined here
19 | bindings::export!(AnotherComponent);
   | ----------------------------------- previous definition of the value `__FORCE_SECTION_REF` here
   |
   = note: `__FORCE_SECTION_REF` must be defined only once in the value namespace of this module
   = note: this error originates in the macro `bindings::export` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0428]: the name `__force_section_ref` is defined multiple times
  --> src\lib.rs:18:1
   |
18 | bindings::export!(Component);
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `__force_section_ref` redefined here
19 | bindings::export!(AnotherComponent);
   | ----------------------------------- previous definition of the value `__force_section_ref` here
   |
   = note: `__force_section_ref` must be defined only once in the value namespace of this module
   = note: this error originates in the macro `bindings::export` (in Nightly builds, run with -Z macro-backtrace for more info)

Hi @Gordon-F. Thanks for the question!
Unfortunately there is no way to define multiple components in a single cargo-component project currently.
cargo-component is designed to only produce a single WebAssembly component (i.e. a single component wasm file defining a single nested WebAssembly module implementing the component).
However, it is possible do define multiple nested components in a WebAssembly component. In theory, a separate tool could be implemented to take multiple WebAssembly components and bundle them together into a single component that exports the inner components. Even so, there would be the requirement of having multiple cargo-component projects.
It is also possible to statically share code between multiple components using normal crate dependencies, but each component will get their own copy of the code.
Could you explain more about the desire to define multiple components in a project? Is it simply to bundle them together or do you envision the components to be able to share a single copy of code?

@peterhuene thank you for the explanation!

Could you explain more about the desire to define multiple components in a project? Is it simply to bundle them together or do you envision the components to be able to share a single copy of code?

Currently, I'm trying to prototype a scripting system for a game engine based on WASM. And I want to use Rust as one of the scripting languages.
For example, a scenario with existing game engines like Unity/Godot/Defold/etc.:

Create an entity
Attach script (Lua, C#, etc.)
Write some code
Hit the run button and test game

If we try to re-implement this with Rust as a scripting language, we should create a new crate for every new script. Unfortunately, this is not very convenient. I thought that cargo-component may help here.


Document how to apply changes without copy-paste

This is the beginning of a contribution guide.
Overtime the collaborators of this repo have developed their own ways around improving the repository, so to help share ideas and solutions to common problems, I started with documenting how I normally apply changes avoiding copy-paste.

@omron93 @php-coder @bparees PTAL

Maybe we should talk a bit about Bash code style that we're using?

There is --check and --reject in git-apply.

Maybe we should talk a bit about Bash code style that we're using?

Yes, I intentionally left that out for a future topic/PR, one thing at a time.
I wanted to start with sharing just this snippet that gets used by myself with for almost every change, and possibly learn from other collaborators better ways to do it.

Yes, I intentionally left that out for a future topic/PR, one thing at a time.

Ok. So, it's a good start then!

@php-coder @praiskup I've updated based on your feedback, thank you!
I've mentioned some more alternatives for when the patch doesn't apply, and suggested using Meld for side-by-side editing and diff'ing. Of course people are free to use whatever they feel like, including copy-paste.
I just want to give an advice instead of leaving contributors in the dark.

It would be fine these instruction could be shared (at least) by C&Ping it elsewhere.
Also consider:
$ git diff diff [--cached]  | git apply -p2 --directory VERSION --reject
$ find -name '*.rej'
... Dockerfile.rej

git diff [--cached]  | git apply -p2 --directory VERSION --reject

@praiskup beautiful. Learning this already paid off the PR :)
Thank you!

Updated with @praiskup's awesome suggestion.
@bparees PTAL

thanks @rhcarvalho


[otbn] Handle memory errors in the ISS and re-enable smoke test

Force-push adds support for getting the err_code value from the internals of the model, out to the wider RTL simulation. This is needed to get things right when running a chip simulation with a model and no OTBN RTL when it runs a program that generates an error code. Of course, I've also wired things up properly in the Verilator block-level testbench so that it checks that the error code gets set properly.

Note that the trace handling changes in this PR clash with those in #4614. Whichever one gets merged second will need a bit of rejigging in the ISS wrapper.


File Explorer preview pane switching does not work

Microsoft PowerToys version
0.79.0
Installation method
GitHub
Running as admin
Yes
Area(s) with issue?
File Explorer: Preview Pane
Steps to reproduce
I installed powertoy 0.79.0, in "File Explorer add-ons", it enabled preview pane for types of files by default. Including txt, python and pdf.

It failed to render the text in preview pane.

It failed to render the pdf in preview pane.

It failed to render the python in preview pane.

When I disable preview pane for "Source code files" and "pdf", the preview pane works

txt preview

python preview

pdf preview

✔ Expected Behavior
PowerToy "File Explorer add-ons" enables a preview pane for types of files by default. The preview pane should work.
❌ Actual Behavior
Preview pane in PowerToy's "File Explorer add-ons" won't work until preview switches are turned off.ew switches.
Other Software
No response

I searched for similar issues, but they did not mention the root cause, mostly the preview pane implementation. The issue is from the switching button.
PDF preview not working #28537
https://github.com/microsoft/PowerToys/issues/28537
Preview Pane Does not show PDFs or Code files #29916
https://github.com/microsoft/PowerToys/issues/29916
I cloned the repository, debugged this issue in visual studio. To enable preview pane by default, it actually binds with disabled configurations. I attached the screenshots with 0.79 powertoy repository.
In PowerToys\src\settings-ui\Settings.UI\SettingsXAML\Views\PowerPreviewPage.xaml

Please give me an opportunity to fix it!

I will create a pull request early next week.

Having this same problem on a fresh install of Windows 11. Switching off the option for "Source code files (Monaco)" makes .txt previews work. Switching off .pdf previews makes .pdf previews work. @jingchen01jingchen01's assessment is spot on. Super weird.


somethings wrong with vocals

Describe your bug here.
before you say name the vocals voices, i have already named the vocals voices.
i was making a chart, the vocals work for the charting menu, but not when i test the songs chart.
i redownloaded psych engine because i thought something was wrong with the application, but for every psych engine i downloaded, it never worked. i tried remaking the chart and that didnt work. is it okay if you could help, but if not, its totally understandable.
Command Prompt/Terminal logs (if existing)
No response
Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows
Did you edit anything in this build? If so, mention or summarize your changes.
yes, i renamed the vocals to voices

Is the "Has voice track" enabled in the "song" section on the chart editor? I think thats what the problem is

uh idk i will check

oh, i found it. thanks!


loading observable

What about a loading$ property on Store class that emit a boolean ?

Yes, that would be great for Stores that are specialized in storing data
fetched asynchronously from the server (as most are, obviously). However,
the sparix Store can also be used for synchronous data (a shopping cart,
for example), in which case the loading$ property wouldn't make much sense.
It may be time to start working on an HttpStore or RESTfulStore or
BackendStore (or a separate sparix-data project) to provide generic CRUD
functionnality, among other things. In the meantime, it is pretty
straightforward to add a loading$ property to an existing Store, or to a
Store's abstract subclass.
--
Mikael Couzic
Appartement 131
32, rue du Javelot
75013 Paris
06 51 17 97 83
2016-05-23 20:28 GMT+02:00 Charles Jacquin<EMAIL_ADDRESS>
What about a loading$ property on Store class that emit a boolean ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/micouz/sparix/issues/1


Fix profile_link leading to NotFound error

remove a path for teiserver, as the production API throws Not Found.

and after investigation the path element teiserver is not needed.

Hotfix deployed.


Does this support structured append?

I'd like to take some data and turn it into 2+ qr codes using the structured append feature.

It does not. Shameless plug: Segno supports it: https://pypi.python.org/pypi/segno/


Added test of HA 2023.11.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (4f82aae) 86.64% compared to head (e72c064) 86.64%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #32   +/-   ##
=======================================
  Coverage   86.64%   86.64%
=======================================
  Files          13       13
  Lines         996      996
=======================================
  Hits          863      863
  Misses        133      133

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


error dialing backend: EOF

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
When I am executing a "cilium status" command on all my three clusters I am getting an "error dialing backend: EOF" message.
Below is the full output:
[opc@o-jpircv ~]$ for c in c1 c2 c3; do
>   kubectx $c
>   cilium status
> done
Switched to context "c1".
    /¯¯\
 /¯¯\__/¯¯\    Cilium:             4 errors
 \__/¯¯\__/    Operator:           OK
 /¯¯\__/¯¯\    Envoy DaemonSet:    disabled (using embedded mode)
 \__/¯¯\__/    Hubble Relay:       OK
    \__/       ClusterMesh:        OK

Deployment             hubble-ui                Desired: 1, Ready: 1/1, Available: 1/1
Deployment             clustermesh-apiserver    Desired: 1, Ready: 1/1, Available: 1/1
Deployment             cilium-operator          Desired: 2, Ready: 2/2, Available: 2/2
DaemonSet              cilium                   Desired: 2, Ready: 2/2, Available: 2/2
Deployment             hubble-relay             Desired: 1, Ready: 1/1, Available: 1/1
Containers:            clustermesh-apiserver    Running: 1
                       hubble-ui                Running: 1
                       cilium                   Running: 2
                       cilium-operator          Running: 2
                       hubble-relay             Running: 1
Cluster Pods:          6/6 managed by Cilium
Helm chart version:
Image versions         cilium                   quay.io/cilium/cilium:v1.15.4@sha256:b760a4831f5aab71c711f7537a107b751d0d0ce90dd32d8b358df3c5da385426: 2
                       cilium-operator          quay.io/cilium/operator-generic:v1.15.4@sha256:404890a83cca3f28829eb7e54c1564bb6904708cdb7be04ebe69c2b60f164e9a: 2
                       hubble-relay             quay.io/cilium/hubble-relay:v1.15.4@sha256:03ad857feaf52f1b4774c29614f42a50b370680eb7d0bfbc1ae065df84b1070a: 1
                       clustermesh-apiserver    quay.io/cilium/clustermesh-apiserver:v1.15.4@sha256:3fadf85d2aa0ecec09152e7e2d57648bda7e35bdc161b25ab54066dd4c3b299c: 2
                       hubble-ui                quay.io/cilium/hubble-ui:v0.13.0@sha256:7d663dc16538dd6e29061abd1047013a645e6e69c115e008bee9ea9fef9a6666: 1
                       hubble-ui                quay.io/cilium/hubble-ui-backend:v0.13.0@sha256:1e7657d997c5a48253bb8dc91ecee75b63018d16ff5e5797e5af367336bc8803: 1
Errors:                cilium                   cilium-psq45    unable to retrieve cilium status: error with exec request (pod=kube-system/cilium-psq45, container=cilium-agent): error dialing backend: EOF
                       cilium                   cilium-psq45    unable to retrieve cilium endpoint information: error with exec request (pod=kube-system/cilium-psq45, container=cilium-agent): error dialing backend: read tcp <IP_ADDRESS>:45892-><IP_ADDRESS>:40755: read: connection reset by peer
                       cilium                   cilium-9trbw    unable to retrieve cilium status: error with exec request (pod=kube-system/cilium-9trbw, container=cilium-agent): error dialing backend: EOF
                       cilium                   cilium-9trbw    unable to retrieve cilium endpoint information: error with exec request (pod=kube-system/cilium-9trbw, container=cilium-agent): error dialing backend: EOF
Switched to context "c2".
    /¯¯\
 /¯¯\__/¯¯\    Cilium:             4 errors
 \__/¯¯\__/    Operator:           OK
 /¯¯\__/¯¯\    Envoy DaemonSet:    disabled (using embedded mode)
 \__/¯¯\__/    Hubble Relay:       OK
    \__/       ClusterMesh:        OK

DaemonSet              cilium                   Desired: 2, Ready: 2/2, Available: 2/2
Deployment             hubble-ui                Desired: 1, Ready: 1/1, Available: 1/1
Deployment             hubble-relay             Desired: 1, Ready: 1/1, Available: 1/1
Deployment             clustermesh-apiserver    Desired: 1, Ready: 1/1, Available: 1/1
Deployment             cilium-operator          Desired: 2, Ready: 2/2, Available: 2/2
Containers:            cilium                   Running: 2
                       cilium-operator          Running: 2
                       hubble-ui                Running: 1
                       hubble-relay             Running: 1
                       clustermesh-apiserver    Running: 1
Cluster Pods:          6/6 managed by Cilium
Helm chart version:
Image versions         cilium                   quay.io/cilium/cilium:v1.15.4@sha256:b760a4831f5aab71c711f7537a107b751d0d0ce90dd32d8b358df3c5da385426: 2
                       cilium-operator          quay.io/cilium/operator-generic:v1.15.4@sha256:404890a83cca3f28829eb7e54c1564bb6904708cdb7be04ebe69c2b60f164e9a: 2
                       hubble-ui                quay.io/cilium/hubble-ui:v0.13.0@sha256:7d663dc16538dd6e29061abd1047013a645e6e69c115e008bee9ea9fef9a6666: 1
                       hubble-ui                quay.io/cilium/hubble-ui-backend:v0.13.0@sha256:1e7657d997c5a48253bb8dc91ecee75b63018d16ff5e5797e5af367336bc8803: 1
                       hubble-relay             quay.io/cilium/hubble-relay:v1.15.4@sha256:03ad857feaf52f1b4774c29614f42a50b370680eb7d0bfbc1ae065df84b1070a: 1
                       clustermesh-apiserver    quay.io/cilium/clustermesh-apiserver:v1.15.4@sha256:3fadf85d2aa0ecec09152e7e2d57648bda7e35bdc161b25ab54066dd4c3b299c: 2
Errors:                cilium                   cilium-gfxl7    unable to retrieve cilium status: error with exec request (pod=kube-system/cilium-gfxl7, container=cilium-agent): error dialing backend: dial tcp <IP_ADDRESS>:10250: i/o timeout
                       cilium                   cilium-gfxl7    unable to retrieve cilium endpoint information: error with exec request (pod=kube-system/cilium-gfxl7, container=cilium-agent): error dialing backend: dial tcp <IP_ADDRESS>:10250: i/o timeout
                       cilium                   cilium-x8klx    unable to retrieve cilium status: error with exec request (pod=kube-system/cilium-x8klx, container=cilium-agent): error dialing backend: dial tcp <IP_ADDRESS>:10250: i/o timeout
                       cilium                   cilium-x8klx    unable to retrieve cilium endpoint information: error with exec request (pod=kube-system/cilium-x8klx, container=cilium-agent): error dialing backend: dial tcp <IP_ADDRESS>:10250: i/o timeout
Switched to context "c3".
    /¯¯\
 /¯¯\__/¯¯\    Cilium:             4 errors
 \__/¯¯\__/    Operator:           OK
 /¯¯\__/¯¯\    Envoy DaemonSet:    disabled (using embedded mode)
 \__/¯¯\__/    Hubble Relay:       OK
    \__/       ClusterMesh:        OK

DaemonSet              cilium                   Desired: 2, Ready: 2/2, Available: 2/2
Deployment             hubble-ui                Desired: 1, Ready: 1/1, Available: 1/1
Deployment             hubble-relay             Desired: 1, Ready: 1/1, Available: 1/1
Deployment             cilium-operator          Desired: 2, Ready: 2/2, Available: 2/2
Deployment             clustermesh-apiserver    Desired: 1, Ready: 1/1, Available: 1/1
Containers:            cilium                   Running: 2
                       hubble-ui                Running: 1
                       hubble-relay             Running: 1
                       clustermesh-apiserver    Running: 1
                       cilium-operator          Running: 2
Cluster Pods:          6/6 managed by Cilium
Helm chart version:
Image versions         hubble-ui                quay.io/cilium/hubble-ui:v0.13.0@sha256:7d663dc16538dd6e29061abd1047013a645e6e69c115e008bee9ea9fef9a6666: 1
                       hubble-ui                quay.io/cilium/hubble-ui-backend:v0.13.0@sha256:1e7657d997c5a48253bb8dc91ecee75b63018d16ff5e5797e5af367336bc8803: 1
                       hubble-relay             quay.io/cilium/hubble-relay:v1.15.4@sha256:03ad857feaf52f1b4774c29614f42a50b370680eb7d0bfbc1ae065df84b1070a: 1
                       clustermesh-apiserver    quay.io/cilium/clustermesh-apiserver:v1.15.4@sha256:3fadf85d2aa0ecec09152e7e2d57648bda7e35bdc161b25ab54066dd4c3b299c: 2
                       cilium-operator          quay.io/cilium/operator-generic:v1.15.4@sha256:404890a83cca3f28829eb7e54c1564bb6904708cdb7be04ebe69c2b60f164e9a: 2
                       cilium                   quay.io/cilium/cilium:v1.15.4@sha256:b760a4831f5aab71c711f7537a107b751d0d0ce90dd32d8b358df3c5da385426: 2
Errors:                cilium                   cilium-7dz52    unable to retrieve cilium status: error with exec request (pod=kube-system/cilium-7dz52, container=cilium-agent): error dialing backend: EOF
                       cilium                   cilium-7dz52    unable to retrieve cilium endpoint information: error with exec request (pod=kube-system/cilium-7dz52, container=cilium-agent): error dialing backend: EOF
                       cilium                   cilium-pbpsm    unable to retrieve cilium status: error with exec request (pod=kube-system/cilium-pbpsm, container=cilium-agent): error dialing backend: EOF
                       cilium                   cilium-pbpsm    unable to retrieve cilium endpoint information: error with exec request (pod=kube-system/cilium-pbpsm, container=cilium-agent): error dialing backend: EOF
[opc@o-jpircv ~]$

Cilium Version
[opc@o-jpircv ~]$ cilium version
cilium-cli: v0.16.4 compiled with go1.22.1 on linux/amd64
cilium image (default): v1.15.3
cilium image (stable): v1.15.3
cilium image (running): 1.15.4
[opc@o-jpircv ~]$

Kernel Version
[opc@o-jpircv ~]$ uname -a
Linux o-jpircv 5.15.0-<IP_ADDRESS>.el8uek.x86_64 #2 SMP Thu Feb 8 17:14:39 PST 2024 x86_64 x86_64 x86_64 GNU/Linux
[opc@o-jpircv ~]$

Kubernetes Version
[opc@o-jpircv ~]$ kubectl version
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.10+3.el8", GitCommit:"064cdc5964787d3615cad6ec279994aee30cc0ea", GitTreeState:"clean", BuildDate:"2024-01-08T21:13:14Z", GoVersion:"go1.20.10", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"28", GitVersion:"v1.28.2", GitCommit:"6f3fcf83109204e359ca38144405293dbeec2200", GitTreeState:"clean", BuildDate:"2023-10-20T09:33:45Z", GoVersion:"go1.20.8 4493 X:boringcrypto", Compiler:"gc", Platform:"linux/amd64"}
WARNING: version difference between client (1.26) and server (1.28) exceeds the supported minor version skew of +/-1
[opc@o-jpircv ~]$

Regression
N/A
Sysdump
cilium-sysdump-20240419-075928.zip
Relevant log output
No response
Anything else?
No response
Cilium Users Document

[ ] Are you a user of Cilium? Please add yourself to the Users doc

Code of Conduct

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

Are you able to run cilium status by exec'ing into cilium pods? Are you able to access the cilium pod logs?

Are you able to run cilium status by exec'ing into cilium pods? Are you able to access the cilium pod logs?

 Are you able to access the cilium pod logs?

I am NOT able to see the status by exec'ing into cilium pods, I am getting these errors below:
[opc@o-jpircv ~]$ kubectx c1
Switched to context "c1".
[opc@o-jpircv ~]$
[opc@o-jpircv ~]$ ./k8s-cilium-exec.sh cilium-dbg status
==== detail from pod cilium-9trbw , on node <IP_ADDRESS>
Error from server: error dialing backend: dial tcp <IP_ADDRESS>:10250: i/o timeout

==== detail from pod cilium-psq45 , on node <IP_ADDRESS>
Error from server: error dialing backend: dial tcp <IP_ADDRESS>:10250: i/o timeout

[opc@o-jpircv ~]$ kubectx c2
Switched to context "c2".
[opc@o-jpircv ~]$ ./k8s-cilium-exec.sh cilium-dbg status
==== detail from pod cilium-x8klx , on node <IP_ADDRESS>
Error from server: error dialing backend: dial tcp <IP_ADDRESS>:10250: i/o timeout

==== detail from pod cilium-gfxl7 , on node <IP_ADDRESS>
Error from server: error dialing backend: dial tcp <IP_ADDRESS>:10250: i/o timeout

[opc@o-jpircv ~]$ kubectx c3
Switched to context "c3".
[opc@o-jpircv ~]$ ./k8s-cilium-exec.sh cilium-dbg status
==== detail from pod cilium-7dz52 , on node <IP_ADDRESS>
Error from server: error dialing backend: dial tcp <IP_ADDRESS>:10250: i/o timeout

==== detail from pod cilium-pbpsm , on node <IP_ADDRESS>
Error from server: error dialing backend: dial tcp <IP_ADDRESS>:10250: i/o timeout

[opc@o-jpircv ~]$

the issue is resolved, the control plane contained a network security group that was too restrictive on the network level.


feat: Dockerfile

Hey! Nice project you got there :)
I'm running an MC instance in Kubernetes and wanted to scratch an itch: Bluemap is unstable af, also generates enormous files. This project is the most perfect thing. With the small exception of nether/end support.
Usage:
docker build -f Dockerfile -t ghcr.io/neocturne/minedmap:latest
docker build -f Dockerfile.viewer -t ghcr.io/neocturne/minedmap-viewer:latest
docker run --rm -v ./data/world:/input -v ./output:/output ghcr.io/neocturne/minedmap:latest --sign-prefix '' /input /output
docker run -it --rm -v ./output/:/usr/share/nginx/html/data -p 8080:80 ghcr.io/neocturne/minedmap-viewer:latest

Finally open up localhost:8080 in a browser of your choice.

Maybe also add the build/run instructions as comments in the Dockerfiles?

Maybe also add the build/run instructions as comments in the Dockerfiles?

Mount path of the viewer not intuitive, included a small hint. Other than that it should be straightforward for anyone using docker. These lines could be included in some kind of documentation, that would be a lot better place for this info.

Thanks!


pipenv

Any chance we get a pipenv status as a prompt element?
https://github.com/pypa/pipenv

my bad, using virtualenv prompt element will show the current virtual enviorment created with pipenv. it works as intended

Glad you got it sorted, @hiimdoublej! =)


Gradle complierArgs behaves strange with Java modules

Expected Behavior
Build should succeed
Current Behavior
Build fails because JARs are not put on --module-path but on classpath. Replacing classpath with custom --module-path argument doesn't work though because Gradle duplicates the configured value?!
Context
Trying to migrate a multi-module Maven project that uses module-info.java files to Gradle. It works fine with Maven though.
These two issues seem relevant https://github.com/gradle/gradle/issues/12630 and https://github.com/gradle/gradle/issues/13147
Steps to Reproduce
You can find a reproducer application attached. Running gradlew compileJava you will see an error because the tika-core JAR is not put on the --module-path as you can see when running gradlew clean compileJava --debug.
Uncommenting the "workaround" in the subproject/build.gradle that is often found on StackOverflow, which sets the --module-path compiler argument and empties the classpath, does not work as Gradle seems to duplicate the configured compiler arguments as you can see when running gradlew clean compileJava --debug again.
Note that adding the following also didn't help:
java {
	modularity.inferModulePath = false
}

Your Environment
Windows 10
OpenJDK Runtime Environment AdoptOpenJDK-16.0.1+9 (build 16.0.1+9)
Gradle 7.2, but I also tried 6.9.1 and 6.6.1 which all seem to have the same issue wrt duplicating the compilerArgs

Ok, it appears the "workaround" does in fact work and the problem is that a different JAR is on the module path as well that exports the same package. Still, the debug output with the duplicate --module-path is not helping the analysis. The issue is still that I would like to avoid this manual --module-path override but I guess this is covered by https://github.com/gradle/gradle/issues/12630


Add method to retrieve a column name from a string

Hi, thank you for this awesome library!
I added the possibility of validating column names at runtime to TableColumns (useful for example when you want to sort on a column that's unknown at compile time).
One thing that I'm not so sure about is that in order to be able to transform the class field name to the column name, I needed to move the transform function into the TableColumns class.
Let me know what you think!

Thanks for the PR @francesconero


Gh 53 config management

First attempt at this. Config service is a rest service. Uses cache service as its store. Clients and palisade services can request config. Some example code is still dependent on some bootstrap code which can be removed once gh-28 is resolved and merged.

And the first thing I should mention is that I based this off the changes for gh-28, so there's quite a bit of stuff from that branch that has been pulled in relating to properties-backing-store and etcd-backing-store. Sorry!

Closed


can't apply dynatrace_request_attribute due to argument_index = 0

Hi, while trying to apply the following resource with argument_index = 0 I got the error below.
Please, let me know if anymore info is necessary.
resource dynatrace_request_attribute "request_attribute" {
  name = "xyz-tf"
  enabled = true
  data_type = "STRING"
  normalization = "ORIGINAL"
  aggregation = "FIRST"
  data_sources {
    enabled = true
    source = "METHOD_PARAM"
    technology = "PHP"
    value_processing {
      value_extractor_regex = "xyz:(.*+)"
      value_condition {
        operator = "BEGINS_WITH"
        value = "xyz:"
      }
    }
    methods {
      capture = "ARGUMENT"
      argument_index = 0  #<--------------------
      method {
        visibility = "PUBLIC"
        class_name = "xyz"
        file_name = "xyz.php"
        file_name_matcher = "EQUALS"
        method_name = "setAttribute"
        return_type = ""
      }
    }
    scope {
      service_technology = "PHP_FPM"
    }
  }
}

Error
Error: {
  "code": 400,
  "message": "Constraints violated.",
  "constraintViolations": [
    {
      "parameterLocation": "PAYLOAD_BODY",
      "location": "",
      "message": "The argumentIndex is required if type is \"ARGUMENT\", and must not be specified otherwise.",
      "path": "dataSources[0].methods[0].argumentIndex"
    }
  ]
}

Environment
Terraform version:
[root@devops terraform-workspaces]# terraform --version
Terraform v0.14.11

Your version of Terraform is out of date! The latest version
is 1.1.5. You can update by downloading from https://www.terraform.io/downloads.html

dynatrace-oss/dynatrace version: 1.9.1
Thanks in advance,
Jeferson

Hi Jefferson,
I've identified the issue and fixed it locally. The next release will contain this fix.

Good news - release v1.10.0 takes care of this issue. Thank you for your patience!


Enhancement: allow one-line class member definition

Make sure these boxes are checked before submitting your issue - thank you!
(If your issue is neither a both bug nor a request, please write in a free style)

[x] https://esdoc.org/manual/usage/feature.html
[x] https://esdoc.org/manual/configuration/config.html
[x] https://esdoc.org/manual/usage/tags.html
[x] https://esdoc.org/manual/advanced/api.html
[x] https://esdoc.org/manual/faq/faq.html

Short summary of your issue
Currently class members must be defined with at least two lines:
/** public prop
    @type {number}
    */
    this.pub = value;

Would be nice if one-line definitions are allowed too
/** @type {number} - public prop */
    this.pub = value;

Moreover, docs already state it is possible: https://esdoc.org/manual/usage/tags.html#for-member-and-variable => #type-syntax
Your environment

ESDoc version: https://try.esdoc.org

unfortunately, the docs (no longer?) state that it is possible. But it would be very useful, indeed !


Can Fastembed have pure rust or c++versions

no python  no  pain

There are some community efforts https://github.com/Anush008/fastembed-rs

thx

I believe this has been addressed. Thanks for the Rust port @Anush008


fix hookRecalledMsgProcess reference exception

chatFactory context was not passed into oldRecalledMsgProcess, so the exception is thrown in the original function.

@huan by merging this PR, a recalled message will trigger the 'message' event with the same type and content of original message.
i.e.

the client sends 'test'
wechaty trigger: 'message' => { text: test, type: text }
the client recalls 'test'
wechaty trigger 'message' => { text: test, type: text } again

Could you please only try {} catch () {} the oldRecalledMsgProcess.call(chatFactory, msg) instead of the whole code block?
After that, I'll merge it and let's begin discussing how to design and implement the RECALL behavior.

Done. Changed try/catch block scope and change the log message.

Awesome, thank you very much for the contribution!


Consider converting this to a ESP Easy plugin?

Hi,
I think your project is great but it would be even greater (I think) if it was part of the ESP Easy community. Would you consider converting this to a ESP Easy plugin?
https://github.com/letscontrolit/ESPEasy

Hi @Grovkillen,
Thanks for your request. Feel free to contribute to this project and create such plugin. I haven't personally the time to maintain this firmware and/or to add new functionalities.
Regards,
Sam

Thanks for the time you have put into this, I will take it to the devs at ESP Easy and see if they feel the same as I do.


Fixed the issue when successfulJobsHistoryLimit and failedJobsHistoryLimit variables are 0.

Fixed the issue that template rendering failed when the values of successfulJobsHistoryLimit and failedJobsHistoryLimit variables are 0.

/ok-to-test

/ok-to-test

/approve
/lgtm


Obtain RethinkDB GPG key directly from https://download.rethinkdb.com/apt/pubkey.gpg

As explained in https://rethinkdb.com/docs/install/ubuntu/:

If you followed the above instructions before July 2017 and want to
upgrade to a newer version of RethinkDB, you will need to first
download the new key (0742918E5C8DA04A)

Tested here: https://staging.travis-ci.org/BanzaiMan/travis_staging_test/builds/607101#L416


fix: avoid overriding role if already exists in bootstrap

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 4 (0.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.02%) to 50.275%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

internal/bootstrap/service.go
0
4
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.02%

Covered Lines:
5768

Relevant Lines:
11473

💛  - Coveralls


Update readme with links to individual READMEs per package

Fixes #187
Related to https://github.com/openwhisk/openwhisk/issues/1848

We need to update the documentation on installing the openwhisk-catalog.  @rabbah recently updated the installCatalog.sh file to ignore the catalog_namespace parameter.

@jasonpet

We need to update the documentation on installing the openwhisk-catalog. @rabbah recently updated the installCatalog.sh file to ignore the catalog_namespace parameter.

This 3rd parameter no longer need it and can remove from readme?

@csantanapr - correct. it can be removed.

@jasonpet

I move out websocket in bb2915a23f329ca436159df07b4409e22cd98020
Updated installCatalog.sh info d3661537e7535883386e1d02d36e4cbf78d30376