assert len(indices) == len(self), f"{indices} not equal {len(self)} while offset is: {offset}"

When I use my custom data, raise error: "assert len(indices) == len(self), f"{indices} not equal {len(self)} while offset is: {offset}""
then I print the length info,  =====len of indices is 29336 - offset: 0 - len self 58640
below is the detail error info, Please help me.
Traceback (most recent call last):
File "tools/train.py", line 198, in
main()
File "tools/train.py", line 193, in main
meta=meta,
File "/home/swap/project/SoftTeacher/ssod/apis/train.py", line 205, in train_detector
runner.run(data_loaders, cfg.workflow)
File "/opt/conda/lib/python3.7/site-packages/mmcv/runner/iter_based_runner.py", line 117, in run
iter_loaders = [IterLoader(x) for x in data_loaders]
File "/opt/conda/lib/python3.7/site-packages/mmcv/runner/iter_based_runner.py", line 117, in
iter_loaders = [IterLoader(x) for x in data_loaders]
File "/opt/conda/lib/python3.7/site-packages/mmcv/runner/iter_based_runner.py", line 23, in init
self.iter_loader = iter(self._dataloader)
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 291, in iter
return _MultiProcessingDataLoaderIter(self)
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 764, in init
self._try_put_index()
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 994, in _try_put_index
index = self._next_index()
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 357, in _next_index
return next(self._sampler_iter)  # may raise StopIteration
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/sampler.py", line 208, in iter
for idx in self.sampler:
File "/home/swap/project/SoftTeacher/ssod/datasets/samplers/semi_sampler.py", line 186, in iter
assert len(indices) == len(self), f"{indices} not equal {len(self)} while offset is: {offset}"

When I use my custom data, raise error: "assert len(indices) == len(self), f"{indices} not equal {len(self)} while offset is: {offset}""
then I print the length info, =====len of indices is 29336 - offset: 0 - len self 58640
below is the detail error info, Please help me.
Traceback (most recent call last):
File "tools/train.py", line 198, in
main()
File "tools/train.py", line 193, in main
meta=meta,
File "/home/swap/project/SoftTeacher/ssod/apis/train.py", line 205, in train_detector
runner.run(data_loaders, cfg.workflow)
File "/opt/conda/lib/python3.7/site-packages/mmcv/runner/iter_based_runner.py", line 117, in run
iter_loaders = [IterLoader(x) for x in data_loaders]
File "/opt/conda/lib/python3.7/site-packages/mmcv/runner/iter_based_runner.py", line 117, in
iter_loaders = [IterLoader(x) for x in data_loaders]
File "/opt/conda/lib/python3.7/site-packages/mmcv/runner/iter_based_runner.py", line 23, in init
self.iter_loader = iter(self._dataloader)
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 291, in iter
return _MultiProcessingDataLoaderIter(self)
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 764, in init
self._try_put_index()
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 994, in _try_put_index
index = self._next_index()
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 357, in _next_index
return next(self._sampler_iter) # may raise StopIteration
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/sampler.py", line 208, in iter
for idx in self.sampler:
File "/home/swap/project/SoftTeacher/ssod/datasets/samplers/semi_sampler.py", line 186, in iter
assert len(indices) == len(self), f"{indices} not equal {len(self)} while offset is: {offset}"

Could you post more information like GPU numbers, dataset size? It will be helpful for us to debug it.

When I use my custom data, raise error: "assert len(indices) == len(self), f"{indices} not equal {len(self)} while offset is: {offset}""
then I print the length info, =====len of indices is 29336 - offset: 0 - len self 58640
below is the detail error info, Please help me.
Traceback (most recent call last):
File "tools/train.py", line 198, in
main()
File "tools/train.py", line 193, in main
meta=meta,
File "/home/swap/project/SoftTeacher/ssod/apis/train.py", line 205, in train_detector
runner.run(data_loaders, cfg.workflow)
File "/opt/conda/lib/python3.7/site-packages/mmcv/runner/iter_based_runner.py", line 117, in run
iter_loaders = [IterLoader(x) for x in data_loaders]
File "/opt/conda/lib/python3.7/site-packages/mmcv/runner/iter_based_runner.py", line 117, in
iter_loaders = [IterLoader(x) for x in data_loaders]
File "/opt/conda/lib/python3.7/site-packages/mmcv/runner/iter_based_runner.py", line 23, in init
self.iter_loader = iter(self._dataloader)
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 291, in iter
return _MultiProcessingDataLoaderIter(self)
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 764, in init
self._try_put_index()
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 994, in _try_put_index
index = self._next_index()
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 357, in _next_index
return next(self._sampler_iter) # may raise StopIteration
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/sampler.py", line 208, in iter
for idx in self.sampler:
File "/home/swap/project/SoftTeacher/ssod/datasets/samplers/semi_sampler.py", line 186, in iter
assert len(indices) == len(self), f"{indices} not equal {len(self)} while offset is: {offset}"

Could you post more information like GPU numbers, dataset size? It will be helpful for us to debug it.

Thank you for your attention.
Below is my information:
GPU:   GeForce RTX 3070,      CUDA:  cuda_11.2.r11.2/compiler.29558016_0,    Driver Version:    460.91.03,    Pytorch: 1.9
Dataset infomation:
labeled train imgs: 1798,     labeled val imgs: 201,    unlabeled imgs:  7000

When I use my custom data, raise error: "assert len(indices) == len(self), f"{indices} not equal {len(self)} while offset is: {offset}""
then I print the length info, =====len of indices is 29336 - offset: 0 - len self 58640
below is the detail error info, Please help me.
Traceback (most recent call last):
File "tools/train.py", line 198, in
main()
File "tools/train.py", line 193, in main
meta=meta,
File "/home/swap/project/SoftTeacher/ssod/apis/train.py", line 205, in train_detector
runner.run(data_loaders, cfg.workflow)
File "/opt/conda/lib/python3.7/site-packages/mmcv/runner/iter_based_runner.py", line 117, in run
iter_loaders = [IterLoader(x) for x in data_loaders]
File "/opt/conda/lib/python3.7/site-packages/mmcv/runner/iter_based_runner.py", line 117, in
iter_loaders = [IterLoader(x) for x in data_loaders]
File "/opt/conda/lib/python3.7/site-packages/mmcv/runner/iter_based_runner.py", line 23, in init
self.iter_loader = iter(self._dataloader)
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 291, in iter
return _MultiProcessingDataLoaderIter(self)
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 764, in init
self._try_put_index()
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 994, in _try_put_index
index = self._next_index()
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 357, in _next_index
return next(self._sampler_iter) # may raise StopIteration
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/sampler.py", line 208, in iter
for idx in self.sampler:
File "/home/swap/project/SoftTeacher/ssod/datasets/samplers/semi_sampler.py", line 186, in iter
assert len(indices) == len(self), f"{indices} not equal {len(self)} while offset is: {offset}"

Could you post more information like GPU numbers, dataset size? It will be helpful for us to debug it.

Thank you for your attention.
Below is my information:
GPU: GeForce RTX 3070, CUDA: cuda_11.2.r11.2/compiler.29558016_0, Driver Version: 460.91.03, Pytorch: 1.9
Dataset infomation:
labeled train imgs: 1798, labeled val imgs: 201, unlabeled imgs: 7000
Custom config infomation(soft_teacher_faster_rcnn_r50_caffe_fpn_custom_full.py):
base="base.py"
data = dict(
samples_per_gpu=8,
workers_per_gpu=8,
train=dict(
    sup=dict(

        ann_file="data/coco/annotations/instances_train2017.json",
        img_prefix="data/coco/train2017/",

    ),
    unsup=dict(

        ann_file="data/coco/annotations/instances_unlabeled2017.json",
        img_prefix="data/coco/unlabeled2017/",

    ),
),
sampler=dict(
    train=dict(
        sample_ratio=[1, 1],
    )
),

)
semi_wrapper = dict(
train_cfg=dict(
unsup_weight=2.0,
)
)
lr_config = dict(step=[2400 * 4, 3200 * 4])
runner = dict(delete=True, type="IterBasedRunner", max_iters=3600 * 4)

When I use my custom data, raise error: "assert len(indices) == len(self), f"{indices} not equal {len(self)} while offset is: {offset}""
then I print the length info, =====len of indices is 29336 - offset: 0 - len self 58640
below is the detail error info, Please help me.
Traceback (most recent call last):
File "tools/train.py", line 198, in
main()
File "tools/train.py", line 193, in main
meta=meta,
File "/home/swap/project/SoftTeacher/ssod/apis/train.py", line 205, in train_detector
runner.run(data_loaders, cfg.workflow)
File "/opt/conda/lib/python3.7/site-packages/mmcv/runner/iter_based_runner.py", line 117, in run
iter_loaders = [IterLoader(x) for x in data_loaders]
File "/opt/conda/lib/python3.7/site-packages/mmcv/runner/iter_based_runner.py", line 117, in
iter_loaders = [IterLoader(x) for x in data_loaders]
File "/opt/conda/lib/python3.7/site-packages/mmcv/runner/iter_based_runner.py", line 23, in init
self.iter_loader = iter(self._dataloader)
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 291, in iter
return _MultiProcessingDataLoaderIter(self)
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 764, in init
self._try_put_index()
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 994, in _try_put_index
index = self._next_index()
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 357, in _next_index
return next(self._sampler_iter) # may raise StopIteration
File "/opt/conda/lib/python3.7/site-packages/torch/utils/data/sampler.py", line 208, in iter
for idx in self.sampler:
File "/home/swap/project/SoftTeacher/ssod/datasets/samplers/semi_sampler.py", line 186, in iter
assert len(indices) == len(self), f"{indices} not equal {len(self)} while offset is: {offset}"

Could you post more information like GPU numbers, dataset size? It will be helpful for us to debug it.

I fixed this problem by configuring the development environment.  Thank you all the same

hello, how did you solve the bug, and now I have the same bug


Increase open file limit for nginx

This allows nginx to open more than 1024 concurrent connections.
Resolves #2779.

Demo looks good.


Attempt to fix dependabot's detection of our GitHub Actions

Is there really no way to test all these dependabot changes other than merging them in?

Well, let's try this action. I'm just trying not to spend too much time on it, hoping that the examples that I find are good enough.


utoipa_swagger_ui: doesn't work with warp

What is the recommended way to add swagger ui to arp framework? If there is any?
I tried to use it like that (https://github.com/juhaku/utoipa/blob/6e3cb4b9be5072108e999b982b17ffae117d65ac/examples/todo-axum/src/main.rs#L52) but it is not type compatible.
 |
36 |       .merge(SwaggerUi::new("/swagger-ui/*tail").url("/api-doc/openapi.json", ApiDoc::openapi()))
   |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `axum::Router`, found struct `SwaggerUi`

Yeah that syntax is the new syntax coming in version 2.0.0 once released. In 1.1.0 release the syntax is bit more complicated similar to the existing for tide and warp framework. To see how it works one need to go back in time to see the example in that point of the releases. See here 1.1.0 example https://github.com/juhaku/utoipa/blob/utoipa-1.1.0/examples/todo-axum/src/main.rs.

thanks for explaining!
I currently forked the main to be able to make the same as written in your examples, but would be waiting for the release!


Add note about git-lfs to README

Add note about git-lfs to Developer section of README. This might've helped with #354.

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

@jtbandes @foxymiles I think CI is failing here because the PR is from an external contributor rather than repository collaborator and this does not have access to repository secrets. The TestPyPi step fails without access to the secret. Do we want to keep that as a part of the CI for python or only run it on main once merged?

Another option is to do something like this and only run the TestPyPI step if the head repo is the upstream repo (not a fork). That would not catch any breakages to the TestPyPI step on PRs from forks (probably rarely/never something we would need to worry about), but it would otherwise allow us to pass CI on PRs from forks.

What do you think we should do here? I'd like to merge this and also make it easy for others to contribute PRs for merging. Right now the CI is preventing that.

@defunctzombie This should be fixed by https://github.com/foxglove/mcap/pull/358


Fix unbalanced quotes in error message

@jcoyne are you (and/or current clients) actively using this library? Should it move to Hydra Labs?

@no-reply yes, we're using it for UCSB. I think moving it to projecthydra-labs is a great idea.


Discord_rpc not downloading

Describe your problem here.
I tried using the source code following the steps correctly, but when i tried the "haxelib run hmm install" it was not downloading the discord rpc and it says: command "haxelib --never git discord_rpc https://github.com/Aidan63/linc_discord-rpc master", and do not download
Are you modding a build from source or with Lua?
Source
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
No, i was still compiling

ok, i just realized the haxelib folder do not have the discord rpc


ux update

First update to the UX of the tool

Running the binary (“depstat”) directly prints help (available options).
“help” sub command prints help.
“list” subcommand lists all dependencies
“cycles” subcommand prints all the cycles in the dependencies
“stats”  subcommand prints the metrics: total number of dependencies, max depth of dependencies, number of transitive dependencies.
a. “-v” verbose flag : lists all dependencies and the longest dependency chain
b. “--file” : produces a JSON file having the metrics at the specified location, if no location specified then the file is created in the current directory

Thanks for the review @alenkacz! Made the changes, please take a look :)


[5.1][ConstraintSystem] Don't attempt dynamic member lookup on invalid base

Explanation:

If subscript(dynamicMember:) is unviable because it's either
an instance method referenced on type or static method
referenced on an instance of type, attempting dynamic
member lookup would be incorrect since it's unclear
what is intended.

Issue: rdar://problem/48994658

Scope: Constraint solver in diagnostic mode.

Risk: Very Low.

Testing: Added compiler regression tests.

Reviewed by: @DougGregor

Resolves: rdar://problem/48994658
(cherry picked from commit cd07652f223782e8be9f2152915412822c5592a6)

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - 30015dc8c8f38c5a06c3713b50ab57ac18a84270

@swift-ci please test macOS platform


Add one hidden example for Labs/observers ResizeController usage

Note: For easier reviewing, I'm splitting out the labs/observers example playgrounds into isolated PRs. There will be a final PR that un-hides them.
This change adds a small hidden ResizeController example (the first demo from the labs observers talk).
View the playground example at: /playground/#sample=examples/observers-resize-controller
Add

Installed labs/observers package to lit.dev content for type checking.
Add a hidden ResizeController playground example.

Test plan
Tested manually on latest Chrome, Safari and Firefox.

Added @sorvell's feedback of changing the icon on the drawer to be an expand and contract arrow based on state.


Type resolution fails with bazel managed npm_modules

I have the following build rule:
ts_library(
    name = "client",
    srcs = glob(["control.ts", "xray_viewer.ts"]),
    tsconfig = "//:tsconfig.json",
    node_modules = "@third_party_js//:node_modules", # or "//:node_modules".
)

If I manage my node_modules myself and check it into my repo root, this build rule works. I want to move to bazel managed dependencies though, so I added
yarn_install(
    name = "third_party_js",
    package_json = "//:package.json",
    yarn_lock = "//:yarn.lock",
)

for managing my javascript dependencies and depend on the new @third_party_js//:node_modules rule. This now no longer compiles:
third_party/point_cloud_viewer/xray/client/control.ts(17,24): error TS7016: Could not find a declaration file for module 'three'. '/home/hrapp/.cache/ba
zel/_bazel_hrapp/8de0a1069de8d166c668173ca21c04ae/bazel-sandbox/7039943917462986036/execroot/com_lyft_avsoftware/external/third_party_js/node_modules/th
ree/build/three.js' implicitly has an 'any' type.

I investigated a bit. The problem in the generated tsconfig.file (Gist) is in the path setting and in the typeRoots setting.
According to https://github.com/Microsoft/TypeScript/issues/13581#issuecomment-274291670, typeRoots is not used for type resolution for modules, i.e. three in this case. It is searched when a node_modules is found in a top level directory for the files that are compiled, that is why it is found if node_modules is checked into my repository.
A possible and easy fix is to add node_modules/@types to paths - so that the type definitions are found. I proposed a fix for this in a separate PR.

/cc @pdubroy


packit srpm --no-bump produces None in Release field

packit srpm --no-bump
produces following diff:
diff --git a/fedora-license-data.spec b/fedora-license-data.spec
index 9c7b830..d062692 100644
--- a/fedora-license-data.spec
+++ b/fedora-license-data.spec
@@ -2,7 +2,7 @@

 Name:           fedora-license-data
 Version:        1.4
-Release:        1%{?dist}
+Release:        None%{?dist}
 Summary:        Fedora Linux license data

The None is an obvious error. IMO the Release field should not be changed at all.

Maybe a related to #1695


Scroll bar missing from application view

Describe the bug
Program admins are unable to view the entirety of an application within CiviForm. Previously there was a scroll bar for them to scroll and view the entire resident's application. That scroll bar is no longer there and program admins are unable to view the application beyond the first few questions.
To Reproduce
Steps to reproduce the behavior:

Log in as a Program Admin
Click on 'Applications'
Click to view 1 application
See that only the first part of the application shows and you cannot scroll to see the rest

Expected behavior
Program admins should be able to scroll to see the entire application
Screenshots
Attached
Issue_No scroll.pdf

@swatkat1 as oncall this seems like a good thing to repro and access the impact of.

This is a regression from https://github.com/civiform/civiform/pull/3191 where we incorrectly added the overflow-hidden class to the application content (thus disabling scrolling). I can put together a fix for this.

@elisekalstad Sorry about the breakage :(.

All good! No worries!
[Title: City of Seattle logo]Elise Kalstad
She/Her/Hers
City of Seattle, Innovation & Performance
206-256-5515 |<EMAIL_ADDRESS>In office: TH  | Remote: M, T, W, F
Learn more about Innovation & Performance: seattle.gov/innovation-performancehttps://www.seattle.gov/innovation-performance
From: Brett Clouser @.>
Sent: Wednesday, September 7, 2022 2:06 PM
To: civiform/civiform @.>
Cc: Kalstad, Elise @.>; Mention @.>
Subject: Re: [civiform/civiform] Scroll bar missing from application view (Issue #3362)
CAUTION: External Email
@elisekalstadhttps://protect2.fireeye.com/v1/url?k=31323334-50bba2bf-31321b84-4544474f5631-a5a11a09f8a70a2f&q=1&e=30d9e71a-e3cb-4311-a3f1-946b294c6cdd&u=https%3A%2F%2Fgithub.com%2Felisekalstad Sorry about the breakage :(.
—
Reply to this email directly, view it on GitHubhttps://protect2.fireeye.com/v1/url?k=31323334-50bba2bf-31321b84-4544474f5631-5f09ec1e5d721772&q=1&e=30d9e71a-e3cb-4311-a3f1-946b294c6cdd&u=https%3A%2F%2Fgithub.com%2Fciviform%2Fciviform%2Fissues%2F3362%23issuecomment-1239882039, or unsubscribehttps://protect2.fireeye.com/v1/url?k=31323334-50bba2bf-31321b84-4544474f5631-e7083e17f0edcafb&q=1&e=30d9e71a-e3cb-4311-a3f1-946b294c6cdd&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAUQYIY6DMZ64NHFKUUECGR3V5D7T5ANCNFSM6AAAAAAQHB7J4A.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>


Adding property to auditing endpoint

And some testing cleanups

Hi @yoavrubin, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (yrubin). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, or work for Microsoft Open Technologies, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;


New profile needed for Quanquer Smart Christmas Lights Using (CZJUTAI Tuya Wifi controller)

I found that the firmware is v1.0.8 and the board is a CB2S with a BK7231N chip.  Firmware full dump attached (mfg default WiFi/config and never connected to Tuya SmartLife app at the time of the dump).
CZJUTAI-multi-lights-FLASH.zip

Added as Quanquer CZJUTAI String Lights.  Looks like the detected device_configuration/user_primary_key is not from storage, and likely belongs to a sample light configuration that doesn't truly belong to this device.  I'm not sure if this device is regular RGB or if it is RGBIC, in which case, there will be limited 3rd party firmware support.

Added as Quanquer CZJUTAI String Lights. Looks like the detected device_configuration/user_primary_key is not from storage, and likely belongs to a sample light configuration that doesn't truly belong to this device. I'm not sure if this device is regular RGB or if it is RGBIC, in which case, there will be limited 3rd party firmware support.

I found that It is RGBIC and got more info on this site (https://cpldcpu.wordpress.com/2022/01/23/controlling-rgb-leds-with-only-the-powerlines-anatomy-of-a-christmas-light-string/) as to how the communication protocol works for the LED string.  I tested the light string and found that it is the same protocol as discussed in the above site. The circuit for the controller has a unmarked 8 pin IC (MCU?) that is controlling the power MOSFETs and sending the pulses to the LED string, so I don't think that part will be a worry since something is already generating the needed pulses.  On the CB2S, P6 is connected to a status LED, P7 is connected to the button, and P11/TX1 is connected to the unmarked IC.  Looking at the signal from the unmarked IC I think it might be I2C comms.  I'm going to try decoding it.


Feat: Adding color-rendering for kubectl diff

Description

Type of change

[ ] Bug fix (fixes an issue)
[x] New feature (added functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Chore (doesn't directly affect users, e.g refactoring or CI/CD changes)
[ ] Is a documentation update
[x] Requires further documentation updates (on https://kubecolor.github.io/)

Changes

Added thing

Motivation

Related issue (if exists)

Closes #190

closes #190

I added the needs documentation label as a reminder to also create a PR to the docs repo for the new configuration fields.
I can create that PR for you as soon as we get this merged.

This is perfect! This is exactly how I'd imagine myself implementing this.
I see your PR is marked as draft, but I couldn't resist giving it a review already.
Our config-schema.json need to be updated as well, which can be done by running:
make config-schema.json

@applejag thx for this wonderful review ❤
I've marked this PR as draft, because it lacks in tests and the PR was not final :)
@tzabbi will finalize the themes tomorrow, so I think the pr should be ready tommorow.

I added the needs documentation label as a reminder to also create a PR to the docs repo for the new configuration fields.
I can create that PR for you as soon as we get this merged.

I will add the documentation this afternoon :)

@applejag can you review again I hope I got all. Thanks for your previous review.

I will make the documentation later.

I added the needs documentation label as a reminder to also create a PR to the docs repo for the new configuration fields.
I can create that PR for you as soon as we get this merged.

which new configuration do you mean? since I removed the new parameter again I think there is noting worth to document.

Ah I see the configdoc got broken after I extracted the Color type out into its own package color.Color. Now it works. I'll push that as a separate PR.
This PR is done though.


[feat] Use GMT time in logs, like zwave-js does

We could decide to use either local or GMT time in the logs, but I think that both zwave-js and zwavejs2mqtt should use the same timezone in order to be consistent. Right now zwavejs2mqtt uses local time while zwave-js driver log uses GMT.

I get both logs in local. Have you defined the timezone in your docker compose?

I still see driver logs in UTC format and zwave-js-ui logs in the host/container timezone format.
According to this comment in an open issue, https://github.com/zwave-js/node-zwave-js/issues/4088#issuecomment-1013660735, node-zwave-js is harcoded to use UTC time. I'm not sure if that comment is technically still accurate, but the logging library being used, winston logger, sets the timezone format to UTC unless configured with a custom timestamp, which node-zwave-js does not do.

I use this timestamp: https://github.com/zwave-js/zwave-js-ui/blob/master/lib/logger.ts#L71

I still see driver logs in UTC format and zwave-js-ui logs in the host/container timezone format.
According to this comment in an open issue, zwave-js/node-zwave-js#4088 (comment), node-zwave-js is harcoded to use UTC time. I'm not sure if that comment is technically still accurate, but the logging library being used, winston logger, sets the timezone format to UTC unless configured with a custom timestamp, which node-zwave-js does not do.

Not sure what to tell you. Mine are in local time.
08:27:11.712 SERIAL » [ACK] (0x06)
08:27:11.713 DRIVER « [Node 024] [REQ] [ApplicationUpdateRequest]
payload: 0x18140410015e2585598672555a735b9f6c702c2b227a
08:27:11.716 CNTRLR « [Node 024] Received updated node info
08:27:12.960 SERIAL « 0x011a00498418140410015e2585598672555a735b9f6c702c2b227a99 (28 bytes)```

Not sure what to tell you. Mine are in local time.
08:27:11.712 SERIAL » [ACK] (0x06)
08:27:11.713 DRIVER « [Node 024] [REQ] [ApplicationUpdateRequest]
payload: 0x18140410015e2585598672555a735b9f6c702c2b227a
08:27:11.716 CNTRLR « [Node 024] Received updated node info
08:27:12.960 SERIAL « 0x011a00498418140410015e2585598672555a735b9f6c702c2b227a99 (28 bytes)```

Any chance your timezone is set to UTC, but the clock with a local time? 😅
Using any kind of custom log transport?
The winston default timestamp format uses toISOString(), as mentioned in the above issue, which uses UTC time always. Wondering how you're getting around that. 🤔 I'd be happy to have synced local timezones, but maybe easier to switch entirely to UTC...

I’m mapping in /etc/localtime and setting my time zone in the environment variable.
My system time is correct:
Mon 17 Oct 2022 10:32:31 AM EDT```

@blhoward2 Are you logging to the console, not a file?
In my testing, when console logging is enabled (file logging disabled) it uses "short" timestamps (no date), which happen to be in the local timezone.
Console logging (file logging off), uses the correct local timezone:
22:42:48.029 SERIAL » 0x011a00a9010c0e9f034c007100fafba19ff3f6b1bf240000000000fe          (28 bytes)

File logging is always UTC:
2022-10-18T05:39:32.271Z SERIAL « 0x011d00a92300000200ba7f7f7f7f01010300000000020100007f7f7f7f7faf    (31 bytes)

I just checked myself, I don't see any issue with zwave-js-ui, it respects the TZ environment variable. If you set TZ=UTC, whether you are using Docker or not, the zwave-js-ui log timestamps will be UTC time.

I just checked myself, I don't see any issue with zwave-js-ui, it respects the TZ environment variable. If you set TZ=UTC, whether you are using Docker or not, the zwave-js-ui log timestamps will be UTC time.

I think we can close this issue


Not an issue, just wondering

Just wondering if there is any DOM implementation, or does all .Net interaction have to be through JS?

If you asking about an interface like IHTMLDocument2 that is available with IE then no that's not available.

Thanks, yes I am. Great control BTW ;-)

I'm just working on a DOM for .NET access.
Are you interested in a collaboration to add a .Net DOM to this project?

Part of the problem is the underlying WebView2 control doesn't expose any interfaces that can be wrapped.

I'm wrapping .Net classes round the native JS DOM, only got some basic testing of principle done, but:
.Net
Below XPath creates a new WVElement, creates Ref[hash]=null
JS
Ref[hash] = document.evaluate...
.Net
WVElement can access methods and properties of Ref[hash]
Public Class WV2Document
	Public Web As WVBrowser

	Sub New(WebView2 As WVBrowser)
		Web = WebView2
	End Sub

	ReadOnly Property XPath(Path As String) As WV2Element
		Get
			Dim Elem = New WV2Element(Me)
			If Web.ExecuteSync($"WV2DOM.Ref[{Elem.Hash}]=document.evaluate('{Path}',document).iterateNext()") = "null" Then
				Return Nothing
			Else
				Return Elem
			End If
		End Get
	End Property


Doesn't implement all semver

When I run the following I get that output.
$ helm registry delete-package<EMAIL_ADDRESS>

usage: cnr delete-package [-h] [--output {text,none,json,yaml}]
                          [-H REGISTRY_HOST] -t MEDIA_TYPE [-v VERSION]
                          package
cnr delete-package: error: Package<EMAIL_ADDRESS>does not match format '[registry/]namespace/name[@version|:channel]'

However when I run.
$ helm registry delete-package<EMAIL_ADDRESS>usage: cnr [-h]
           {show,inspect,logout,plugins,helm,pull,list,delete-package,version,push,login,config,channel}
           ...
cnr: error: 404 Client Error: NOT FOUND for url: https://quay.io/cnr/api/v1/packages/registry-name/namespace/name/0.2.0-staging/helm
Error: plugin "registry" exited with error

The +<uuid> is how we identify which build the deploy comes from.

Thanks to report this error.
There is a typo in the regexp, it doesn't include the '+' char(https://github.com/app-registry/appr-cli/blob/master/cnrclient/utils.py#L6)
I'll push a new release shortly.

released:
https://github.com/app-registry/helm-plugin/releases/tag/v0.3.8

@ant31 does that mean this is safe to close?


Invoke Password Grant

I'm using a AuthController for my user log in. And once the user successfully logs in, I want to include the access token with the response. However, I don't know how exactly to invoke the PasswordGrantVerify class in order to get a access token.
How do I invoke that class exactly? That information is not provided in the documentation.

It's already there.
The user needs to make a request to oauth/access_token providing email, password, client_id, client_secret, & grant_type. Then, the PasswordGrantVerifier@verify will verify the user credentials, and if valid, an access token will be sent.

Thanks for helping out @OmarElGabry!

@OmarElGabry
I definitely did all this. I also checked out the documentation at thephpleague website. However, I keep getting this error:
"error": {
    "message": "Tried to access session data without an active access token",
    "status": 400,
    "debug": {
      "exception": "LucaDegasperi\\OAuth2Server\\Exceptions\\NoActiveAccessTokenException",

I am making a POST request to the /access_token route with all the data you mentioned, but nothing is happening, except the error shown above. Therefore, I think the documentation is slightly unclear at explaining on how to achieve this verification - especially for people just starting on OAuth2 like myself.

@dugajean Can you share with me the way your PasswordGrantVerify class works?

@OmarElGabry It was literally copied from the link you provided. I have been trying to follow that documentation as-is and it didn't work. My grant setup in config/oauth2.php has this:
'grant_types' => [
    'password' => [
        'class' => '\League\OAuth2\Server\Grant\PasswordGrant',
        'callback' => '\App\PasswordGrantVerifier@verify',
        'access_token_ttl' => 3600
    ]
]

And the PasswordGrantVerifier.php file is placed inside App and has the contents from the previous link as said.
I created an OAuth client in the oauth_clients table like so:
mypublic	mysecret	myClient	2016-06-30 22:22:04	2016-06-30 22:22:04

And I make the POST via Postman request like this (set in x-www-form-urlencoded):
grant_type:password
client_id:mypublic
client_secret:mysecret
scope:
username:oauer1084
password:password

NoActiveAccessTokenException  will be thrown when you try to get the current client id, but no access token is provided. So, I suspect you are calling Authorizer::getResourceOwnerId(); somewhere in the code, right?

@OmarElGabry Please see my edit above. And no, I don't use that.

I think we're experiencing a bug here. I'm trying to dump something in PasswordGrantVerifier@verify when doing my POST request and it's not showing anything, which means it's never hitting this callback.

getAccessToken() is enough to throw NoActiveAccessTokenException exception when no access token is provided.


poetry2nix: fix "invalid Git revision 'master'"

Motivation for this change
When running nix-shell after added a git dependency, it complains invalid Git revision 'master'.
I think it should always prefer resolved_reference to reference?
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

opened pr to poetry2nix's own repo.


Do not install pip dependencies at runtime for Docker installations.

This is unexpected as containers are designed to be immutable,
changes should happen in the build process.
Second, it will only work with pure python libraries as we remove
the majority of the build tools as part of the container build.
Description:
As the title states. Docker images are ideally immutable and stateless. Dependencies should be installed at build time.
Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[ ] The manifest file has all fields filled out correctly (example).
[ ] New dependencies have been added to requirements in the manifest (example).
[ ] New dependencies are only imported inside functions that use them (example).
[ ] New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

If the code does not interact with devices:

[ ] Tests have been added to verify that the new code works.

You are right, we already install all dependencies, and what's the harm in keeping this? I'm actually more in favor of not including all packages during the build process, and having Hass install on demand. This to keep the docker image smaller...

user may load custom component

You are right, we already install all dependencies, and what's the harm in keeping this? I'm actually more in favor of not including all packages during the build process, and having Hass install on demand. This to keep the docker image smaller...

I expected to be able to "patch" my container by changing the version in requirements.txt but I found out the container was installing the REQUIREMENTS version at startup, and breaking because it couldn't compile extensions (pyozw) as gcc is removed. Resulted in a broken container and an hour of debugging. If we want to keep this behavior, we need to keep the entire build toolchain installed so pip libraries with c extensions will compile.
Ultimately it's about principle of least surprise, docker images should not change themselves, the expectation is you rebuild when you want new code.

user may load custom component

How do we guarantee they load a custom component with no external dependencies?

How do we guarantee they load a custom component with no external dependencies?

That is the reason we cannot skip-pip

How do we guarantee they load a custom component with no external dependencies?

That is the reason we cannot skip-pip

I'm not sure I understand, maybe I use docker differently.
For the custom custom components I have used in the past I would change my Dockerfile in a fork and add a COPY command that added my custom component and patched requirements.txt that added my dependencies so when a new image was built dependencies are installed while gcc was available. This process is then repeatable effectively "rebasing" onto the upstream version of home assistant whenever I want with with git pull upstream master and docker build.

I never had do extend the docker image when using custom components, because the dependencies are automatically installed.
When you have dependencies that need a compile, this is another thing, and we currently build them in the build phase, but IMO, they should be moved to another way of installation.
Also, things are moving in the direction of a manifest per component and even in splitting the components from the Hass core, so we shouldn't fix this issue by disabling automatic installation of dependencies.

@loe you should create a new Dockerfile and extend from the Hass one with a FROM homeassistant/homeassistant:latest
Then you just need a docker-compose build --pull to have a new image, and you can keep your own changes in a separate git repo.

@loe

I'm not sure I understand, maybe I use docker differently.

That is not how HA works.
You should place your custom components in config/custom_components folder, HA will load them. Your config folder should be outside of container. See https://developers.home-assistant.io/docs/en/creating_component_loading.html


Compiler segfaults during configure

I keep getting weird compiler segfaults during ps2toolchain-dvp configure that I've not seen ever before:
build-all_log.txt
I'm on an updated Arch Linux with GCC 11.2.0.
Rebuilding binutils/gdb for x86_64 runs through fine here.
Any ideas?
EDIT:
A month ago this ran through w/o many problems (apart from finding python stuff, that's now gone).

I can work with the latest dev build for now.

Probably issues with gcc in arch linux.
This doesn't seem to be an issue anymore. Reopen if this is not the case


[v0.7] Remove pining of indirect dependencies

Because  core_io still depends on nightly-20210325, pining the  indirect dependencies of core_io makes this crate incompatible with a lot of crates which is on stable or nightly channel.
This PR remove the explicitly pining of  indirect dependencies to resolve above problem and keep lock file unchanged so the tests & CI could still pass

bors r+


[Task] Update CI badge

After #619, the CI badge is broken.

Now that test and quay push are separated. We should have 2 badges for test and push (i.e. basically a link to the quay image).
Something like https://github.com/quarkusio/quarkus. They have a badge for maven artifacts. We can explore an option for quay image.

@tthvo We only need to update the link from ci.yml to build-ci.yml? 🤔

Right! We also want to have the test status. That should be test-ci-push.yaml


cmd/go: "out of memory" running fuzz tests on windows-amd64-longtest

go test proxy running at GOPROXY=http://<IP_ADDRESS>:54095/mod
--- FAIL: TestScript (0.01s)
    --- FAIL: TestScript/test_fuzz_fuzztime (25.52s)
        script_test.go:260:
            # There are no seed values, so 'go test' should finish quickly. (2.215s)
            # Fuzzing should exit 0 after fuzztime, even if timeout is short. (23.078s)
            > go test -timeout=3s -fuzz=FuzzFast -fuzztime=5s
            [stdout]
            warning: starting with empty corpus
            fuzz: elapsed: 2s, execs: 0 (0/sec), new interesting: 0 (total: 0)
            fuzz: elapsed: 5s, execs: 316564 (105009/sec), new interesting: 0 (total: 0)
            runtime: VirtualAlloc of 104857600 bytes failed with errno=1455
            fatal error: out of memory
            runtime: VirtualAlloc of 104857600 bytes failed with errno=1455
            fatal error: out of memory
            runtime: failed to create new OS thread (have 42 already; errno=1455)
            fatal error: runtime.newosproc
            runtime: VirtualAlloc of 104857600 bytes failed with errno=1455
            fatal error: out of memory
            fatal error: out of memory allocating heap arena metadata
            exit status 2
            FAIL	fuzz	5.615s
            [stderr]
            go: failed to remove work dir: remove $WORK\tmp\go-build4214020448\b001\fuzz.test.exe: Access is denied.
            [exit status 1]
            FAIL: testdata\script\test_fuzz_fuzztime.txt:8: unexpected command failure

    --- FAIL: TestScript/test_fuzz_minimize_dirty_cov (34.01s)
        script_test.go:260:
            # Test that minimization doesn't use dirty coverage snapshots when it
            # is unable to actually minimize the input. We do this by checking that
            # a expected value appears in the cache. If a dirty coverage map is used
            # (i.e. the coverage map generated during the last minimization step,
            # rather than the map provided with the initial input) then this value
            # is unlikely to appear in the cache, since the map generated during
            # the last minimization step should not increase the coverage. (29.273s)
            > [short] skip
            > [!fuzz-instrumented] skip
            > env GOCACHE=$WORK/gocache
            > go test -fuzz=FuzzCovMin -fuzztime=25s -test.fuzzcachedir=$GOCACHE/fuzz
            [stdout]
            warning: starting with empty corpus
            fuzz: elapsed: 0s, execs: 0 (0/sec), new interesting: 0 (total: 0)
            fuzz: elapsed: 3s, execs: 628152 (209180/sec), new interesting: 6 (total: 6)
            fuzz: elapsed: 6s, execs: 1371740 (248104/sec), new interesting: 6 (total: 6)
            fuzz: elapsed: 9s, execs: 1985965 (203944/sec), new interesting: 6 (total: 6)
            runtime: VirtualAlloc of 24576 bytes failed with errno=1455
            fatal error: out of memory
…
    --- FAIL: TestScript/test_fuzz_dup_cache (33.71s)
        script_test.go:260:
            # This test checks that cached corpus loading properly handles duplicate entries (this can
            # happen when a f.Add value has a duplicate entry in the cached corpus.) Duplicate entries
            # should be discarded, and the rest of the cache should be loaded as normal. (29.547s)
            > env GOCACHE=$WORK/cache
            > env GODEBUG=fuzzdebug=1
            > mkdir -p $GOCACHE/fuzz/fuzztest/FuzzTarget
            > go run ./populate $GOCACHE/fuzz/fuzztest/FuzzTarget
            > go test -fuzz=FuzzTarget -fuzztime=10x .
            [stdout]
            FAIL	fuzztest [build failed]
            [stderr]
            # go/token
            runtime: VirtualAlloc of 32768 bytes failed with errno=1455
            fatal error: out of memory
…

greplogs -l -e 'FAIL: TestScript/test_fuzz.*\n(\s+.*)*fatal error: out of memory'
2022-05-05T01:32:18-b922055/windows-amd64-longtest
I wonder if the fuzz tests might actually be using too much memory — they might be more memory-intensive than most of the other tests by virtue of running the fuzzer.
On the other hand, these tests were also running for a long time. Maybe there's something wrong with the fuzzer that is causing them to be much more expensive than expected? (attn @golang/fuzzing)

Marking as release-blocker for Go 1.19 because this looks to me like a pretty serious problem with either the tests or the fuzzing engine.

test_fuzz_minimize_dirty_cov intentionally fuzzes for 25s, which seems excessive for coverage-guided fuzzing to minimize a trivial input.
test_fuzz_dup_cache ran for ~30s before it crashed in cmd/compile.
test_fuzz_fuzztime was running for 25s before it failed, although it only fuzzed for ~5½ seconds. That suggests to me that it (and likely test_fuzz_dup_cache too) was slowed down by the other test(s).

Suspect this is just because test_fuzz_minimize_dirty_cov was a bit overly aggressive in it's runtime, and was consuming a bit too much memory. CL 393660 reduces memory consumption a bit, but also fuzzing just uses a lot of memory for reasons.

Let's give that a try, then — if it's still a problem after that, we could consider some other options that trade off wall-time for memory footprint (like capping GOMAXPROCS to something small, or tossing in a semaphore in the fuzz-instrumented condition).


fix: increase minimum ios deployment to 12

📜 Description
Increase ios minimum deployment to 12
💡 Motivation and Context
When new arch is enabled xcode will complain with the following error in the latest RN version 0.75.3:
error: 'value' is unavailable: introduced in iOS 12.0

📢 Changelog
iOS

Increase ios minimum deployment to 12

🤔 How Has This Been Tested?
Run pod install and build again in xcode.
📝 Checklist

[ ] CI successfully passed
[ ] I added new mocks and corresponding unit-tests if library API was changed

@matinzd hm, interesting! I'm using RN 0.75.2 and in Fabric example I haven't seen such errors 🤔
Do you experience similar issues with other libraries, such as react-native-screens/react-native-gesture-handler? They are also using minimal supported 11 iOS version 🤔
Can you maybe share full stack trace? Where this .value come from? On top of my head I've seen this when I had Flipper enabled...

It's weird. I cannot find it anymore after increasing the minimum deployment. I will go back to 11 to see if I can reproduce it.

I got the same issue with RN version 0.75.3

@t4ngth00 do you use flipper? 👀
What I'm currently trying to understand os why it fails if I don't use any platform dependent code? I have some conditional compilable code (like use new API for iOS 13 and use stub for older versions), but can such checks really lead to compilation errors? 🤔
@t4ngth00 would you mind to share a stacktrace of the compilation error? I.e. which exactly file triggers the error?

do you use flipper?

No I don't

would you mind to share a stacktrace of the compilation error? I.e. which exactly file triggers the error?

I'm sorry that I have just gone for vacation and will be back next week. But you can simply reproduce the issue by upgrade react native 0.75.3 and compile with Xcode.

@t4ngth00 I updated RN to 0.75.3 in example app but I haven't seen mentioned problems 🤔 PR for a reference: https://github.com/kirillzyusko/react-native-keyboard-controller/pull/586

@t4ngth00 I updated RN to 0.75.3 in example app but I haven't seen mentioned problems 🤔 PR for a reference: #586

What xcode are you using?

Very weird I cannot reproduce it anymore. Can you try it in a clean environment with new arch turned on?

Which version of xcode are you using?

Version 15.4 (15F31d). Which version do you use?

Very weird I cannot reproduce it anymore. Can you try it in a clean environment with new arch turned on?

Yeah, I'll try to create a new example app and see if I can reproduce it there 👀

Version 15.4 (15F31d). Which version do you use?

Same here :D (15F31d)

I am gonna close this. It was a very random thing. It seems like the min deployment was not being properly applied in pod install.

Okay @matinzd
Thank you for the contribution anyway. If you discover this problem again and it'll be always reproducible feel free to open a new/re-open this PR and provide some more details 😊


Removed indent from sidebar items

I need a second opinion on this one -- does this look better or worse? You can compare the sidebar on the current site to the demo:
https://docs.dea.ga.gov.au/data/
https://deploy-preview-119--dea-docs.netlify.app/data/

I think an improvement, maybe?


Using dependency injection to get SQLAlchemy session can lead to deadlock

First check

[x] I added a very descriptive title to this issue.
[x] I used the GitHub search to find a similar issue and didn't find it.
[x] I searched the FastAPI documentation, with the integrated search.
[x] I already searched in Google "How to X in FastAPI" and didn't find any information.
[x] I already read and followed all the tutorial in the docs and didn't find an answer.
[x] I already checked if it is not related to FastAPI but to Pydantic.
[x] I already checked if it is not related to FastAPI but to Swagger UI.
[x] I already checked if it is not related to FastAPI but to ReDoc.
[x] After submitting this, I commit to one of:

Read open issues with questions until I find 2 issues where I can help someone and add a comment to help there.
I already hit the "watch" button in this repository to receive notifications and I commit to help at least 2 people that ask questions in the future.
Implement a Pull Request for a confirmed bug.

I've noticed that when using dependency injection with SQLAlchemy, a large number of concurrent requests can leave the app in a deadlocked state. This is especially noticeable with a small SQLAlchemy connection pool size (relative to the FastAPI thread pool size). Below is a self-contained example (you might have to tweak the pool size and the request body's sleep length but this should be a good starting point).

View app.py
"""
Setup: pip install fastapi sqlalchemy uvicorn
Run: python app.py
"""
import time
import uvicorn

from fastapi import Depends, FastAPI, Request
from sqlalchemy import create_engine
from sqlalchemy.orm import Session, sessionmaker
from sqlalchemy.pool import QueuePool

# SQLAlchemy setup
engine = create_engine(
    'sqlite:///test.db',
    connect_args={'check_same_thread': False},
    poolclass=QueuePool,
    pool_size=4,
    max_overflow=0,
    pool_timeout=None,  # Wait forever for a connection
)
SessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine)

# FastAPI
app = FastAPI()

def get_db(request: Request):
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

@app.get('/')
def index(db: Session = Depends(get_db)):
    # Some blocking work
    _ = db.execute('select 1')
    time.sleep(1)
    return {'hello': 'world'}

# Run
if __name__ == '__main__':
    uvicorn.run('app:app', reload=True, host='<IP_ADDRESS>', port=80)

When running the above with 100 concurrent requests (I used locust), I noticed that only around 5 requests are served, and then the app freezes and is unable to serve any more requests. Below is the locustfile.

View locustfile.py
"""
Setup: pip install locust
Run: Save as locustfile.py and run locust in terminal. Open http://localhost:8089 and run with 100, 100, http://localhost.
"""
from locust import HttpUser, task

class User(HttpUser):
    @task
    def index(self):
        self.client.get("/")

I suspect the following is happening. (Note that SessionLocal() is lazy, so db = SessionLocal() will return immediately even if no connections are available.)

The first N requests come in (where N >= thread pool size). Their get_db dependencies run and yield, and we start executing their path operation functions. At this point, the entire thread pool is full. Only pool_size (4) requests are able to get a connection, and the remaining requests wait (in their path operation functions).
The path operation functions that were able to get a connection return, opening up pool_size (4) spots in the thread pool. Because dependencies and requests run in separate threads, the finally blocks for these requests' get_db dependencies have not run yet, so the connections for these requests have not returned to the SQLAlchemy pool.
More requests come in, and like step 1, their get_db dependencies run, and we start executing their path operation functions. No connections have returned to the SQLAlchemy pool, so these requests wait. At this point, the entire thread pool is full, and every thread is waiting for a connection.
For the requests that finished in step 2, we try to schedule the finally blocks for their get_db dependencies in a new thread so we can free the connections, but all of the threads are busy, so we end up waiting.
None of the threads will ever finish because they are waiting for a connection, and no connections will be released because the thread pool is full, leaving the app in a deadlocked state.

This doesn't really seem like a bug in FastAPI or in SQLAlchemy, but it suggests that we should not use dependency injection like this when using synchronous database libraries. The only workaround I've found for this is to use a context manager to handle the session in the endpoint itself instead of injecting the database session directly.
Another thing I've noticed is that changing get_db to be an async function prevents deadlock (as does using the middleware approach), but only if the endpoint does not have a response_model. If it has a response_model then the app will still lock up. I believe this is because if response_model is defined, then when we run serialize_response, field will be non-None, and we will attempt to run field.validate in a separate thread. If the thread pool is full with requests waiting for connections, we won't be able to serialize the response and won't be able to close the database connection. Maybe we could serialize the response in the same thread as the path operation function; I'm not sure what the benefit of serializing in a separate thread is.
There is similar discussion in https://github.com/tiangolo/full-stack-fastapi-postgresql/issues/104 and many others came to the conclusion that using a context manager is the right approach, but nothing really came of it. If others can validate that my suspicion is correct, then maybe we should change the docs to recommend using a context manager within the endpoint itself until a better solution is available.
Environment

OS: macOS Big Sur (11.3)
FastAPI Version: 0.63.0
SQLAlchemy Version: 1.4.13
Python version: 3.9.4

I'm not sure how background tasks are scheduled, but it doesn't look like that would always prevent the above situation. For example, running the above app using that solution still leads to deadlock with 100 concurrent users.
Another possible solution is to keep get_db() as-is, and change all endpoints to something like:
@app.get('/')
def index(db: Session = Depends(get_db)):
    with close_at_end(db) as db:
        data = db.query(...)...
        return {"data": data}

where close_at_end is a simple context manager that yields db and closes it after. This doesn't account for sub-dependencies and is a little tedious, but it can work as a temporary workaround.
It seems like if you want to keep using dependencies, the real solution is to migrate to an async database library, and if you're already using SQLAlchemy the switch should be relatively easy with version 1.4.

Hi everyone,
During my locust test on my FastApi apis, I'm trying a 1000 users test with a 10 users spawn rate and after a moment, I have a QueuePool limit error.
First I increase my create_engine configuration (my SQL Database allows 75 different connections) :
engine = create_engine(     SQLALCHEMY_DATABASE_URL,     pool_recycle=3600,     pool_size=16,     max_overflow=48 )
But the problem persists. After a lot of investigation, I find this topic : https://github.com/tiangolo/full-stack-fastapi-postgresql/issues/104#issuecomment-586466934 (the same as @Blue9 ). And I just remove the Depends as recommanded by the following Session Manager :
`@contextmanager
def get_db():
session = SessionLocal()
try:
yield session
finally:
session.close()
@app.get("/users/get-mail/{mail}", response_model=schemas.User)
def check_user_by_email(mail: str):
with get_db() as db:
db_user = crud.get_user_by_email(db, email=mail)
return db_user
`
I think there is a critical problem with de Depends and I think that @tiangolo needs to investigate this problem too because in their documentation, they advise to use Depends, but Depends is not ready for a production use ! Thanks to the community for the Session Manager solution that saves my production deployment !

We're seeing this issue too.
I'm working on going in and figuring out the bug, but @Blue9 seems to be correct in the problem stemming from the operation code being run in a different thread than the dependency seems to be the locus.
Temporary work arounds are to use a context manager, or use an async function with sqlalchemy.ext.asyncio, both of which ensure it all happens in the same thread. But you do not have to do both.
I would highly suggest to the FastAPI maintainers that they add a note in the documentation and on https://github.com/tiangolo/full-stack-fastapi-postgresql that there is a potential issue, as right now it is not production ready for a load greater than 30 or so concurrent users.

We have this same issue when making use of a resource pool which acquires a resource in a generator.
The example below illustrates the issue, this can be run using apache bench to simulate some actvity.
ab -n 100 -c 20 http://localhost:8000/test

import itertools
import asyncio
from concurrent.futures import ThreadPoolExecutor
from queue import Queue
from threading import currentThread

from fastapi.applications import FastAPI
from fastapi import Depends, Request

app = FastAPI()
pool: Queue[int] = Queue()

counter = itertools.count()

def get_data():
    trace_id = next(counter)
    ct = currentThread()
    print(f"get trace-id-{trace_id}", ct.name, ct.native_id)

    value = pool.get()
    yield value

    print(f"got trace-id-{trace_id}", ct.name, ct.native_id)
    pool.put_nowait(value)
    print(f"release trace-id-{trace_id}", ct.name, ct.native_id)

@app.get("/test")
def index(
    req: Request,
    data: dict[str, str] = Depends(get_data),
) -> dict:
    return data

@app.on_event("startup")
def on_startup() -> None:
    pool.put_nowait(1)
    pool.put_nowait(2)

    loop = asyncio.get_running_loop()
    executor = ThreadPoolExecutor(1)
    loop.set_default_executor(executor)

From the output in the logs it seems like the same thread is acquiring resources from the pool and creating a deadlock. This seems to be caused by the cm = contextmanager_in_threadpool(contextmanager(call)(**sub_values)) call in solve_generator. If we decorate our dependency function with @contextlib.contextmanager the issue does not occur.
get - resource trace-0 ThreadPoolExecutor-0_0 13479
got - resource trace-0 ThreadPoolExecutor-0_0
release - resource trace-0 ThreadPoolExecutor-0_0 13479
get - resource trace-1 ThreadPoolExecutor-0_0 13479
get - resource trace-2 ThreadPoolExecutor-0_1 13480
got - resource trace-1 ThreadPoolExecutor-0_0
got - resource trace-2 ThreadPoolExecutor-0_1
get - resource trace-3 ThreadPoolExecutor-0_0 13479
get - resource trace-4 ThreadPoolExecutor-0_1 13480

I've just been bitten by this issue as well. I had sqlalchemy configured with a pool of 10 and no overflow, and with 11 simultaneous connections the FastAPI server deadlocks completely and doesn't serve any request.
I remove the DB dependency injection and started using the contextmanager method and now it works as it should: 10 requests are served immediately and the 11th gets handled afterwards.
@tiangolo, could you clarify why dependency injection doesn't work in this case? Could you fix the examples in the documentation so more users aren't led astray?

Hey all. I've been digging into this as well and I don't think this is a FastAPI issue per se. There are a few things going on that seem to be leading to the issue.
tl;dr Dependencies and path operations defined as functions (def only) are run in an anyio threadpool. db.execute is a blocking call, causing all the workers in the pool to block in the path operation. This prevents dependency generators from performing cleanup.
Workarounds?
The suggested workaround to use a context manager within your path operation is by far the easiest solution. You're scoping the SQLAlchemy session lifecycle within the same coroutine, guaranteeing that connections can be acquired and released within the same coroutine.
While I haven't tried it yet.... It may be worth using the SQLAlchemy 1.4 asyncio beta. Part of the core issue here is related to db.execute being a blocking call. If SQLAlchemy natively supports async operations, it may resolve the issue.
Deep dive
def get_db(request: Request):
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

^ First, it should be noted that db = SessionLocal() is a non-blocking operation. Prior to the deadlock, all N requests will be able to create a session object and yield it to the path operation.
@app.get('/')
def index(db: Session = Depends(get_db)):
    # Some blocking work
    _ = db.execute('select 1')

^ db.execute is a blocking operation. Per the SQLAlchemy docs, the session requests a connection from the connection pool once queries are issues.
In the example code above, the SQLAlchemy connection pool is of size 4. This means that 4 requests will be able to check out a connection, while (N-4) connections will block on this line waiting for a connection to become available. (Side note, it's good practice to define connection timeouts on your engine object to avoid waiting interminably for a connection. Though that alone won't solve the problem).
def get_db(request: Request):
def index(db: Session = Depends(get_db)):

^ Also keep in mind that neither the dependency function nor the path operation are defined as coroutines. Both FastAPI and Starlette seem to want everything to run asynchronously, so these functions are invoked in a threadpool. See Starlette code, FastAPI doc 1, and FastAPI doc 2 for more information.
Here is where things break. anyio manages it's own threadpool of ~40 workers, each with it's own job queue. There are (N-4) workers blocked waiting for a SQLAlchemy connection to be relinquished. The 4 path operations that secured a connection can complete. FastAPI will then attempt to invoke the __exit__ method of your dependency generator to clean up the session (which implicitly checks the connection back into the connection pool). However, the dependency generator is not a coroutine, so it's passed off to the threadpool.
And here is our deadlock. All anyio worker threads are blocked waiting for SQLAlchemy connections. The code to release the connections is blocked waiting for a worker to become available.
But what about native coroutines?
While the root issue in this case is related to the use of anyio thread pools, the deadlock can still occur when defining your path operations and dependency generators native python coroutines.
This is arguably a FastAPI issue, though I honestly haven't spent more time looking into a fix. FastAPI changes the call stack slightly when it comes to your resolve dependency. The dependency is created after middleware is invoked, but before the path operation. Though the dependency isn't cleaned up until after all middleware has finished. Here is the code that adds the dependency __exit__ function to an AsyncExitStack, which isn't cleaned up until FastAPI is finished with the request.

I've read a lot of issues about this problem, but there's one thing I can't really figure out yet.
Now we're using get_db as a context manager as it's preconized by a lot of people and it seems to work a lot better than using Depends. Now, the second problem is when you have a dependency, like "get_current_active_user".  I've tried to refactor it like this :
async def get_current_user(token: str = Depends(oauth2_scheme)) -> User:
    with get_session() as db:
        decoded_token = jwt.decode(token, SECRET_KEY, [ALGORITHM])
        user = get_user(decoded_token['login'], db)
        if not user:
            raise HTTPException(400, 'User in token does not exists')
        return user

And my route looks like this (classic) :
@playlists_router.get('/me', response_model=List[PlaylistShow], tags=['playlists'])
def get_my_playlists(current_user: User = Depends(get_current_user)):
    with get_session() as db:
        playlists = current_user.playlists
        for p in playlists:
            p.new_entries_count = len(get_new_entries_for_user(current_user.id, p.id, db))

        return playlists

I get this error :
sqlalchemy.orm.exc.DetachedInstanceError: Parent instance <User at 0x1fa8d5e2d90> is not bound to a Session; lazy load operation of attribute 'playlists' cannot proceed (Background on this error at: https://sqlalche.me/e/14/bhk3)
I've read that maybe we should do something with pydantic and .from_orm method, but what if I need to update this current user or access its attributes ? I don't want to go through the process of searching him from the DB in the new context manager.
Thanks for your time !

I've read a lot of issues about this problem, but there's one thing I can't really figure out yet.
Now we're using get_db as a context manager as it's preconized by a lot of people and it seems to work a lot better than using Depends. Now, the second problem is when you have a dependency, like "get_current_active_user". I've tried to refactor it like this :
async def get_current_user(token: str = Depends(oauth2_scheme)) -> User:
    with get_session() as db:
        decoded_token = jwt.decode(token, SECRET_KEY, [ALGORITHM])
        user = get_user(decoded_token['login'], db)
        if not user:
            raise HTTPException(400, 'User in token does not exists')
        return user

And my route looks like this (classic) :
@playlists_router.get('/me', response_model=List[PlaylistShow], tags=['playlists'])
def get_my_playlists(current_user: User = Depends(get_current_user)):
    with get_session() as db:
        playlists = current_user.playlists
        for p in playlists:
            p.new_entries_count = len(get_new_entries_for_user(current_user.id, p.id, db))

        return playlists

I get this error : sqlalchemy.orm.exc.DetachedInstanceError: Parent instance <User at 0x1fa8d5e2d90> is not bound to a Session; lazy load operation of attribute 'playlists' cannot proceed (Background on this error at: https://sqlalche.me/e/14/bhk3)
I've read that maybe we should do something with pydantic and .from_orm method, but what if I need to update this current user or access its attributes ? I don't want to go through the process of searching him from the DB in the new context manager.
Thanks for your time !

did you find a solution to this pblm ?

@OpetherMB  Unfortunately no, I decided to switch to Ormar which is an async ORM. It works very nicely now, but it required some refactoring.

I notice if we create the dependency function get_session as async function, the connection pool issue gone !
so in short,

no issue with SQLAlchemy async mode (with asyncpg) and FastAPI with async def get_session()
connection pool running out issue with SQLAlchemy sync mode (with psycopg2) and FastAPI with def get_session(). The issue could be resolved by declaring async def get_session()

@happy-toro Declaring get_session() as async with SQLAlchemy sync mode did not change the behaviour for me.
Also if it helps, I have compiled results from a list of load tests I performed with different implementations for get_db() with SQLAlchemy sync mode here: https://github.com/harsh8398/fastapi-dependency-issue.

That is some comprehensive testing right there, kudos!
Indeed, changing your dependency function to a coroutine itself (using a sync def) won’t fix it, as the call to the DB later on will be blocking, waiting for a free connection, which will never happen as the event loop is blocked by the db call. Someone explained it above in a deep dive, good read!

Can you folks try this "one quick trick" and see if it solves/is related to your issues?
import anyio
import anyio._backends._asyncio as anyio_asyncio  # change if you are using trio

app = FastAPI()

@app.on_event("startup")
def startup():
    anyio_asyncio._default_thread_limiter.set(anyio.CapacityLimiter(4096))

I'll try @adriangb

@happy-toro Declaring get_session() as async with SQLAlchemy sync mode did not change the behaviour for me.
Also if it helps, I have compiled results from a list of load tests I performed with different implementations for get_db() with SQLAlchemy sync mode here: https://github.com/harsh8398/fastapi-dependency-issue.

I've also been facing this issue on a production server, this seems like a major problem as FastAPI Dependencies with sync databases are currently causing deadlocks @tiangolo

@adriangb Thanks for the snippet, the limiter increase does seem to assist in the short term although 4096 is quite & not feasible for production.
Is there anyway to get this PR more attention for review ? your concurrency fixes seem to be a good way to resolve this.

Comment on it saying it fixed your issue (if you tested it and it did)

@adriangb Thanks for speedy response, it's very much appreciated.
I tested this open PR  with locust, 5 endpoints and 40 concurrent users and still hitting the Queuepool error:
Engine

engine = create_engine(SQLALCHEMY_DATABASE_URL, pool_recycle=600)

SessionLocal = sessionmaker(bind=engine)

deps:

def get_db() -> Generator:
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()`

Errors:

greenfields-api |   File "/usr/local/lib/python3.9/site-packages/h11/_state.py", line 251, in _fire_event_triggered_transitions
greenfields-api |     raise LocalProtocolError(
greenfields-api | h11._util.LocalProtocolError: can't handle event type ConnectionClosed when role=SERVER and state=SEND_RESPONSE
greenfields-api | ERROR:sqlalchemy.pool.impl.QueuePool:Exception during reset or similar
greenfields-api | Traceback (most recent call last):
greenfields-api |   File "/usr/src/app/./app/api/dependencies.py", line 17, in get_db
greenfields-api |     yield db
greenfields-api | GeneratorExit

raise exc.TimeoutError(\nsqlalchemy.exc.TimeoutError: QueuePool limit of size 5 overflow
10 reached, connection timed out, timeout 30.00 (Background on this error at: https://sqlalche.me/e/14/3o7r

Uvicorn command:
uvicorn app.main:app --reload --workers 1 --host <IP_ADDRESS> --port 8000
Main Packages:

https://github.com/adriangb/fastapi/archive/no-limiter-for-exit.zip
h11==0.12.0
starlette==0.19.1
anyio==3.6.1

I'm not sure what's going on with your test. Can you post the whole thing publicly in a reproducible format? These sorts of concurrency things are tricky, sometimes there's even more than one issue at play. For example, if you have a lot of clients and/or slow queries you'll still time out waiting for a database connection (even if there is no deadlock).

Thanks for the report @Blue9 and thanks everyone for the discussion! :coffee:
This was most probably solved by @adriangb in https://github.com/tiangolo/fastapi/pull/5122, released as part of FastAPI 0.82.0 :tada:
If this solves it for you, you could close the issue. :nerd_face:


Works with latest jQuery?

Does this work with the latest jQuery? If not, what version would you recommend?

@kidouchi It does work with the latest jQuery ;)


fix:  use token for codecov in ci

Pull Request type
Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build-related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Issue Number: N/A
What is the new behavior?

Does this introduce a breaking change?

[ ] Yes
[ ] No

Other information

This change is

#1922  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @nagmo-starkware and the rest of your teammates on  Graphite


CPU Usage is not accurate on windows

Analytics/Hardware/CPUInfo.cpp f32 GetCPUUsage() reports false CPU usage on windows, works good on Linux.

Also i read that Task Manager it self is not a debugging tool. my function may be reporting the right CPU usage after all. i just need to confirm...

https://stackoverflow.com/questions/42432101/why-do-visual-studio-and-task-manager-report-different-memory-usages
https://social.msdn.microsoft.com/Forums/en-US/79ce4470-47ab-403a-a415-69b9f332bc0d/vs-2017-performance-profiler-vs-task-manager?forum=vsdebug

after trying a better debugging tool Process Hacker 2 it seems to be reporting the right cpu usage.


CTDing on AMD GPU (AMD Test build v1)

The game instantly crashes to desktop on clicking confirm to matchmake/filter lobby list, with this AMD test version. Using on a 2022 ROG Zephyrus G14 model with an AMD Radeon RX 6800S dGPU. Sharp Loader <IP_ADDRESS> was installed.

[ 01:38:42.1397685 | SPL ] [AddressRepo] Restored from address record cache.
[ 01:38:42.1405607 | SPL ] [Preloader] Resolved address for __scrt_common_main_seh: 0x1427414F4
[ 01:38:42.1405767 | SPL ] [Preloader] Resolved address for WinMain: 0x1413A4C00
[ 01:38:42.1405841 | SPL ] [Preloader] Resolved address for sMhMain::ctor: 0x141AEBB00
[ 01:38:42.1410200 | SPL ] [Preloader] Initializing CLR / NativePluginFramework
[ 01:38:42.1653508 | SPL ] Loading bootstrapper from C:\Program Files (x86)\Steam\steamapps\common\Monster Hunter World\nativePC\plugins\CSharp\Loader\SharpPluginLoader.Bootstrapper.dll
[ 01:38:42.1893685 | SPL ] [Bootstrapper] Initializing SharpPluginLoader.Core
[ 01:38:42.2099364 | SPL ] [Bootstrapper] SharpPluginLoader.Core loaded
[ 01:38:42.2104196 | SPL ] [Bootstrapper] Loading System.Runtime
[ 01:38:42.2694251 | SPL ] [Bootstrapper] Loading System.Collections
[ 01:38:42.2698505 | SPL ] [Bootstrapper] Loading System.Runtime.InteropServices
[ 01:38:42.2710571 | SPL ] [Core] Retrieved Function pointers
[ 01:38:42.3134058 | SPL ] sMhMain::move: 0x141af1e90
[ 01:38:42.3135771 | SPL ] Dialog Virtual Function [3] = 0x141ec9790
[ 01:38:42.3135902 | SPL ] Dialog Virtual Function [4] = 0x1402405c0
[ 01:38:42.3135972 | SPL ] Dialog Virtual Function [5] = 0x1402406b0
[ 01:38:42.3136033 | SPL ] DisplayYesNoDialog = 0x141ae1380
[ 01:38:42.3136470 | SPL ] [Bootstrapper] Loading System.Numerics.Vectors
[ 01:38:42.3149151 | SPL ] [Bootstrapper] Loading System.Drawing.Primitives
[ 01:38:42.3162220 | SPL ] [Core] Found method SharpPluginLoader.Core.SingletonManager.GetSingletonNative in cache
[ 01:38:42.3172474 | SPL ] [Core] Uploading internal call QueueYesNoDialog
[ 01:38:42.3175204 | SPL ] [Core] Uploading internal call LoadTexture
[ 01:38:42.3175554 | SPL ] [Core] Uploading internal call UnloadTexture
[ 01:38:42.3175682 | SPL ] [Core] Uploading internal call RegisterTexture
[ 01:38:42.3175788 | SPL ] [Core] Uploading internal call LoadChunk
[ 01:38:42.3175882 | SPL ] [Core] Uploading internal call GetDefaultChunk
[ 01:38:42.3175972 | SPL ] [Core] Uploading internal call RequestChunk
[ 01:38:42.3176056 | SPL ] [Core] Uploading internal call ChunkGetFile
[ 01:38:42.3176143 | SPL ] [Core] Uploading internal call ChunkGetFolder
[ 01:38:42.3176227 | SPL ] [Core] Uploading internal call FileGetContents
[ 01:38:42.3176305 | SPL ] [Core] Uploading internal call FileGetSize
[ 01:38:42.3176391 | SPL ] [Core] Uploading internal call BeginTimeline
[ 01:38:42.3176520 | SPL ] [Core] Uploading internal call EndTimeline
[ 01:38:42.3176613 | SPL ] [Core] Uploading internal call BeginTimelineGroup
[ 01:38:42.3176703 | SPL ] [Core] Uploading internal call EndTimelineGroup
[ 01:38:42.3176791 | SPL ] [Core] Uploading internal call TimelineTrack
[ 01:38:42.3176885 | SPL ] [Core] Uploading internal call Bitfield
[ 01:38:42.3176974 | SPL ] [Core] Uploading internal call NotificationSuccess
[ 01:38:42.3177089 | SPL ] [Core] Uploading internal call NotificationError
[ 01:38:42.3177184 | SPL ] [Core] Uploading internal call NotificationWarning
[ 01:38:42.3177263 | SPL ] [Core] Uploading internal call NotificationInfo
[ 01:38:42.3177365 | SPL ] [Core] Uploading internal call Notification
[ 01:38:42.3177450 | SPL ] [Core] Uploading internal call RenderNotifications
[ 01:38:42.3177530 | SPL ] [Core] Uploading internal call GetRepositoryAddress
[ 01:38:42.3177612 | SPL ] [Core] Uploading internal call GetGameRevision
[ 01:38:42.3258798 | SPL ] [Bootstrapper] Loading System.Text.Json
[ 01:38:42.3274309 | SPL ] [Bootstrapper] Loading System.Collections.Concurrent
[ 01:38:42.3747555 | SPL ] Game revision: 421652
[ 01:38:42.3748078 | SPL ] [Core] Restoring from plugin record cache.
[ 01:38:42.3771852 | SPL ] [Bootstrapper] Loading Reloaded.Hooks
[ 01:38:42.3772815 | SPL ] [Bootstrapper] Loading Reloaded.Hooks
[ 01:38:42.3775625 | SPL ] [Bootstrapper] Loading Reloaded.Hooks
[ 01:38:42.3775795 | SPL ] [Bootstrapper] Loading Reloaded.Hooks
[ 01:38:42.3776652 | SPL ] [Bootstrapper] Loading Reloaded.Hooks
[ 01:38:42.3778184 | SPL ] [Bootstrapper] Loading Reloaded.Hooks
[ 01:38:42.3780517 | SPL ] [Bootstrapper] Loading Reloaded.Hooks
[ 01:38:42.3781163 | SPL ] [Bootstrapper] Loading Reloaded.Hooks
[ 01:38:42.3782086 | SPL ] [Bootstrapper] Loading Reloaded.Hooks
[ 01:38:42.3784233 | SPL ] [Bootstrapper] Loading Reloaded.Hooks
[ 01:38:42.3793656 | SPL ] [Bootstrapper] Loading System.Runtime
[ 01:38:42.3794449 | SPL ] [Bootstrapper] Loading Reloaded.Hooks.Definitions
[ 01:38:42.3958665 | SPL ] [Bootstrapper] Loading System.Runtime
[ 01:38:42.3975321 | SPL ] [Bootstrapper] Loading System.Runtime.InteropServices
[ 01:38:42.3981697 | SPL ] [Bootstrapper] Loading Reloaded.Memory.Buffers
[ 01:38:42.4001603 | SPL ] [Bootstrapper] Loading System.Runtime
[ 01:38:42.4011521 | SPL ] [Bootstrapper] Loading System.Linq
[ 01:38:42.4023747 | SPL ] [Bootstrapper] Loading System.Runtime
[ 01:38:42.4027803 | SPL ] [Bootstrapper] Loading Reloaded.Assembler
[ 01:38:42.4047383 | SPL ] [Bootstrapper] Loading System.Runtime
[ 01:38:42.4048645 | SPL ] [Bootstrapper] Loading System.Diagnostics.Process
[ 01:38:42.4064075 | SPL ] [Bootstrapper] Loading System.Diagnostics.Process
[ 01:38:42.4065868 | SPL ] [Bootstrapper] Loading System.Runtime.InteropServices
[ 01:38:42.4068453 | SPL ] [Bootstrapper] Loading Reloaded.Memory
[ 01:38:42.4086125 | SPL ] [Bootstrapper] Loading System.Runtime
[ 01:38:42.4087224 | SPL ] [Bootstrapper] Loading System.Diagnostics.Process
[ 01:38:42.4089484 | SPL ] [Bootstrapper] Loading System.Threading
[ 01:38:42.4090955 | SPL ] [Bootstrapper] Loading System.Collections.Concurrent
[ 01:38:42.4119580 | SPL ] [Bootstrapper] Loading System.Collections
[ 01:38:42.4127204 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.4146171 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.4150190 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.4189357 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.4315534 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.4445205 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.4452184 | SPL ] [Bootstrapper] Loading System.Linq
[ 01:38:42.4532288 | SPL ] [Bootstrapper] Loading System.Diagnostics.Process
[ 01:38:42.4534448 | SPL ] [Bootstrapper] Loading System.Runtime.CompilerServices.Unsafe
[ 01:38:42.4550064 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.4550066 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.4550173 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.4550268 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.4550054 | SPL ] [ 01:38:42.4550090 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.4550057 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.4550126 | SPL ] [kernel32.dll] Resolved Path:
[kernel32.dll] Resolved Path:
[ 01:38:42.4550150 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.4550108 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.4583929 | SPL ] [Bootstrapper] Loading System.Runtime.InteropServices
[ 01:38:42.4620792 | SPL ] [Bootstrapper] Loading System.Threading
[ 01:38:42.4624667 | SPL ] [Bootstrapper] Loading System.Runtime.InteropServices
[ 01:38:42.4640414 | SPL ] [Bootstrapper] Loading System.Collections
[ 01:38:42.4641924 | SPL ] [Bootstrapper] Loading System.Linq
[ 01:38:42.4695618 | SPL ] [Bootstrapper] Loading System.Runtime
[ 01:38:42.4832920 | SPL ] [Bootstrapper] Loading Iced
[ 01:38:42.4921869 | SPL ] [Bootstrapper] Loading netstandard
[ 01:38:42.5273448 | SPL ] [Bootstrapper] Loading System.Memory
[ 01:38:42.5287236 | SPL ] [Bootstrapper] Loading System.Collections.NonGeneric
[ 01:38:42.5542923 | SPL ] [Bootstrapper] Loading System.Runtime
[ 01:38:42.5551931 | SPL ] [Bootstrapper] Loading System.Linq
[ 01:38:42.5582851 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.5583389 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.5583690 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.5584027 | SPL ] [kernel32.dll] Resolved Path:
[ 01:38:42.5974489 | SPL ] [Matchmaking] Found SteamMatchmaking interface getter at 0x143E98558
[ 01:38:42.5975323 | SPL ] [Preloader] Initialized
[ 01:38:42.5982110 | SPL ] [Bootstrapper] Loading System.IO.FileSystem.Watcher
[ 01:38:42.6065516 | SPL ] [Bootstrapper] Loading System.Reflection.Metadata
[ 01:38:42.6096084 | SPL ] [Bootstrapper] Loading System.Threading.Thread
[ 01:38:42.6142340 | SPL ] [Bootstrapper] Loading System.Runtime.Loader
[ 01:38:42.6144335 | SPL ] [Bootstrapper] Loading System.Threading
[ 01:38:42.6171279 | SPL ] Attempting to load nativePC/plugins/CSharp\BetterMatchmaking\BetterMatchmaking.dll
[ 01:38:42.6177470 | SPL ] Creating ALC for assembly BetterMatchmaking
[ 01:38:42.6195981 | SPL ] [BetterMatchmaking, Culture=neutral, PublicKeyToken=null] Resolved Path: C:\Program Files (x86)\Steam\steamapps\common\Monster Hunter World\nativePC\plugins\CSharp\BetterMatchmaking\BetterMatchmaking.dll
[ 01:38:42.6229636 | SPL ] [System.Runtime, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a] Resolved Path:
[ 01:38:42.6230695 | SPL ] [Bootstrapper] Loading System.Runtime
[ 01:38:42.6237101 | SPL ] [SharpPluginLoader.Core, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null] Resolved Path:
[ 01:38:42.6237997 | SPL ] [System.Numerics.Vectors, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a] Resolved Path:
[ 01:38:42.6238188 | SPL ] [Bootstrapper] Loading System.Numerics.Vectors
[ 01:38:42.6246398 | SPL ] Loading plugin BetterMatchmaking
[ 01:38:42.6273118 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnPreMain
[ 01:38:42.6273712 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnWinMain
[ 01:38:42.6273981 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnUpdate
[ 01:38:42.6274117 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnSave
[ 01:38:42.6274221 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnSelectSaveSlot
[ 01:38:42.6274316 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnResourceLoad
[ 01:38:42.6274426 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnChatMessageSent
[ 01:38:42.6274513 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnQuestAccept
[ 01:38:42.6274629 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnQuestCancel
[ 01:38:42.6274717 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnQuestDepart
[ 01:38:42.6274805 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnQuestEnter
[ 01:38:42.6274892 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnQuestLeave
[ 01:38:42.6274977 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnQuestComplete
[ 01:38:42.6275063 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnQuestFail
[ 01:38:42.6275155 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnQuestReturn
[ 01:38:42.6275238 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnQuestAbandon
[ 01:38:42.6275321 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnMonsterCreate
[ 01:38:42.6275409 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnMonsterInitialized
[ 01:38:42.6275499 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnMonsterAction
[ 01:38:42.6275582 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnMonsterFlinch
[ 01:38:42.6275663 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnMonsterEnrage
[ 01:38:42.6275746 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnMonsterUnenrage
[ 01:38:42.6275847 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnMonsterDeath
[ 01:38:42.6275944 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnMonsterDestroy
[ 01:38:42.6276034 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnPlayerAction
[ 01:38:42.6276114 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnWeaponChange
[ 01:38:42.6276197 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnEntityAction
[ 01:38:42.6276281 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnEntityAnimation
[ 01:38:42.6276364 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnEntityAnimationUpdate
[ 01:38:42.6276455 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnSendPacket
[ 01:38:42.6276571 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnReceivePacket
[ 01:38:42.6276671 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnLobbySearch
[ 01:38:42.6276756 | SPL ] Plugin Better Matchmaking v2.0 does not implement OnRender
[ 01:38:42.6276847 | SPL ] Plugin Better Matchmaking v2.0 implements OnImGuiRender
[ 01:38:42.6276935 | SPL ] Plugin Better Matchmaking v2.0 implements OnImGuiFreeRender
[ 01:38:50.0835756 | SPL ] [Better Matchmaking] Managers: Initializing...
[ 01:38:50.0841750 | SPL ] [System.Collections, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a] Resolved Path:
[ 01:38:50.0842167 | SPL ] [Bootstrapper] Loading System.Collections
[ 01:38:50.0854857 | SPL ] [Better Matchmaking] LocalizationManager: Initializing...
[ 01:38:50.0858282 | SPL ] [System.IO.FileSystem.Watcher, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a] Resolved Path:
[ 01:38:50.0858601 | SPL ] [Bootstrapper] Loading System.IO.FileSystem.Watcher
[ 01:38:50.0868589 | SPL ] [Better Matchmaking] Localization en-us: Initializing...
[ 01:38:50.0897844 | SPL ] [Better Matchmaking] Localization en-us: Done!
[ 01:38:50.0898922 | SPL ] [Better Matchmaking] Localization en-us: Saving...
[ 01:38:50.0899899 | SPL ] [Better Matchmaking] LocalizationChangeWatcher: Localization en-us: Temporarily Disabling...
[ 01:38:50.0946493 | SPL ] [System.Text.Json, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51] Resolved Path:
[ 01:38:50.0947044 | SPL ] [Bootstrapper] Loading System.Text.Json
[ 01:38:50.0948792 | SPL ] [System.Text.Encodings.Web, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51] Resolved Path:
[ 01:38:50.0949047 | SPL ] [Bootstrapper] Loading System.Text.Encodings.Web
[ 01:38:50.1161659 | SPL ] [Better Matchmaking] LocalizationManager: Loading All Localizations...
[ 01:38:50.1167465 | SPL ] [Better Matchmaking] LocalizationManager: Loading All Localizations Done!
[ 01:38:50.1169088 | SPL ] [Better Matchmaking] LocalizationChangeWatcher: Initializing...
[ 01:38:50.1171580 | SPL ] [Better Matchmaking] LocalizationChangeWatcher: Initialization Done!
[ 01:38:50.1171743 | SPL ] [Better Matchmaking] LocalizationManager: Initialization Done!
[ 01:38:50.1173395 | SPL ] [Better Matchmaking] ConfigManager: Initializing...
[ 01:38:50.1194939 | SPL ] [Better Matchmaking] Default Config: Initializing...
[ 01:38:50.1195153 | SPL ] [Better Matchmaking] Default Config: Initialization Done!
[ 01:38:50.1197051 | SPL ] [Better Matchmaking] Config: Loading...
[ 01:38:50.1835013 | SPL ] [Better Matchmaking] Config: Initializing...
[ 01:38:50.1906936 | SPL ] [Better Matchmaking] Config: Initialization Done!
[ 01:38:50.1907272 | SPL ] [Better Matchmaking] Config: Loading Done!
[ 01:38:50.1915149 | SPL ] [Better Matchmaking] Config: Saving...
[ 01:38:50.1915859 | SPL ] [Better Matchmaking] ConfigChangeWatcher: Temporarily Disabling...
[ 01:38:50.2134409 | SPL ] [Better Matchmaking] Config: Saving Done!
[ 01:38:50.2136089 | SPL ] [Better Matchmaking] ConfigChangeWatcher: Initializing...
[ 01:38:50.2137872 | SPL ] [Better Matchmaking] ConfigChangeWatcher: Initialization Done!
[ 01:38:50.2138042 | SPL ] [Better Matchmaking] ConfigManager: Initialization Done!
[ 01:38:50.2142154 | SPL ] [Better Matchmaking] Core: Initializing...
[ 01:38:50.2153261 | SPL ] [steam_api64.dll] Resolved Path:
[ 01:38:50.2540845 | SPL ] [Matchmaking: Found SteamMatchmaking interface getter at 0x143E98558
[ 01:38:50.2546715 | SPL ] [steam_api64.dll] Resolved Path:
[ 01:38:50.2547657 | SPL ] [Better Matchmaking] Core: Initialization Done!
[ 01:38:50.2548077 | SPL ] [Better Matchmaking] Managers: Initialization Done!
[ 01:39:02.0752596 | SPL ] [Better Matchmaking] [OnNumericalFilter] steamInterface: 60361488, keyAddress: 4, comparison: ==, value: 0
[ 01:39:05.5893213 | SPL ] Found GetMonsterDti function at 0x14139EAF0
[ 01:39:05.5893809 | SPL ] Found EmDtiTable at 0x143EEFC60
[ 01:39:07.2830157 | SPL ] Found cD3DRender::isD3D12 at 0x1424e8250
[ 01:39:07.2850550 | SPL ] Initializing D3D module for D3D12
[ 01:39:07.3081306 | SPL ] Found D3D12 command queue
[ 01:39:07.3083342 | SPL ] [Bootstrapper] Loading ImGui.NET
[ 01:39:07.3120374 | SPL ] [Bootstrapper] Loading System.Runtime
[ 01:39:07.3139482 | SPL ] [Bootstrapper] Loading System.Numerics.Vectors
[ 01:39:07.3150879 | SPL ] Initializing Renderer with
Viewport Size: 2560x1600

Window Size: 2560x1600

[ 01:39:07.3151180 | SPL ] [cimgui] Resolved Path: nativePC/plugins/CSharp/Loader/cimgui.dll
[ 01:39:07.3374173 | SPL ] [cimgui] Resolved Path: nativePC/plugins/CSharp/Loader/cimgui.dll
[ 01:39:07.3379423 | SPL ] [cimgui] Resolved Path: nativePC/plugins/CSharp/Loader/cimgui.dll
[ 01:39:07.3409299 | SPL ] [cimgui] Resolved Path: nativePC/plugins/CSharp/Loader/cimgui.dll
[ 01:39:07.3424502 | SPL ] Renderer.Initialize
[ 01:39:07.3424766 | SPL ] Loading cimgui.dll
[ 01:39:07.4769471 | SPL ] Creating RTV for back buffer 0, with size 2560x1600
[ 01:39:07.4769889 | SPL ] Creating RTV for back buffer 1, with size 2560x1600
[ 01:39:07.4769982 | SPL ] Creating RTV for back buffer 2, with size 2560x1600
[ 01:39:07.5108069 | SPL ] Initialized D3D12
[ 01:39:07.5108702 | SPL ] [PrimitiveRenderingModule] Late init
[ 01:39:07.5323551 | SPL ] [PrimitiveRenderingModule] Creating frame contexts
[ 01:39:07.5346866 | SPL ] [Bootstrapper] Loading System.Reflection.Emit.Lightweight
[ 01:39:07.5348106 | SPL ] [Bootstrapper] Loading System.Reflection.Emit.ILGeneration
[ 01:39:07.5348518 | SPL ] [Bootstrapper] Loading System.Reflection.Primitives
[ 01:39:07.5394340 | SPL ] [cimgui] Resolved Path: nativePC/plugins/CSharp/Loader/cimgui.dll
[ 01:39:07.5401238 | SPL ] [cimgui] Resolved Path: nativePC/plugins/CSharp/Loader/cimgui.dll
[ 01:39:07.5405715 | SPL ] [cimgui] Resolved Path: nativePC/plugins/CSharp/Loader/cimgui.dll
[ 01:39:07.5413994 | SPL ] [cimgui] Resolved Path: nativePC/plugins/CSharp/Loader/cimgui.dll
[ 01:39:07.5418485 | SPL ] [cimgui] Resolved Path: nativePC/plugins/CSharp/Loader/cimgui.dll
[ 01:39:07.5422482 | SPL ] [cimgui] Resolved Path: nativePC/plugins/CSharp/Loader/cimgui.dll
[ 01:39:07.5426637 | SPL ] [cimgui] Resolved Path: nativePC/plugins/CSharp/Loader/cimgui.dll
[ 01:39:07.5430586 | SPL ] [cimgui] Resolved Path: nativePC/plugins/CSharp/Loader/cimgui.dll
[ 01:39:27.6501609 | SPL ] [Better Matchmaking] [OnStartRequest] phase: 0, netCore:<PHONE_NUMBER>, netRequest:<PHONE_NUMBER>
[ 01:39:27.6505563 | SPL ] [Better Matchmaking] 1
[ 01:39:27.6505954 | SPL ] [Better Matchmaking] 2

Potentially fixed in ca765942d6dd1f88ed020df3dd2282816b38d697. Released with https://github.com/GreenComfyTea/MHW-Better-Matchmaking/releases/tag/v2.1. Will close later if I don't receive reports that the fix is not working.


Check on conda channels used in build/install process

In response to install failures on Travis, I started using the conda-forge channel instead of the default channel to get dependent packages for dakotathon (see #48). My hunch is there's a bug in the default channel. When it's fixed, I'll revert to using it instead of conda-forge.

Note that we're using conda-forge everywhere. It has become our default.


Read me part is missing !!!

vue & vue-router-permissions version
vue: 2.6.4
vue-router: ^3.0.2
Reproduction Link
Out of the box
Steps to reproduce
Setup access per documentation. Notice how when you have a protected route, it will flash before redirecting when access is not allowed.
What is Expected?
read me part is missing.
What is actually happening?
Correct the read me part. Because npm package name is missing.

Thanks, will do


feat: add BakeShadows component

closes #321
How can I remove these warnings

About the color error, the color prop on TresMeshStandardMaterial expects a THREE.Color, so any of the instantiation examples here will work, like this:
<TresMeshStandardMaterial :color="new Color(0x00ff00)" />


Fix README.md formatting

It appears the markdown for the headers isn't being properly parsed. This should be corrected for readability purposes.

https://github.com/benweiser/Webpack-Starter-Pack/commit/31f8d02d385d25c4b9789cb39ee27fc4677cf9f3


Plugin error

Macos 11.
Kicad 5.1
It sees the plugin is installed right, but it can not initialize. Other plugins work just fine in the same location.

This looks like an issue trying to create temporary files. 8c11d36 should fix this


Add tests to show #684 is fixed

Build failing because of NPM issues with prerelease versions :angry: