Development environment improvements

#Changelog:

Replace mailslurper with a basic python SMTP logger
Add more compliance periods to dockerized ops scripts and bundle the credit calculation scripts into it
Fix operational script 0008 to deal with renamed energy density categories
Add react-hot-loader dependency and integrate with docker webpack config
Chunk splitting and HTML generation for dev-server to improve compile times
Minio bucket created on startup if it doesn't exist

@plasticviking the operational script 0008_add_default_carbon_intensities.py is updated, do we need to run it? the latest script in 0012..

message from developers, no need to run the updated script


Can't see all options in DropDown

Hey there, I just encountered the following error with Alva:
As I downloaded it first time and was following Guides. In Guide 5, in HandleChange, in to, all options are not clearly visible, dropdown is coming behind the windows taskbar.

Hey @GermaVinsmoke – good catch. We‘ll have a look at it, thanks for reporting!


[FixCode] Add necessary constructor call to bridge a String to AnyHashable

[FixCode] Add necessary constructor call to bridge a String to AnyHashable. rdar://27685458
This is migration-critical fixit. After id-as-any, imported dictionary may require key as AnyHashable.
This fixit helps construct AnyHashable from a string if an unable-to-convert error is encountered.

Resolved bug number: (SR-)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

Builds the compiler incrementally.
Builds the standard library only for macOS. Simulator standard libraries and
device standard libraries are not built.
lldb is not built.
The test and validation-test targets are run only for macOS. The optimized
version of these tests are not run.

A smoke test on Linux does the following:

Builds the compiler incrementally.
Builds the standard library incrementally.
lldb is built incrementally.
The swift test and validation-test targets are run. The optimized version of these
tests are not run.
lldb is tested.

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

…hable. rdar://27685458
This is migration-critical fixit. After id-as-any, imported dictionary may require key as AnyHashable.
This fixit helps construct AnyHashable from a string if an unable-to-convert error is encountered.

@swift-ci smoke test OS X platform

After talking with @rjmccall , the fixit may not be necessary since we will add implicit conversion rule for this case. We decide to not merge it for now.


Examples of using Atomics has wrong return value comment

@Zavtramen commented on Mon Oct 12 2020
Content Issue

[ ] Please close this issue, I accidentally submitted it without adding any details
[ ] New documentation
[x] Correction or update

URL of page you are seeing the problem on:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Atomics
Details

Examples of using Atomics has wrong return value comment:
Atomics.compareExchange(ta, 0, 5, 12);
Atomics.load(ta, 0); // 12

result here should be 1, not 12, cause previously stored value is 1 not 5
and, another one:
Atomics.store(ta, 0, 12); // 12

Atomics.sub(ta, 0, 2);
Atomics.load(ta, 0); // 3

result here should be 10, not 3
and where is another error with 'or'
examples should be revised

I corrected the return value comments and added some more for clarfication.

Fixes look good; thanks @mikoMK !


feat: add optional database column type to entity definition

Fixes: https://github.com/pdevito3/craftsman/issues/35

added a new line to the changelog - let me know if I you want me to squash the two commits or if its ok for you

no worries. thanks again!


ResearchStudy.titel: String :contains search and parentheses fails

Describe the bug
When searching for a string with the :contains modifier or using _filter with the comodifier results are not found if the target string contains brackets
To Reproduce
Steps to reproduce the behavior:

http://hapi.fhir.org/baseR4/ResearchStudy?title:contains=SORATR returns a single result (expected 2)
https://hapi.fhir.org/baseR4/ResearchStudy?title:contains=SORA returns 2 results (including the one with brackets surrounding the target string)

Expected behavior
Both searches should return 2 results, brackets shouldn't impact the contains search.
Environment (please complete the following information):

HAPI FHIR Version
OS: [e.g. iOS]
Browser [e.g. chrome, safari]

Additional context
Backup of target resources:
https://gist.github.com/patrick-werner/f341a699e5df56e0365f4716f897a368

That's a very long string in the source resource. My suspicion (untested) is that the brackets are a red herring, and this string is just hitting the current 200 character limit for indexing strings.
This limit is arbitrary and could be made configurable, although different RDBMSs will have different behaviours when you try to index a really long string column.

Thanks for your reply @jamesagnew
After some testing i can confirm the issue is caused by the 200 char index limit. Will close this issue.

I modified the issue title. I have a use case where we are storing and searching ResearchStudy titles, these are often times longer then 200 chars.
I'd like to increase the max size of the column(s), but this has to be static a compile time.
What do you think of removing the length attribute on the columns, transfer Max_Length to the storageSettings with a default of 200.
This would enforce the index string to be maximum 200 chars long by default, but allow use-cases with longer strings.

I don't know that I'd want to drop the length attribute - That means we'd just use the default, which I believe is 255 chars, but with unexpected changes possible if that default ever changed. And making it longer by default could cause issue in some places, not all databases like indexing long strings.
Adding a configurable max length would be fine though - You'd have to manually change the maximum length of the column in the DB, but we could add a setting to tell HAPI that this had been done.


How long does it take for training 2 epochs on 8 x NVIDIA A100

Hi:
I was able to successfully fine-tune with the training script you provided, using the EleutherAI/pythia-12b as the base model, but I am trying to verify that I did the same that you did.
I am wondering how long is training supposed to run for for 8 x A100.
Can you share the tensorboard board to understand how the training process happened for the model that you published on HuggingFace?
Thanks in advance

1 epoch on 8 A100s is probably several hours. Depends a bit on what data you use and settings you might change. I don't think the TB logs are lying around from that run, but, just run the training script and watch metrics and progress to 0.01 epochs or something to extraploate.

Interesting, the reason I ask is because seems to only be taking 1 hour for me, which seems suspect :-). I am using the default deepspeed config provided, the default dolly 15k fine-tuning dataset with the default configuration:
!deepspeed 8 \
     --module training.trainer \
     --input-model EleutherAI/pythia-12b \
     --deepspeed {deepspeed_config} \
     --epochs 2 \
     --local-output-dir {local_output_dir} \
     --dbfs-output-dir {dbfs_output_dir} \
     --per-device-train-batch-size 6 \
     --per-device-eval-batch-size 6 \
     --logging-steps 10 \
     --save-steps 200 \
     --save-total-limit 20 \
     --eval-steps 50 \
     --warmup-steps 50 \
     --test-size 200 \
     --lr 5e-6

No, the time for 2 full epochs. It took 1 hour for 2 epochs on 8 x A100 80GB.

Just double checking - that shows about 600 steps, which is 3600 inputs, which isn't nearly a full epoch. Is what's above what you mean or you're definitely sure it was 2 epochs (more like 5000 steps at batch size of 6). If so, then it's likely I just misremember, as I only tried this early on once

That's what I mean.

Am I reading that graph incorrectly or is it wrong?

I see.
Related question, the eval's loss trends upwards with the arguments from the train_dolly.py script, and also even when I make the test-size bigger. That's part of the reason why I was asking if you had the Tensorboard for the training of the published model, it would be great to be able to compare for reproducibility sake.

That looks familiar. Train loss drops at the end of each epoch and is mostly flat. Eval loss may or may not go down at first, but one quickly runs into overfitting with models like this and eval loss increases after an epoch or two. I'm not sure we had a great explanaiton. It seems, generally, like overfitting / memorization. Train loss is better once it starts seeing what it saw before in training. And so eval is getting worse quickly because of that. The answers would be more data or a smaller model really. 12B is just overkill, I think, unless you have a lot of fine-tuning data.

Thank you.


Build fails with messages including "undefined reference to symbol 'acos@@GLIBC_2.2.5' ", "Linking of rule '@flatbuffers//:flatc' failed"

System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 18.04
TensorFlow installed from (source or binary): Attempting to build from source
TensorFlow version: 2.1.0 (attempting to build from master)
Python version: 3.8.0
Installed using virtualenv? pip? conda?: virtualenv
Bazel version (if compiling from source): 1.2.1
GCC/Compiler version (if compiling from source): 7.4.0
CUDA/cuDNN version: CUDA 10.1 / cuDNN 7.6.5
GPU model and memory: NVidia RTX 2080 Ti

Describe the problem
I am trying to build for python 3.8.0 since issues relating to python 3.8.0 should now be fixed (see #34433 ).  There is also no pip package that you can install with "pip install tensorflow" for python 3.8.0.
Build fails with the following messages:
INFO: Analyzed target //tensorflow/tools/pip_package:build_pip_package (345 packages loaded, 27926 targets configured).
INFO: Found 1 target...
INFO: Deleting stale sandbox base /home/daniel/.cache/bazel/_bazel_daniel/79db702fc9f94af7d11e11c5d64854d0/sandbox
INFO: From Compiling tensorflow/core/platform/default/logging.cc [for host]:
tensorflow/core/platform/default/logging.cc: In member function ‘bool tensorflow::internal::LogFirstNState::ShouldLog(int)’:
tensorflow/core/platform/default/logging.cc:369:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   if (counter_value < n) {
       ~~~~~~~~~~~~~~^~~
INFO: From Compiling external/snappy/snappy-sinksource.cc [for host]:
cc1plus: warning: command line option ‘-Wno-implicit-function-declaration’ is valid for C/ObjC but not for C++
INFO: From Compiling external/snappy/snappy-stubs-internal.cc [for host]:
cc1plus: warning: command line option ‘-Wno-implicit-function-declaration’ is valid for C/ObjC but not for C++
INFO: From Compiling external/snappy/snappy.cc [for host]:
cc1plus: warning: command line option ‘-Wno-implicit-function-declaration’ is valid for C/ObjC but not for C++
INFO: From Compiling tensorflow/core/platform/protobuf.cc [for host]:
tensorflow/core/platform/protobuf.cc: In member function ‘virtual bool tensorflow::TStringOutputStream::Next(void**, int*)’:
tensorflow/core/platform/protobuf.cc:30:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   if (old_size < target_->capacity()) {
       ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
INFO: From Compiling tensorflow/core/platform/numbers.cc [for host]:
tensorflow/core/platform/numbers.cc: In instantiation of ‘T tensorflow::{anonymous}::locale_independent_strtonum(const char*, const char**) [with T = double]’:
tensorflow/core/platform/numbers.cc:197:60:   required from here
tensorflow/core/platform/numbers.cc:65:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   for (int i = 0; i < special_num_str.length(); ++i) {
                   ~~^~~~~~~~~~~~~~~~~~~~~~~~~~
tensorflow/core/platform/numbers.cc: In function ‘std::__cxx11::string tensorflow::strings::HumanReadableNumBytes(tensorflow::int64)’:
tensorflow/core/platform/numbers.cc:459:8: warning: ‘%lld’ directive output may be truncated writing between 1 and 19 bytes into a region of size between 7 and 8 [-Wformat-truncation=]
 string HumanReadableNumBytes(int64 num_bytes) {
        ^~~~~~~~~~~~~~~~~~~~~
tensorflow/core/platform/numbers.cc:459:8: note: directive argument in the range [0,<PHONE_NUMBER>854775807]
In file included from /usr/include/stdio.h:862:0,
                 from /usr/include/c++/7/cstdio:42,
                 from /usr/include/c++/7/ext/string_conversions.h:43,
                 from /usr/include/c++/7/bits/basic_string.h:6361,
                 from /usr/include/c++/7/string:52,
                 from ./tensorflow/core/platform/numbers.h:19,
                 from tensorflow/core/platform/numbers.cc:15:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:65:44: note: ‘__builtin_snprintf’ output between 3 and 22 bytes into a destination of size 8
        __bos (__s), __fmt, __va_arg_pack ());
                                            ^
INFO: From Compiling external/llvm-project/llvm/lib/Support/APFloat.cpp [for host]:
external/llvm-project/llvm/lib/Support/APFloat.cpp: In member function ‘llvm::Expected<llvm::APFloatBase::opStatus> llvm::detail::IEEEFloat::convertFromDecimalString(llvm::StringRef, llvm::APFloatBase::roundingMode)’:
external/llvm-project/llvm/lib/Support/APFloat.cpp:2625:38: warning: ‘D.llvm::decimalInfo::exponent’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     fs = roundSignificandWithExponent(decSignificand, partCount,
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
                                       D.exponent, rounding_mode);
                                       ~~~~~~~~~~~~~~~~~~~~~~~~~~
external/llvm-project/llvm/lib/Support/APFloat.cpp:2561:36: warning: ‘D.llvm::decimalInfo::normalizedExponent’ may be used uninitialized in this function [-Wmaybe-uninitialized]
              (D.normalizedExponent + 1) * 28738 <=
              ~~~~~~~~~~~~~~~~~~~~~~^~~~
external/llvm-project/llvm/lib/Support/APFloat.cpp:2622:16: warning: ‘D.llvm::decimalInfo::lastSigDigit’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     } while (p <= D.lastSigDigit);
              ~~^~~~~~~~~~~~~~~~~
external/llvm-project/llvm/lib/Support/APFloat.cpp:2581:58: warning: ‘D.llvm::decimalInfo::firstSigDigit’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     partCount = static_cast<unsigned int>(D.lastSigDigit - D.firstSigDigit) + 1;
                                           ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
INFO: From Compiling external/llvm-project/llvm/lib/Support/UnicodeCaseFold.cpp [for host]:
external/llvm-project/llvm/lib/Support/UnicodeCaseFold.cpp:8:1: warning: multi-line comment [-Wcomment]
 //   utils/unicode-case-fold.py \
 ^
INFO: From Compiling external/llvm-project/llvm/lib/Support/VirtualFileSystem.cpp [for host]:
external/llvm-project/llvm/lib/Support/VirtualFileSystem.cpp: In member function ‘std::unique_ptr<llvm::vfs::RedirectingFileSystem::Entry> llvm::vfs::RedirectingFileSystemParser::parseEntry(llvm::yaml::Node*, llvm::vfs::RedirectingFileSystem*, bool)’:
external/llvm-project/llvm/lib/Support/VirtualFileSystem.cpp:1471:5: warning: ‘Kind’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     switch (Kind) {
     ^~~~~~
INFO: From Compiling external/llvm-project/llvm/lib/MC/ELFObjectWriter.cpp [for host]:
external/llvm-project/llvm/lib/MC/ELFObjectWriter.cpp: In function ‘uint64_t {anonymous}::ELFWriter::writeObject(llvm::MCAssembler&, const llvm::MCAsmLayout&)’:
external/llvm-project/llvm/lib/MC/ELFObjectWriter.cpp:1193:36: warning: ‘AddrsigSection’ may be used uninitialized in this function [-Wmaybe-uninitialized]
       SectionOffsets[AddrsigSection] = std::make_pair(SecStart, SecEnd);
                                    ^
INFO: From Compiling external/llvm-project/llvm/lib/MC/MachObjectWriter.cpp [for host]:
external/llvm-project/llvm/lib/MC/MachObjectWriter.cpp: In member function ‘void llvm::MachObjectWriter::writeNlist(llvm::MachObjectWriter::MachSymbolData&, const llvm::MCAsmLayout&)’:
external/llvm-project/llvm/lib/MC/MachObjectWriter.cpp:381:13: warning: ‘AliaseeInfo’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     Address = AliaseeInfo->StringIndex;
     ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
ERROR: /home/daniel/.cache/bazel/_bazel_daniel/79db702fc9f94af7d11e11c5d64854d0/external/flatbuffers/BUILD.bazel:51:1: Linking of rule '@flatbuffers//:flatc' failed (Exit 1)
/usr/bin/ld: bazel-out/host/bin/external/flatbuffers/src/libflatbuffers.a(idl_parser.o): undefined reference to symbol 'acos@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Target //tensorflow/tools/pip_package:build_pip_package failed to build
Use --verbose_failures to see the command lines of failed build steps.
ERROR: /home/daniel/tensorflow/tensorflow/python/tools/BUILD:141:1 Linking of rule '@flatbuffers//:flatc' failed (Exit 1)
INFO: Elapsed time: 103.160s, Critical Path: 25.44s
INFO: 1225 processes: 1225 local.
FAILED: Build did NOT complete successfully

Provide the exact sequence of commands / steps that you executed before running into the problem
git clone https://github.com/tensorflow/tensorflow.git
cd tensorflow
./configure
You have bazel 1.2.1 installed.
Please specify the location of python. [Default is /home/daniel/tf38/bin/python]: Default accepted
Python library path to use.  Default is [/home/daniel/tf38/lib/python3.8/site-packages]: Default accepted
Do you wish to build TensorFlow with XLA JIT support? [Y/n]: Y
XLA JIT support will be enabled for TensorFlow.
Do you wish to build TensorFlow with OpenCL SYCL support? [y/N]: N
No OpenCL SYCL support will be enabled for TensorFlow.
Do you wish to build TensorFlow with ROCm support? [y/N]: N
No ROCm support will be enabled for TensorFlow.
Do you wish to build TensorFlow with CUDA support? [y/N]: y
CUDA support will be enabled for TensorFlow.
Do you wish to build TensorFlow with TensorRT support? [y/N]: y
TensorRT support will be enabled for TensorFlow.
Found CUDA 10.1 in:
    /usr/local/cuda/lib64
    /usr/local/cuda/include
Found cuDNN 7 in:
    /usr/lib/x86_64-linux-gnu
    /usr/include
Found TensorRT 6 in:
    /usr/lib/x86_64-linux-gnu
    /usr/include/x86_64-linux-gnu
CUDA compute capabilities [Default is: 3.5,7.0]: 7.5
Do you want to use clang as CUDA compiler? [y/N]: N
nvcc will be used as CUDA compiler.
Please specify which gcc should be used by nvcc as the host compiler. [Default is /usr/bin/gcc]: Default accepted
Please specify optimization flags to use during compilation when bazel option "--config=opt" is specified [Default is -march=native -Wno-sign-compare]: Default accepted
Would you like to interactively configure ./WORKSPACE for Android builds? [y/N]: N
Not configuring the WORKSPACE for Android builds.
Configuration finished.
bazel build --config=opt --config=cuda //tensorflow/tools/pip_package:build_pip_package

Build fails with the above messages.
Any other info / logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached.
I have noticed in the past that builds can sometimes build with different bazel versions.  I tried bazel 0.26.1, 1.0.0 and 2.0.0.  However the build still fails with all these bazel versions.

For those who are still struggling with this problem and using centos-7 with "scl enable devtoolset-7", you can workaournd this issue by adding "BAZEL_LINKLIBS=-l%:libstdc++.a" before "bazel build".
the workaround mentioned above doesn't work at my side

Is this issue fixed? building still leads to the following error
Linking CXX executable ../../../../bin/intel64/Release/hello_classification
/opt/intel/openvino_2020.1.023/opencv/lib/libopencv_imgproc.so.4.2.0: undefined reference to<EMAIL_ADDRESS>/opt/intel/openvino_2020.1.023/opencv/lib/libopencv_core.so.4.2.0: undefined reference to<EMAIL_ADDRESS>collect2: error: ld returned 1 exit status
inference-engine/ie_bridges/c/samples/object_detection_sample_ssd/CMakeFiles/object_detection_sample_ssd_c.dir/build.make:111: recipe for target '../bin/intel64/Release/object_detection_sample_ssd_c' failed
make[2]: *** [../bin/intel64/Release/object_detection_sample_ssd_c] Error 1
CMakeFiles/Makefile2:6449: recipe for target 'inference-engine/ie_bridges/c/samples/object_detection_sample_ssd/CMakeFiles/object_detection_sample_ssd_c.dir/all' failed
make[1]: *** [inference-engine/ie_bridges/c/samples/object_detection_sample_ssd/CMakeFiles/object_detection_sample_ssd_c.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
/opt/intel/openvino_2020.1.023/opencv/lib/libopencv_imgproc.so.4.2.0: undefined reference to<EMAIL_ADDRESS>/opt/intel/openvino_2020.1.023/opencv/lib/libopencv_core.so.4.2.0: undefined reference to<EMAIL_ADDRESS>collect2: error: ld returned 1 exit status
inference-engine/samples/benchmark_app/CMakeFiles/benchmark_app.dir/build.make:156: recipe for target '../bin/intel64/Release/benchmark_app' failed
make[2]: *** [../bin/intel64/Release/benchmark_app] Error 1
CMakeFiles/Makefile2:5622: recipe for target 'inference-engine/samples/benchmark_app/CMakeFiles/benchmark_app.dir/all' failed
make[1]: *** [inference-engine/samples/benchmark_app/CMakeFiles/benchmark_app.dir/all] Error 2
/opt/intel/openvino_2020.1.023/opencv/lib/libopencv_imgproc.so.4.2: undefined reference to<EMAIL_ADDRESS>/opt/intel/openvino_2020.1.023/opencv/lib/libopencv_core.so.4.2: undefined reference to<EMAIL_ADDRESS>collect2: error: ld returned 1 exit status
inference-engine/samples/classification_sample_async/CMakeFiles/classification_sample_async.dir/build.make:108: recipe for target '../bin/intel64/Release/classification_sample_async' failed
make[2]: *** [../bin/intel64/Release/classification_sample_async] Error 1
CMakeFiles/Makefile2:5680: recipe for target 'inference-engine/samples/classification_sample_async/CMakeFiles/classification_sample_async.dir/all' failed
make[1]: *** [inference-engine/samples/classification_sample_async/CMakeFiles/classification_sample_async.dir/all] Error 2
/opt/intel/openvino_2020.1.023/opencv/lib/libopencv_imgproc.so.4.2.0: undefined reference to<EMAIL_ADDRESS>/opt/intel/openvino_2020.1.023/opencv/lib/libopencv_core.so.4.2.0: undefined reference to<EMAIL_ADDRESS>collect2: error: ld returned 1 exit status
inference-engine/samples/hello_classification/CMakeFiles/hello_classification.dir/build.make:110: recipe for target '../bin/intel64/Release/hello_classification' failed
make[2]: *** [../bin/intel64/Release/hello_classification] Error 1
CMakeFiles/Makefile2:5764: recipe for target 'inference-engine/samples/hello_classification/CMakeFiles/hello_classification.dir/all' failed
make[1]: *** [inference-engine/samples/hello_classification/CMakeFiles/hello_classification.dir/all] Error 2
Makefile:181: recipe for target 'all' failed
make: *** [all] Error 2

@dbonner,
We are checking to see if you still need help on this issue. Can you try building the latest stable version of TF i.e  2.6.0 using this guide and let us know if the issue still persists in newer versions.Thanks!

It's resolved. thanks
On Mon, 20 Sep 2021, 11:46 pm Sanat, @.***> wrote:

@dbonner https://github.com/dbonner,
We are checking to see if you still need help on this issue. Can you try
building the latest stable version of TF i.e 2.6.0 using this guide
https://www.tensorflow.org/install/source and let us know if the issue
still persists in newer versions.Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/issues/36170#issuecomment-922943348,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAB26QXOFFUDI4YOJK3VFM3UC43M3ANCNFSM4KLABISA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

@dbonner,
Thank you for your update, kindly move this issue to closed status as it is resolved.


[question] Optional Types?

Hi,
Thanks for this great plugin, is there a way to generate Option<T> types as ? optionals in TS?
Thanks

You can do that by adding #[specta(optional)] to the field you want to be optional. If you haven't checked out the Specta documentation I'd suggest doing so, since this question isn't relevant to Tauri Specta specifically, but it looks like we don't actually document #[specta(optional)] yet.

Oh awesome thanks


Pass all supported options to the fetch function

Hi @enisdenjo ,
some time ago following our conversation you introduced support for credentials option on the fetch function.
Today I am back to ask to introduce support for additional options.
Story
Make sure all supported options are passed to the fetch function.
Acceptance criteria
Currently, the fetch implementation has a whitelist approach to pass options to fetch.
Specifically, only headers, credentials, and body are passed to the underlying fetch function.
However, fetch supports many additional options, such as mode, cache, redirect, referrer, referrerPolicy, integrity, keepalive, and signal (this is actually something you custom implement and so possibly should not be replaced).
Developers might need to specify any of those valid additional options and so these must be passed to fetch.
I have just opened a similar PR, in fetch-multipart-graphql#46, where I proposed dropping the whitelist approach so that all developer-defined options are passed to fetch.
This shifts the responsibility to define valid options to developers as opposed to being forced to maintain a whitelist.
Clearly, you can still override options that need a custom implementation, such as signal.
Let me know your thoughts, it's a simple change, but I am also happy to open a PR for it.

Hey hey, thanks for bringing this up. The reason why I don't expose all of the options is because I don't think all of them are useful. Certainly the cache, redirect, integrity and keepalive options are not something you'd fiddle with when dealing with SSE subscriptions (maybe excluding referrer and referrerPolicy?); also, changing the mode option wont disable CORS and is rarely used in practice.
Do you have an actual use-case where you need to manually manage one of the options? If so, I'd love to hear about it and accordingly expose the options you're missing.
P.S. you can always adapt the fetchFn and provide whatever options you need:
import { createClient } from 'graphql-sse';

const client = createClient({
  url: 'http://my-fetch-fn:4000/graphql/stream',
  fetchFn: (url, options) =>
    fetch(url, {
      mode: 'cors',
      referrerPolicy: 'origin',
      cache: 'no-cache',
      // ...and friends...
      ...options,
    }),
});

My current use case is mostly around referrerPolicy indeed.
I bet most developers don't pay enough attention to this, which means they are implicitly forced to work with whatever the browsers set.
Sometimes that is not a problem, but I always encourage making explicit decisions that force you to deal with the problem and prepare for the integration between client and server; rather than being forgetful and relying on defaults.

Makes sense.
Lets start then by exposing referrer and referrerPolicy through the regular client options and leave the rest behind the custom fetchFn implementation for now (as showcased above in https://github.com/enisdenjo/graphql-sse/issues/31#issuecomment-1190344839). I'd prefer facing use-cases before expanding options - keeps the library lean and simple.
Feel free to open a PR if you feel like it!


Small changes. readme, language:version Strings/Included files

readme.md:
move the Version section after the initial description of the project and "minimize" the OPENQASM 2.x visibility, adding link to the Live doc.
Documentation

Language>Version string : adding more clarity when the minor version is not present
Language>Include Files: remove the "#" in the "include statement
Grammar: Adding link to ANTLR4 base library to use the Grammar file, and mark it like "Work in Progress"

@ismaelfaro should pass now feel free to merge (whitespace :-().
@mtreinish can we set this up to auto-merge if it passes tests

@jaygambetta I can configure mergify (that's what we use on terra for automerge) for this repo if you want. But, the CI job will never actually pass as it is written. It is trying to do something that auth model on github doesn't actually allow (which is why it returns a 403 here). The job is trying to push to a branch which github doesn't allow from PRs opened from a fork. This is done for security reasons, since anyone can open a PR from a fork.

thanks


SHOULD vs MUST with orphan mitigiation

In the new text about platforms sending a deprovision request for every resource that has attempted to be provisioned, we specify that the platform MUST send a deletion request. However, the existing orphan mitigation section says that the platform SHOULD attempt a deletion for the specific orphan mitigation circumstances. As neither section specifies the timing as to when this deletion request will happen, the new text basically overwrites the entirety of the orphan mitigation section.
We should clarify our intent here. Should orphan mitigation happen immediately upon the platform deciding to mark the resource as failed? If so, we should specify that here. If not, then is orphan mitigation no longer relevant? We should then rework this section entirely to just talk about cleaning up of resources in general.

Reading #368 I see this:

the platform MUST cease polling, the operation state MUST be considered failed, and the Platform SHOULD send a deprovision request

And then the current orphan mitigation

To mitigate orphan Service Instances and bindings, the marketplace SHOULD attempt to delete resources it cannot be sure were successfully created, and SHOULD keep trying to delete them until the Service Broker responds with a success.

Both sections seems to be in sync, am I missing something?

I think @kibbles-n-bytes is talking about this line in the provision section:

Responses with any other status code will be interpreted as a failure and a deprovision request MUST be sent to the Service Broker to prevent an orphan being created on the Service Broker.

Note the "MUST".
There might be some inconsistency between the two sections, but I would prefer to solve this by:
1 - moving the orphan mitigation section into the appropriate Provision and Binding sections of the spec. Having the logic of how to deal with each type of response split between two sections of the spec hard to follow and leads to possible conflicts, like @kibbles-n-bytes is suggesting we have.
2 - once we do 1, we can then see if we still have an inconsistency - but I doubt we will.
Note, this is related to: https://github.com/openservicebrokerapi/servicebroker/pull/254 and might end up closing that one.

The new orphan mitigation makes this much clearer. Closing.


Seek to previous or next subtitle line takes into account both imported subtitles.

I've observed that when I import both Japanese and English subtitles, the seeking function takes into account both, even though the primary subtitle is the Japanese one. For instance, during the opening song where there's an English translation but no Japanese transcription, pressing the hotkey to jump to the next subtitle line doesn't go to the next Japanese line. Instead, it goes through the English secondary subtitle since it contains the translation of the opening. Shouldn't the seeking be focused on the main subtitle?

Maybe, some people will want to seek through one track or both tracks. Fixing this problem for everyone would probably mean implementing a setting somewhere that controls which subtitle tracks are navigated via the seek binds.


Unable to use the Endpoint object as per S3 docs

Hello,
I have a specific endpoint host and port for my buckets.
I've found the Endpoint object in S3 https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Endpoint.html however where is this configuration placed, I tried in the createClient object however it didn't seem to work:
var client = s3.createClient({
    s3Options: {
        hostname: "<IP_ADDRESS>"
        port: "1111",
        accessKeyId: "xxxxxxx",
        secretAccessKey: "xxxxy",
    },
});

Do I have to create a seperate object, if so at where is linked with the client itself?
Any help would be appreciated.

Got it - had to use:
endpoint: "<IP_ADDRESS>:1111"
and also:
sslEnabled: false,
s3ForcePathStyle: true


Update Console API Metric doc

🚀 Deployed on https://650a27c8108f1c5f4b75f136--cozy-fox-0defec.netlify.app


Hide only tag items in Git branch list.

There's currently a "Checkout Type" setting that allows the following options :  All, local, tags, remote.
There's not an option to show both local and remote only (i.e., hide only tags). I'd like to see this setting converted to a checkbox for each option so that any combination of options can be selected.

I have a similar feature request. Not sure if it should be a separate issue, but I'd like to reorder the items in the checkout list. Currently remote branches come last. If a repo has a large number of tags and only few remote branches, it would be nice if the branches could be shown before the tags, so one doesn't have to scroll so far.

Hello @joaomoreno,
How about I combine the two requests, and make it into an array where the order of the choices matters? However, since it's an array, it will be updatable through JSON only.

Could be a text box with comma-separated values of Local,Remote,Tags and the order they're listed matters. To not show one, just remove it from the list.

I'd like to work on this.

Filed #111754 to track an edge case around setting behaviour when there is one invalid value in the list.


another try with a wizard step component

Another approach is to create Component WizardStep and use it in a composite way. I also looked at Accordion and Accordion.Tab but i'm not really sure how to call createSubComponents and loadSubComponents correctly... :-(

it gets rendered, but the frame content is underneath the tabs and not within them...

Apply this patch and it will work
Patch_for_nested_frames_loading.patch.txt

Ok, so if I get you right, you mean that I should create dealing with if a TabSheet or if an Accordion is created in Wizard and WebWizard - is that correct? This makes total sense because of programmatic creation. Just like here e.g.: Accordion.addTab- correct?
But:
Compared to all other CUBA Components, in this Wizard Component i would like to not dig down in the  Vaadin layer, because there is no need to. If I see it correctly, the only place where I could place the implementation would be the WebWizard class. But there I'm already in Vaadin land and cannot use stuff like CUBA Accordion, correct?
Does this mean that I have to use the native Vaarin accordion to accomplish it?
Or is it possible to create a WizardImpl in the gui module and interact there with the CUBA components like Accordion.
If this is not possible, that I might loose some benefits of the abstraction you have put in place with something like Accordion...
Perhaps you can bring some light into this ;)

hi @jreznot,
do you have an idea on my above question? Perhaps I will just start and see how it goes, but I just want to make sure that I not totally misunderstand something here...
Thanks,
Mario

I mean that your component should contain TabSheet as the implementation detail. You can use cuba components if you do not want depend on Vaadin ones, for instance, Filter component uses GUI components instead of Vaadin. You can even implement your component in gui module, but it is not required.
As for Accordion and TabSheet - I think it is not so good idea to use them for Wizard at all. They use excessive space and it is not usual design pattern for wizards.


Unexpected current buffer change on new note

🐛 Describe the bug
I  recently started using this plugin and noticed an oddity (which admittedly could be something to do with my setup).
I have the following keybind:
vim.keymap.set("n", "<leader>nn", function()
    return "<Cmd>ObsidianNew " .. vim.fn.input('Title: ') .. "<CR>"
end, { expr = true })

Essentially to make creating a new note with user supplied title.
I notice that for some reason as soon as I press enter, the new note indeed gets created as expected, but something in the currently opened buffer also changes.
Below is a video demonstrating the issue (note the little blue dot in the tabline next to obsidian.lua was not present before I created the note but is present after the creating of the note, indicating that the currrent buffer, obsidian.lua in this case has changed in some way). This causes an error when trying to exit nvim, because it thinks that the currently opened buffer has changed.
https://user-images.githubusercontent.com/3199183/195307003-bcedb27e-8c82-4d32-8aed-18464c8ceb05.mp4
Versions
nvim --version

NVIM v0.8.0
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by<EMAIL_ADDRESS>
Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/opt/homebrew/Cellar/neovim/0.8.0/share/nvim"

nvim --headless -c 'lua print(require("obsidian").VERSION)' -c q
1.4.0%

Hey @vihu, :ObsidianNew will call :w on the current file before switching to the new note. That could be the source of the issue. Maybe you have some autocmd that modifies lua files on write?
It's not really necessary that :ObsidianNew writes the current buffer before switching, so maybe we should remove that if it causes more problems.

t's not really necessary that :ObsidianNew writes the current buffer before switching, so maybe we should remove that if it causes more problems.

I agree with this. Having :ObsidianNew and :ObsidianToday write out the currently opened buffer seems like unexpectedly introduced behavior to me. That's the responsibility of the user to specifically choose when to write the open buffer imo.

Having :ObsidianNew and :ObsidianToday write out the currently opened buffer seems like unexpectedly introduced behavior to me.

Fair enough. Do you want to make a PR to remove the writes? The lines are here and here.

Ah, beat me to it!


Increase compatibility with external cmake

Allow control of targets by external variables, and add include
directories to targets.
Signed-off-by: Raef Coles<EMAIL_ADDRESS>Description
Alter some of the cmake build system in order to allow better control of it by external projects. This allows, for example, a project to include two copies of mbedtls in its cmake (via include_directories) without causing target name clashes.
There shouldn't be any behavior changes in the cmake by default.
Status
READY
Requires Backporting
NO
Migrations
NO
Additional comments

Thanks! There are other pull requests in flight that change the cmakefiles, in particular https://github.com/ARMmbed/mbedtls/pull/3337 and https://github.com/ARMmbed/mbedtls/pull/3159 . Have you checked for redundancy and conflicts?

@ronald-cron-arm As the de facto cmake expert, I'm assigning this to you. Please unassign if you don't have time to shepherd this PR.

Yes I can handle this, no problem. This is related to things I've been looking at recently.

Thanks! There are other pull requests in flight that change the cmakefiles, in particular #3337 and #3159 . Have you checked for redundancy and conflicts?

As best I can tell there is very little overlap. I think #3337 moves a a couple of add_subdirectory statements that we also move, but their placement seems like it'd work fine for us. #3159 uncapitalizes an add_custom_target that we also touch but that's functionally equivalent.

Could you explain why do you need those changes? What are your use cases? What are your issues with the way it is without this PR? We will have to maintain the changes thus we need to understand them and their purpose. In the PR description you mention two copies of mbedtls under the same cmake build system it seems, why do you need that?

The TF-M build system builds two versions of mbedtls(/mbedcrypto). One is a lightweight version that only enables functionality needed by the bootloader to save space, and the second is a full version is used by the crypto service to implement the PSA crypto api.
We're trying to alter the cmake to be more intuitive, and one part of this is that we've switched to building mbedtls by including the directory via include_directories. However, if you do this twice you run into errors where targets are multiply defined, which is a cmake error.
The idea behind these changes is that it allows all targets that would be multiply defined to either be disabled (such as the docs) or renamed by the including project, which removes the issue with multiple definitions.

We're trying to alter the cmake to be more intuitive, and one part of this is that we've switched to building mbedtls by including the directory via include_directories. However, if you do this twice you run into errors where targets are multiply defined, which is a cmake error.

include_directories is a command to define include path. Do you mean add_subdirectory?

The TF-M build system builds two versions of mbedtls(/mbedcrypto). One is a lightweight version that only enables functionality needed by the bootloader to save space, and the second is a full version is used by the crypto service to implement the PSA crypto api.

A quite natural way to build the same project two different ways with cmake is to define two different build trees. Did you consider this option?

The TF-M build system builds two versions of mbedtls(/mbedcrypto). One is a lightweight version that only enables functionality needed by the bootloader to save space, and the second is a full version is used by the crypto service to implement the PSA crypto api.

A quite natural way to build the same project two different ways with cmake is to define two different build trees. Did you consider this option?

That's what we are doing - I think there might be some confusion as to where the conflicts exist. If you have
add_subdirectory(mbedtls ${BUILD_DIR_1}
add_subdirectory(mbedtls ${BUILD_DIR_2}

This would do two builds in two different trees - you're correct in that this is the natural (and only?) way to build the same module twice in the same cmake.
However both of those include directories will run
add_library(mbedtls_static STATIC)

One for each time the mbedtls cmakelists is included. This will fail on the second run because cmake doesn't allow two targets to exist with the same name, even if they have been specified with different build directories. As far as I can tell cmake always treats targets as global, and has no concept of scoping of targets.

Two build trees, yes, but I am not sure about the two add_subdirectory() to generate those two build trees. Adding twice the same sub-directory does not smell good to me. Did you consider other solutions, like copy of the build tree in other directory and run make from there, add_custom_target command ... ?

See I'd lean the other way. I see no reason that using add_subdirectory twice would be an issue - It even has some implicit support in that cmake allows you to select the build tree directory for a source tree dir, without which it would clearly be a bad idea.
Doing a manual copy of the build directory would be tricky - you'd have to manually change all the build parameters in the makefiles. Also, that might break cmake's dependency management, which works well with the double add_subdirectory.

Hi @ronald-cron-arm, could you check to see if these changes were what you were thinking of. I've tried to make the minimal change required to allow the prefix/suffix for targets, and have also included a minor bugfix where some cmake statements were using legacy syntax that was causing compatibility issues. The new syntax is supported since at least cmake version 3.0, which is as far back as their public documentation goes.

Good point, we should probably have at least a cmake build in all.sh where mbedtls_target_prefix is set to not empty string value.

Good point, we should probably have at least a cmake build in all.sh where mbedtls_target_prefix is set to not empty string value.

Do you think it would be better to be added to a current test or as a new one?

Think I've covered all requested changes.

We should wait for the CI to pass at least once with the new changes to all.sh before merging.

The test_cmake_as_subdirectory component of all.sh is falling in the CI:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
FAILED: 1
test_cmake_as_subdirectory: build: cmake 'as-subdirectory' build: command make -> 2
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

The test_cmake_as_subdirectory component of all.sh is falling in the CI:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
FAILED: 1
test_cmake_as_subdirectory: build: cmake 'as-subdirectory' build: command make -> 2
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Have you got a link to the failed CI run so I can take a look?

The test_cmake_as_subdirectory component of all.sh is falling in the CI:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
FAILED: 1
test_cmake_as_subdirectory: build: cmake 'as-subdirectory' build: command make -> 2
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I think this should now be fixed. I've also removed the test from that was added to all.sh and added it to the as-subdirectory test instead, as this seems to be the correct place to test this new feature as it is how it is intended to be used

This change doesn't break existing builds so I'm going to go ahead and merge it. However there's a risk that MBEDTLS_TARGET_PREFIX breaks, since it isn't tested. I've filed https://github.com/ARMmbed/mbedtls/issues/3832 as a wish to have a test.

@gilles-peskine-arm MBEDTLS_TARGET_PREFIX is tested. The cmake_subproject test was modified in this PR to also test this feature.


Bumped checkout version in Github actions configuration.

https://github.com/actions/checkout/releases/tag/v4.0.0

@hramezani Thanks for the review :+1:


Target framework is netstandard2.1

Why the target framework is netstandard2.1?
Now it's not possible to use on a .NETcore3.1 project.
Kind regards,
Arthur

netstandard2.1 was required by EF.core 3.0.
I will migrate lib to 3.1.x and then I will be able to switch to netstandard2.0.

Nuget package is already available

Thank you so much Michal, our automated build is working again. Have nice day!


Upgrade Angular

/////////////////////// IGNORE ////////////////////////
////////////////////// PULL BRANCH angular-upgrade INSTEAD ////////////////////////////
Task:
CODE CHANGES | Angular 7

split to as-split
type casting where SupportedTypes is used
type casting where "filereader.result" is used
app-bar component gradient no longer grades color due to necessary palette changes

black to white icon color change will be necessary unless we decide to fix the gradient.

Closed as a duplicate pull request.


Revise JavaCPP bindings and core package

Streamline core API and reduce redundancies in JavaCPP wrapper.
The API for creating and writing ArrayJ looks like this now:
DeviceJ device = DeviceJ.getDefaultDevice();
ArrayJ arrayJ = device.createArray(DataType.UINT8, MemoryType.BUFFER, 4, 3);
// or, alternatively:
// ArrayJ arrayJ = new ArrayJ(4, 3, 1, 2, device, DataType.UINT8, MemoryType.BUFFER);

byte[] inValues = new byte[4 * 3];
arrayJ.writeFromArray(inValues);

byte[] outValues = new byte[4 * 3];
arrayJ.readToArray(outValues);

Changes in more detail:

cle::dType and cle::mType are represented as Java enums net.clesperanto.core.DataType and net.clesperanto.core.MemoryType

Reduce memory copying functions in cleasperantoj.hpp to only the primitive types. The distinction between signed and unsigned is unnecessary. Corresponding Java methods are in MemoryJ instances MemoryJ.BYTE, MemoryJ.SHORT, MemoryJ.INT, MemoryJ.FLOAT. The DataType enum has a memory() method that maps to the appropriate MemoryJ instance. For example, DataType.UINT8.memory() == MemoryJ.BYTE.

Move ArrayJ create/read/write methods into ArrayJ.

Revise ImgLib2Converters and ImageJConverters to not go through an additional ByteBuffer. Just copy from/to primitive arrays directly.

ArrayJ constructors can extract Device from underlying _ArrayJ directly. So we don't need the ArrayJ(_ArrayJ, DeviceJ) constructor anymore. However, this is left in for now, until we replace all the call sites in Tier1, Tier2, etc. (This should be done through gencle?)

There is a bit of confusion of how to handle width/height/depth/dimensions of an cle::Array consistently. I'll make a separate GitHub issue about that.

However, this is left in for now, until we replace all the call sites in Tier1, Tier2, etc. (This should be done through gencle?)

Yes, I will update gencle accordingly.
I will merge this along the update of gencle


Add support for docker load

This PR is an attempt to implement support for docker load.
Related issue #253.
It first makes a small refactor by moving out the run command code into its own file and making the hooks/command file only the entry point. This is the same structure that buildkite-plugins/docker-compose-buildkite-plugin uses. It then introduces a new file for the docker load command.

The example added in the README file is the use case that I was thinking of and that we need. I'm not sure if it makes sense to use load without running a container afterwards though.

Yes I agree with that in the current state, I'll make the run required. Although I do think it can make sense in the future if other commands like push are implemented.

Thanks for the feedback. Fixed the comments now.

Finally got around to fixing the comments.


Strange behaviour with word "general"

I am getting a little crazy because I do not understand the following behaviour. I have a couple of objects like these:
{
  category: "general"
  title: "a title"
}

When I search for "general", I get results only as long as I type up to "gener". Typing "genera" or "general" removes all matching results.
The word "general" is not part of the stopwordfilter.js, as far as I understand. So what is causing this? Changing it to "generol" works just fine. It seems to be this specific phrase, but I could not find any hint in the repo.
lunr(function() {
this.ref("path");
this.field("category");
this.field("title");
docs.forEach(function(docObj) {
    this.add(docObj);
}, this);
});

idx(tree)
.query(function(q) {
    q.term(query.toLowerCase(), {
    wildcard:
        lunr.Query.wildcard.LEADING | lunr.Query.wildcard.TRAILING
    });
})

The same occurs with "introduction" ... it works until the "T" in "introducTion". Am I missing a basic concept?

@tknuth When you say you changed "general" to "generol", is this in the document, or in the query?
The reason for this comes down to the interaction between wildcards and stemming - judging from a little test I ran, the stemmer removes the al suffix from words, so "general" is stored in the inverted index as "gener".  When you're using wildcards with your input, "gener" will match any prefix of itself up to "gener" - as you observed - but once you query with "genera", lunr starts looking for tokens that contain "genera".  Since "gener" doesn't contain that string, it doesn't contribute towards a match.
Let's back up a bit and talk about things at a higher level - what are you trying to use lunr to do?  It might be possible with some tweaking to the index builder, or it could be that lunr isn't a good fit for your use case.  Let's have a discussion to see if lunr works for you!

@tknuth I think your approach of having two separate indices would work, but as you point out, you could run into performance issues.  Another potential issue is the ranking of search results - I'm not exactly sure how that would shake out when merging result lists.  @olivernn and I were having a discussion about this issue on one of my projects using lunr here - I plan on experimenting with different approaches in the near future.  I'll follow up here if I feel like I find a good solution!

I've seen this error as well and the solution that is often mentioned is to remove stemmer.
I found a different solution that allows keeping both the stemmed result as well as wildcarded w/o the need for another index.
var idx = lunr(function () {
  this.ref('id')
  this.field('text')
  this.pipeline.remove(lunr.stemmer)
  // replace original stemmer with one that returns two tokens
  this.pipeline.add((token) => {
    const clone = token.clone()
    return [lunr.stemmer(token), clone]
  })
  this.metadataWhitelist = ['position']

  autocompleteWithIds.forEach((doc) => {
    this.add(doc)
  })
})

// const result = idx.search('*billing*')
const result = idx.query((q) => {
  // for each word add two queries: one with wildcard, one w/o
  q.term('billed*', { wildcard: lunr.Query.wildcard.TRAILING | lunr.Query.wildcard.LEADING })
  q.term('billed')
})

This will result in stemming the search terms and then will look for "bill" as well as billed*. If you indexed "billing" it will work for "billing", "bill", "billed", etc


Add Windows and macOS CI for PR and master builds

Currently PRs and master builds are only end-to-end tested on Linux, and not on Windows and macOS.
macOS and Windows are only tested in a private CI at release time.
Having a complete CI on this repo would avoid this kind of bug happing during the release: https://github.com/code-ready/crc/issues/1549

When we initially thought about this, we couldn't find a suitable free CI infra for doing this, Right now if we want to use the downstream resources, we could go that route by integrating it with github but not sure if that'd be possible, another way is to use the GCE resources. @guillaumerose do you have any ideas?


Character attributes like height, weight, hair color do not import

Needs JSON updated in HD to fix.

Fixed JSON export and added code to populate.


Closebutton does not work ("success"-panel after saving)

The "success"-panel "You just edited OpenStreetMap!" that appears after saving some edits
does not go away when the close-button is pressed.
As a workaround, I press "Export", and the close-button there...
Also, it would be nice to show something useful in that success-panel,
e.g. the changeset-number, the number of edits done,
that kind of info...

@hajo4 is this also in Palemoon browser
(you mentioned in #2490)


secondaryFiles referenced inside tool not included when running a CWL workflow

cwltoil doesn't copy secondaryFiles to the staging area if they aren't specified in the top level workflow file. I have a workflow that runs fine in cwltool but fails with
[Errno 2] No such file or directory ...

when run via cwltoil.
Simplified Example
Details for a workflow with a single input data file that runs wc on it's secondaryFile.
Workflow file wc-workflow.cwl
This file has input somefile that doesn't reference any secondaryFiles. I expected this to be inferred from the tool file.
cwlVersion: v1.0
class: Workflow
inputs:
  somefile:
    type: File

outputs:
  classout:
    type: File
    outputSource: wordcount/output

steps:
  wordcount:
    run: wordcount.cwl
    in:
      somefile: somefile
    out:
      - output

Tool file wordcount.cwl.
Specifies somefile has a secondaryFile with the extension .log. This tool returns the output from wc <somefile>.log
cwlVersion: v1.0
class: CommandLineTool
baseCommand: wc
requirements:
  - class: InlineJavascriptRequirement
stdout: output.txt
label: wc pairs of files
doc: wc pairs
inputs:
  somefile:
    type: File
    secondaryFiles:
      - .log
arguments:
  - valueFrom: $(inputs.somefile.path + '.log')
outputs:
  output:
    type: stdout

Job order file wordcount.json
{
  "somefile": {
     "class": "File",
     "path": "data.txt"
  }
}

How to run:
cwltoil wc-workflow.cwl wordcount.json

Fails with:
ValidationException: :1:1: [Errno 2] No such file or directory: '/var/folders/fs/vv08ppmd1mj7g35hyq5m_7nr0000gp/T/toil-86b1c2c0-787e-4edf-a008-baaae56a25f9/tmp4gDukI/987fdd3e-0cda-415c-8c97-76824e1fdd72/tuuC8qN/inp/tmpExS9RP/data.txt.log'

It works fine with cwltool/cwl-runner:
cwltool wc-workflow.cwl wordcount.json

Work around
If I change my workflow file(wc-workflow.cwl) to include the secondaryFile information(duplicated from the tool file) cwltoil works fine.
cwlVersion: v1.0
class: Workflow
inputs:
  somefile:
    type: File
    secondaryFiles:
      - .log
...

Here is the repo from this example: https://github.com/johnbradley/toil-secondary-bug
Thanks.

In general, CWL implementations are not expected to do that kind of inference.  So you need to use the workaround and copy the secondaryFile pattern to the toplevel of the workflow.


Update MS PowerToys to 0.22.0

https://github.com/microsoft/PowerToys/releases/tag/v0.22.0-Experimental

Package Requested
Manifest:
Fill out as much of the manifest as you can:
Id: string # publisher.package format
Publisher: string # the name of the publisher
Name: string # the name of the application
Version: string # version numbering format
License: string # the open source license or copyright
InstallerType: string # enumeration of supported installer types (exe, msi, msix, inno, wix, nullsoft, appx)
Installers:
  - Arch: string # enumeration of supported architectures
    Url: string # path to download installation file
    Sha256: string # SHA256 calculated from installer
# ManifestVersion: 0.1.0

Add experimental to the name like Power Toys - Experimental so stable can be installed instead if desired.

we intentionally did not release on winget as we require a driver to be HDC signed to prevent the prompt.  This prompt causes silent install to not work

Add experimental to the name like Power Toys - Experimental so stable can be installed instead if desired.

Hi
How do I type the command the get install successfully?
I tried:
winget install powertoys -experimental
But -experimental is not a valid flag and doing without experimental ends with the same error:
Successfully verified installer hash Starting package install... Installer failed with exit code: 1

To install the experimental release, please use the exe on github currently.  It is currently not a silent installer hence we didn't add a Winget manifest.

As this seems to have been intentional for 0.22.0 I'm closing this issue.


nightly/audit: Temporary ignore RUSTSEC-2024-0006

shlex is currently only being brought by bindgen, which does not use the concerning APIs except for testing.
This needs spiffe to be upgraded to be finally be resolved, which will not happen now.

Can you add a small comment on top of the ignore command?


useQuery randomly not returning data and stuck in loading

Describe the bug
After upgrading to react-query 3.5.11 from 2.26.4 last week, our project's Cypress tests started failing randomly because the app started showing a loading spinner at random times. After a lot of head-banging, we finally tracked down the issue: even though, based on the network inspector, the request had gone through successfully, react-query's useQuery was returning an object with isLoading as true and data as undefined. Reverting back to react-query 2 fixed the problems.
Most of the requests in our Cypress tests are stubbed using cy.server and cy.route. This probably shouldn't affect react-query but mentioning it here just in case.
Our cache is configured in the following manner at the top of one of our source files, so this shouldn't be caused by us accidentally creating multiple caches:
const queryCache = new QueryCache({
  defaultConfig: {
    queries: {
      staleTime: 10 * 60 * 1000,
      cacheTime: 15 * 60 * 1000,
      retry: (
        _failureCount,
        error: any,
      ) => error.status !== 403 && error.status !== 401,
    },
  },
});

// Further down:

class AppProvider extends Component<{}, State> {
  public render() {
    return (
      <ReactQueryCacheProvider queryCache={queryCache}>
        {/* ... */}
      </ReactQueryCacheProvider>
    );
  }
}

To Reproduce
Unfortunately, this happens randomly and is thus very hard to reproduce. The randomness does point towards some type of race condition. Our app performs many (~10) requests on startup.
Even though which tests fail is random, I can consistently get at least one test to fail. Is there something I can do to help track down what could be the issue?
Expected behavior
useQuery should return the data it receives in the response once the request is successful.
Desktop (please complete the following information):

OS: MacOS
Browser: Chrome
Version: 87

Additional context
Happens on both Cypress version 5.3.0 and 6.2.1.

this looks surprisingly similar to https://github.com/tannerlinsley/react-query/issues/1657

this looks surprisingly similar to https://github.com/tannerlinsley/react-query/issues/1657

Don't know how the tests are written but it might be good to check if they do not implicitly depend on certain timings. Are you able to reproduce it manually? This might be useful: https://docs.cypress.io/guides/core-concepts/retry-ability.html

Don't know how the tests are written but it might be good to check if they do not implicitly depend on certain timings. Are you able to reproduce it manually? This might be useful: https://docs.cypress.io/guides/core-concepts/retry-ability.html

Don't know how the tests are written but it might be good to check if they do not implicitly depend on certain timings. Are you able to reproduce it manually? This might be useful: https://docs.cypress.io/guides/core-concepts/retry-ability.html

I haven't noticed this problem when using the app manually, so there's always a chance that this is somehow caused by Cypress. But a few reasons why I think this may be an issue with react-query:

The error (loading spinner) occurs on app startup, before any interaction from Cypress. So it shouldn't be due to timing of commands/assertions.
The problem goes away when react-query is downgraded to an old version.
When inspecting the app, the network requests show that the response was received by the app but the related useQuery call returns undefined for data.

I'll see if I can narrow down the react-query version where this started happening.

Don't know how the tests are written but it might be good to check if they do not implicitly depend on certain timings. Are you able to reproduce it manually? This might be useful: https://docs.cypress.io/guides/core-concepts/retry-ability.html

I haven't noticed this problem when using the app manually, so there's always a chance that this is somehow caused by Cypress. But a few reasons why I think this may be an issue with react-query:

The error (loading spinner) occurs on app startup, before any interaction from Cypress. So it shouldn't be due to timing of commands/assertions.
The problem goes away when react-query is downgraded to an old version.
When inspecting the app, the network requests show that the response was received by the app but the related useQuery call returns undefined for data.

I'll see if I can narrow down the react-query version where this started happening.

I can confirm the same behavior after migrating from 2.23.1 to 3.5.16.
isLoading is randomly returning true for queries with staleTime option. Everything works without staleTime.

I can confirm the same behavior after migrating from 2.23.1 to 3.5.16.
isLoading is randomly returning true for queries with staleTime option. Everything works without staleTime.

Would be great if you guys could to provide a sandbox or something similar which we can use to debug the issue.

Would be great if you guys could to provide a sandbox or something similar which we can use to debug the issue.

Would be great if you guys could to provide a sandbox or something similar which we can use to debug the issue.

I've tried to reproduce in a sandbox without any luck (

Would be great if you guys could to provide a sandbox or something similar which we can use to debug the issue.

I've tried to reproduce in a sandbox without any luck (

Commenting just to subscribe to the thread because I'm having the same issue and can't reproduce it on a sandbox. Happens  on v2.26.3 and after updating to v3.6.0.

Commenting just to subscribe to the thread because I'm having the same issue and can't reproduce it on a sandbox. Happens  on v2.26.3 and after updating to v3.6.0.

Can we try to narrow it down collectively? So far, we've seen that:

it apparently still works on 2.23.1 according to @antonversal
it's no longer working on 2.26.3 according to @josewhitetower

could you further narrow it down to a specific version between those two?
staleTime seems to be involved, but how do you set staleTime?  via the default-config on the global cache like @vsaarinen has shown in the opening post (similar to what @fTrestour has posted in #1653), or are you setting the staleTime on the useQuery call directly?

Can we try to narrow it down collectively? So far, we've seen that:

it apparently still works on 2.23.1 according to @antonversal
it's no longer working on 2.26.3 according to @josewhitetower

could you further narrow it down to a specific version between those two?
staleTime seems to be involved, but how do you set staleTime?  via the default-config on the global cache like @vsaarinen has shown in the opening post (similar to what @fTrestour has posted in #1653), or are you setting the staleTime on the useQuery call directly?

I'm also seeing that both the opening post in this issue as well as in #1653 have the retry option set - could we rule that one out as well?

I'm also seeing that both the opening post in this issue as well as in #1653 have the retry option set - could we rule that one out as well?

@TkDodo I set staleTime in useQuery. No global settings and retry.

@TkDodo I set staleTime in useQuery. No global settings and retry.

Can we try to narrow it down collectively? So far, we've seen that:

it apparently still works on 2.23.1 according to @antonversal
it's no longer working on 2.26.3 according to @josewhitetower

could you further narrow it down to a specific version between those two?

For me, things work fine on 2.26.4. I'll try to find which version of 3 causes things to start breaking again.

Can we try to narrow it down collectively? So far, we've seen that:

it apparently still works on 2.23.1 according to @antonversal
it's no longer working on 2.26.3 according to @josewhitetower

could you further narrow it down to a specific version between those two?

For me, things work fine on 2.26.4. I'll try to find which version of 3 causes things to start breaking again.

Started seeing the same issues after upgrading to 3.2.0. So it appears to be a regression introduced in version 3.

Started seeing the same issues after upgrading to 3.2.0. So it appears to be a regression introduced in version 3.

Started seeing the same issues after upgrading to 3.2.0 from 2.26.4. So it appears to be a regression introduced in version 3.

I have the same issue

Started seeing the same issues after upgrading to 3.2.0 from 2.26.4. So it appears to be a regression introduced in version 3.

I have the same issue

I have the same issue, at leat in my case I found this:
When is stuck it seems it's because the refectch is returning the same object, when the query is stuck this console.log prints true on the console:
const { data, refetch } = useQuery(...)
...
refetch().then(response => console.log(response.data === data));

I have the same issue, at leat in my case I found this:
When is stuck it seems it's because the refectch is returning the same object, when the query is stuck this console.log prints true on the console:
const { data, refetch } = useQuery(...)
...
refetch().then(response => console.log(response.data === data));

I have the same issue, it's doing it randomly like the others are reporting. I've found this:
When it's stuck refetch() returns the same object, when the query is stuck this console.log prints true and when it's not stuck prints false:
const { data, refetch } = useQuery(...)
...
refetch().then(response => console.log(response.data === data));

Calling refetch() again when the data is the same doesn't work, returns the same data again, so there is no workaround possible yet.
Edit: Upgraded from 3.5.1 to 3.6.0 and the problem is still happening but at least this time calling refetch() again when the query is stuck doesn't return the same object so it's a workaround:
const { data, refetch } = useQuery(...)
...
refetch().then(response => {
    if(response.data === data){
        refetch()
    }
});

I have staleTime: Infinity on the new QueryClient() (global setting)
Using version: 3.5.1
Reproducing this on a sandbox takes a lot of effort and time I don't have. This bug already took a lot of my time and it's a blocker for me.

Self-response: I finally found the cause at least for my specific case.
React-query performs a deep compare to update the component, so if your request returns the same data than in the previous request, react query will not update your component. This was happening randomly because the response of my request contains random changes and sometimes returns the same data. So if you trigger a request you should not expect a component re-render unless the returned data from the server is different according to the deep compare function of react-query. In my case the returned data was not different and I was expecting a re-render because I have my own logic to deal with the server returning the same data.
The solution in case you have the same problem is to disable deep compare setting structuralSharing to false like this:
export const queryClient = new QueryClient({
   defaultOptions: {
      queries: {
         staleTime: Infinity,
         structuralSharing: false
      },
      mutations: {}
   }
});

This feature was introduced because of this issue:
https://github.com/tannerlinsley/react-query/issues/430

I have the same issue, it's doing it randomly like the others are reporting. I've found this:
When it's stuck refetch() returns the same object, when the query is stuck this console.log prints true and when it's not stuck prints false:
const { data, refetch } = useQuery(...)
...
refetch().then(response => console.log(response.data === data));

Calling refetch() again when the data is the same doesn't work, returns the same data again, so there is no workaround possible yet.
Edit: Upgraded from 3.5.1 to 3.6.0 and the problem is still happening but at least this time calling refetch() again when the query is stuck doesn't return the same object so it's a workaround:
const { data, refetch } = useQuery(...)
...
refetch().then(response => {
    if(response.data === data){
        refetch()
    }
});

I have staleTime: Infinity on the new QueryClient() (global setting)
Using version: 3.5.1
Reproducing this on a sandbox takes a lot of effort and time I don't have. This bug already took a lot of my time and it's a blocker for me.

Self-response: I finally found the cause at least for my specific case.
React-query performs a deep compare to update the component, so if your request returns the same data than in the previous request, react query will not update your component. This was happening randomly because the response of my request contains random changes and sometimes returns the same data. So if you trigger a request you should not expect a component re-render unless the returned data from the server is different according to the deep compare function of react-query. In my case the returned data was not different and I was expecting a re-render because I have my own logic to deal with the server returning the same data.
The solution in case you have the same problem is to disable deep compare setting structuralSharing to false like this:
export const queryClient = new QueryClient({
   defaultOptions: {
      queries: {
         staleTime: Infinity,
         structuralSharing: false
      },
      mutations: {}
   }
});

This feature was introduced because of this issue:
https://github.com/tannerlinsley/react-query/issues/430

@fermmm It sounds like your issue may be different than what I'm experiencing. My issue is that even though data was successfully received by the app, useQuery thinks that it's still loading the data and never provides it to the app.

@fermmm It sounds like your issue may be different than what I'm experiencing. My issue is that even though data was successfully received by the app, useQuery thinks that it's still loading the data and never provides it to the app.

@fermmm It sounds like your issue may be different than what I'm experiencing. My issue is that even though data was successfully received by the app, useQuery thinks that it's still loading the data and never provides it to the app.

Yes my problem looks similar but may be not the same. Unless the response of your server is empty and there is no cache, so de deep compare function returns that the results are the same, that could be triggering your specific bug. I bet is also caused by deep compare in some way. Try disabling structuralSharing.

@fermmm It sounds like your issue may be different than what I'm experiencing. My issue is that even though data was successfully received by the app, useQuery thinks that it's still loading the data and never provides it to the app.

Yes my problem looks similar but may be not the same. Unless the response of your server is empty and there is no cache, so de deep compare function returns that the results are the same, that could be triggering your specific bug. I bet is also caused by deep compare in some way. Try disabling structuralSharing.

Ok I had this issue in another request of my app and this time was not related with structuralSharing, I noticed {data: undefined,  isLoading: true} randomly without getting the data. The only different thing with this request it was that I had many components mounted that use this query, maybe is something that happens when one component is waiting for the request and other mounts with the same query... I don't know.
I decided to port all my requests to SWR, I tested it a lot and looks really stable, they don't have issues in their github like this one, where random instability happens and nobody can reproduce. Also I noticed they implemented some features first, like the deep equality, also I trust the next.js devs.

Same problem here. In my case I use staleTime: Infinity.
I tested @fermmm workaround and it seems to work, thanks!

I would really like to get to the bottom of this issue, but if nobody can reproduce it in a codesandbox, it is almost impossible to narrow down.

I forgot to add more info: I'm mounting a lot of components (50) that use this useQuery with Infinity staleTime and I don't have configured retry neither. I'm going to try to reproduce it in a sandbox.

I have created a sandbox with the conditions that seem to be common to all of us (Infinity staleTime and having many instances) but cannot reproduce the error, I think it has only happened to me once. On my SPA it happens to me much more easily 🤔

From what I can see in the sandbox: are you also putting the whole result from fetch into the query cache in your app? This includes some non-serializable data, like the body, which is a stream, and lots of functions that return Promises, like .json()...

No no, it was like this because since I don't use data in the example I didn't even worry with the response. I updated it and now I just return the JSON body (like in my app of course)

In my case this only happens when I restart my RN app when all the components are mounting for the first time

I believe my issue has also appeared only on app start, in the initial loading of components.

I believe my issue has also appeared only on app start, in the initial loading of components.

I guess this is the only time when you can be "stuck in loading", because you are never in loading state again once you've successfully loaded data.
Question: In case this being-stuck happens, what do the react-query devtools say about the state of the query?

Question: In case this being-stuck happens, what do the react-query devtools say about the state of the query?

The problematic query is the second from the bottom in the list, with 5 listeners and marked as stale:

I confirmed that the data for that query was received successfully when looking at the network developer tab. The weird thing is that the data is shown correctly in the devtools, but in our app the data property of the objected returned by that useQuery is undefined.

The weird thing is that the data is shown correctly in the devtools, but in our app the data property of the objected returned by that useQuery is undefined.

Yes, that does indeed seem weird. Are you using different staleTimes on the  5 observers? Everyone is mentioning staleTime: Infinity, but in your code, I am seeing a different staleTime - and your query is also marked as stale, which shouldn't be the case with staleTime: Infinity...

Yes, that does indeed seem weird. Are you using different staleTimes on the 5 observers? Everyone is mentioning staleTime: Infinity, but in your code, I am seeing a different staleTime - and your query is also marked as stale, which shouldn't be the case with staleTime: Infinity...

I've never used staleTime: Infinity. Except for a couple of queries where these are overridden, I only use the time values from the defaultConfig as shown in the original post:
      staleTime: 10 * 60 * 1000,
      cacheTime: 15 * 60 * 1000,

I've never used staleTime: Infinity.

thanks, I mixed that up a bit 😅 .

since I don't know what "stale" means.

a stale query is a query that will refetched in the background if a new subscriber mounts / the window is refocussed etc.

the devtools marks the query as stale

judging from the code, the devtools don't manipulate the queries (unless you press one of the buttons). They just display the current state of the cache.

So if  your screenshot is from after the 5 subscribers mount, and you have a staleTime of 10 minutes - why are the queries showing up as stale ? They should show up as fresh (green) - just like the other queries 🤔

So if your screenshot is from after the 5 subscribers mount, and you have a staleTime of 10 minutes - why are the queries showing up as stale ? They should show up as fresh (green) - just like the other queries 🤔

Good question. The top 6 queries in the list should be marked as fresh. Maybe this is related to the underlying cause?

Good question. The top 6 queries in the list should be marked as fresh. Maybe this is related to the underlying cause?

yes, maybe. Are you sure that all subscribers (all instances of useQuery) use the same config? If you have 4 subscribers with staleTime: 10 minutes, and one additional subscriber where the staleTime is 0, the smaller one will "win". Not sure if that could cause this problem ...

Are you sure that all subscribers (all instances of useQuery) use the same config? If you have 4 subscribers with staleTime: 10 minutes, and one additional subscriber where the staleTime is 0, the smaller one will "win". Not sure if that could cause this problem ...

All of the subscribers listed in the screenshots use the default cacheTime of 15 minutes and staleTime of 10 minutes.

Seems like the cache is fine, but maybe one of the observers did not get updated somehow. Can you see in the devtools if one of the observers for that query has an incorrect currentResult?

Seems like the cache is fine, but maybe one of the observers did not get updated somehow. Can you see in the devtools if one of the observers for that query has an incorrect currentResult?

Yep, there's an issue with the observers: the first three have the correct data in currentResult but the last one has invalid data, as shown in the screenshots below.

Just guessing here, but it seems technically possible that a query gets updated between a component mount and its useEffect.

Component mount
Query update
Component useEffect (starts listening for updates)

In such case the component would miss the update.
Could you check if this change fixes it?
--- a/src/core/queryObserver.ts
+++ b/src/core/queryObserver.ts
@@ -528,6 +528,11 @@ export class QueryObserver<
       )

     if (query === prevQuery) {
+      if (query.state !== this.currentResultState) {
+        const prevResult = this.currentResult
+        this.updateResult()
+        if (prevResult !== this.currentResult) {
+          this.notify({ listeners: true })
+        }
+      }
       return
     }

Could you check if this change fixes it?

After a few quick tests, it does seem like this fixes the issue. 🎉 But need to do a bit more testing...
I added the following console logging to make sure that the condition gets hit, and the weird thing is that the this.notify() never seems to be get called but the issue still seems to be fixed.
    if (query === prevQuery) {
      if (query.state !== this.currentResultState) {
        console.warn('!!! query.state !== this.currentResultState !!!')
        const prevResult = this.currentResult
        this.updateResult()
        if (prevResult !== this.currentResult) {
          console.warn('!!! prevResult !== this.currentResult !!!')
          this.notify({ listeners: true })
        }
      }
      return
    }

I can confirm the same behavior after migrating from 2.23.1 to 3.5.16.
isLoading is randomly returning true for queries with staleTime option. Everything works without staleTime.

I'm currently experiencing this same issue. I opened a discussion on this yesterday. Here

Could you check if the issue is fixed in v3.6.1?

Haven't run into failing tests after upgrading to 3.6.1. Let's keep our fingers crossed.
Thanks a lot for the fix!

It seems to solve the problem in my case. Thank you very much!!

Thanks, @boschni. I do not see failing tests anymore as well.

Hello everyone!!!
Has anyone experienced the same behavior but now with useQueries hook?
it doesn't return data and gets stuck in loading randomly in the tests. I appreciate any support
"react": "^16.13.1"
"react-query": "^3.13.4"

@ivillarreal91 I'm seeing this as well with latest, were you able to find a solution? Using useQuery in one component and useQueries with the same key in another component causes the useQuery to get stuck. Going to try to reproduce in a CSB.

@ivillarreal91 I'm seeing this as well with latest, were you able to find a solution? Using useQuery in one component and useQueries with the same key in another component causes the useQuery to get stuck. Going to try to reproduce in a CSB.

I think this is the closest thing that describes the problem, I am currently having a similar issue and I just upgraded to the latest release. if you have keys like baa and baaFoo, the whole pages hangs and is stuck on isFetching

@Toyurc if you have a codesandbox reproduction, please open a new issue with it.

I have the same issue, its stuck at loading, while the exact same code works on another app.

@MatkoMilic again, this is not very helpful I'm afraid. Without an isolated reproduction, there is only so much I can do 🤷

@TkDodo I am also facing the same issue and stuggling to reproduce it.

I also have the same issue in my react native application, it is a random issue, sometimes isLoading and isFetching get stuck and data stays undefined even if the network request is done successfully.

@MatkoMilic again, this is not very helpful I'm afraid. Without an isolated reproduction, there is only so much I can do 🤷

Hello, I'm running 4 API calls in the same component with different keys using "useQuery"  and I used QueriesObserver to see what is happening in the background.
Basically, in the observer, the data is up to date and the isLoading state has changed to false, but this does not reflect on the variables which are extracted from useQuery.
is there a way to force a useQuery to check the observer again?
@TkDodo

@nawfalhaddi if its related to 4 useQuery queries running in parallel, can you reproduce this in a sandbox?

Btw this is on a react native project

Are all problems posted in this issue related to react native?

@TkDodo  I tried to reproduce the issue on sandbox but it's not happening, maybe it's related to react native specifically.
I will create an example repo of react native project and try to reproduce the problem on it, I will share it with you soon.

could this be related to https://github.com/tannerlinsley/react-query/issues/3332 ?

@TkDodo I am experiencing the same issue on version 3.24.4 - isLoading gets stuck on true. I'm using React Native and this happens to me randomly (but only on app startup). It seems to happen about every 1 in 10 or 20 times, so is quite difficult to replicate.
Any update on this?
I also have the same question as @nawfalhaddi:

is there a way to force a useQuery to check the observer again?

Hey y'allz. I've been dealing with this for 8 hours myself and this is my story:
My query that's stuck in loading has an enabled property, and I had a race condition where:

Component would get enabled set to true, so query fires
I have an axios interceptor that calls a function that updates the enabled property above
Before the API call finishes its normal lifecycle (succeed or fail), enabled is set to false before isLoading is flipped back to false. Basically the query gets disabled in a "loading" state.

For me I just needed to call resetQueries, but the race condition made the problem intermittent and it would only happen on app startup. Hopefully it helps somebody

Hey y'allz. I've been dealing with this for 8 hours myself and this is my story:
My query that's stuck in loading has an enabled property, and I had a race condition where:

Component would get enabled set to true, so query fires
I have an axios interceptor that calls a function that updates the enabled property above
Before the API call finishes its normal lifecycle (succeed or fail), enabled is set to false before isLoading is flipped back to false. Basically the query gets disabled in a "loading" state.

For me I just needed to call resetQueries, but the race condition made the problem intermittent and it would only happen on app startup. Hopefully it helps somebody

I'm experiencing the same issue on version 3.38.0. It seems to only happen when my Jest tests are run in CI environment with multiple workers (with --maxWorkers=4 flag). It doesn't happen on my local machine, nor when I set --maxWorkers=1 (single worker mode). DN if the info helps.

imo it doesn't make much sense if more people keep commenting on this closed issue from over a year ago. If you have a consistent reproduction, or any reproduction for that matter, please open a new issue. There isn't much I can do otherwise I'm afraid.

Hi @TkDodo
I have implemented a small application that reproduces the issue described in this discussion. Here is the repo: https://github.com/balteo/react-query-issue-reproduction
Just git clone the repos and yarn install and yarn run test
Please let me know if I can help further.
Kind regards

I renamed the port-to-v3 label as port-to-v4, that was probably not a good idea, sorry.
code is quite different now, I would need to see a codesandbox reproduction that fails on v4 please.
the code path you're showing has been removed in a later v3 version to ensure concurrent rendering capabilities:

https://github.com/TanStack/query/pull/1775/files#diff-93f379800fc8abf895eba249b2e2371eda98740aa40fc9f284a8088d190f46c3L97

I am going to add a +1 to this. I am facing this exact issue where isLoading gets stuck in true and data comes back as undefined.  I am using the same query in two components the first component fires the query and gets the data fine, but on the second component the same query (with the same key) gets stuck and returns undefined. This is a bizarre situation that I am not sure I am able to wrap my head around.
Here's whats happening
Component - 1
    Query 1 --> Works
    Query 2 --> Works

Component - 2
   Query 1 --> Works with same key as in component 1
   Query 2 --> Doesn't Work with same or different key

ok sheesh i think i found the issue. With Multiple queries comes multiple isLoading the part of the component that depended on the second query was rendering too soon causing the issue. So these multiple isLoadings and checking of data for each of these queries will need to be handled individually. Any early rendering causes the query status to stay stuck (or rather give the illusion i should say).

I am experiencing this issue consistently in a larger project with
    "@tanstack/react-query": "4.26.0",
    "react": "18.2.0",
    "next": "13.2.3",

but only if react is running in strict mode.
Unfortunately I do not have a minimal repro example.

I am facing the same issue only in Cypress.
Devtools indicate that the data is fresh but the loader is still loading (isFetching).

@agos thanks for the clue about invalidating a query being the cause. in my case im doing cancelQueries instead. i tried adding await in front and now it works! not sure if this helps.

One thing to remember if you're in the MSW/Testing land - set retry to 0 during testing.
Remember that Query intentionally backs off over a period of time to retry searching, upwards of a couple of seconds. This is a good thing, as it leads to better UX.
As a result, my tests were failing until I did this.

We also faced the same issue where for some reason some users were not able to fetch the data properly.
On further debugging found the fetchStatus was always paused. After going through docs, we passed the networkMode: always and it worked fine this time. We also verified this by removing the networkMode config.
So this probably means something wrong is happening in the code when the default networkMode: on value is set.
cc @TkDodo

So this probably means something wrong is happening in the code

no, this is an issue with navigator.onLine in chrome on macos, which we are using in v4 to determine if you are online or not.

https://github.com/TanStack/query/issues/5644
https://github.com/TanStack/query/issues/5679#issuecomment-1623038531

Since navigator.onLine is broken, we've moved away from using it in v5

Since navigator.onLine is broken, we've moved away from using it in v5

Thanks for the quick reply, will upgrade to v5.

I just needed to upload it to the new version of Chrome, now it's working.

macOS: Ventura 13.5.2

See am encountering the same issue with v4.36,
It tends to make requests successfully to jsonplaceholder however when I make a request to my local server it then stucks on the loading,
When I use the use Effect hook and state everything works well, I've seen this stuck issue has been perturbing from v2 all the way to v4, why on earth haven't you figured out why your library behaves like this, it's pretty frustrating and I'll chose to revert to the older way of fetching data 😡😡😡😡😠😠

It's quite strange.

again, I'm positive that this is related to navigator.onLine being broken in chrome, which is not our fault. What is our fault is that we were relying on it to work properly in the first place, which is what we've changed in v5.
you can validate that assumption by looking at the fetchStatus returned from useQuery when that happens. If the fetchStatus is 'paused', you'll know that this is indeed the case.
again, you can:

update to v5, which has a different default behaviour
set networkMode: 'offlineFirst' to work around it
get the bugs fixed in chrome 🤷

It's quite strange.

again, I'm positive that this is related to navigator.onLine being broken in chrome, which is not our fault. What is our fault is that we were relying on it to work properly in the first place, which is what we've changed in v5.
you can validate that assumption by looking at the fetchStatus returned from useQuery when that happens. If the fetchStatus is 'paused', you'll know that this is indeed the case.
again, you can:

update to v5, which has a different default behaviour
set networkMode: 'offlineFirst' to work around it
get the bugs fixed in chrome 🤷

Thank you for responding, however, it happens randomly across different browsers including Edge, Brave, etc.
I will try upgrading to v5.

edge and brave are both built on chromium ... they are the same thing and have the same behaviour / bugs in this regard

Firefox 120.0.1 (64-bit) still occurring  M2 Mac, Sonoma 14.1.1

@117 on query v4 or v5? We haven't done anything on v4 - and also won't because the fix / workaround was a change in behaviour, so it's a breaking change

I believe I'm seeing this issue in react native when the app first launches. I'm positive I prefetch data and the prefetching resolves. When I query that data with the same key after navigating to a new page with the stack navigator, it returns undefined for a while. If I launch the app and wait about 5 seconds before navigating to the screen, the data is there. So for me it is shortly after app launch, which unfortunately is the most critical time for my app to work quickly.
I'm using v4. I haven't shifted to v5 because it requires a lot of rewriting onSuccess logic. Does v5 resolve the issue?

@lundstromdavid it seems like you're clearing the cache while the query is in-flight, I don't know why you would do something like that. clear() is not the same as resetQueries() because clear does not inform observers about the change

@TkDodo Thanks for the reply! Should have read up more before. Although it does seem quite unintuitive for me that clear() can stall in-flight queries in a loading state, but what I do know :man_shrugging:

can confirm this indeed happens with react: 18.2, and @tanstack/react-query 4.36.1 on post request when running jest test with axios 1.6.2 and axios-mock-adapter 1.22.0, still happens after upgrading @tanstack/react-query to 5.17.19, I can see the result in useQuery, but it never returns to the component, and the status is always loading; hence used vanilla axios for my failed test and everything passes.
Also found a very hacky workaround if you don't want to replace @tanstack/react-query with other libraries: basically just do a data fetching with axios-mock-adapter in beforeAll or beforeEach, then run your regular test, and in your test block, do a data fetching with axios-mock-adapter again... your test will then have about 1/2 chance of passing... super confusing bug

One thing you can try on v5 is to disable our batching and see if that helps:
import { notifyManager } from '@tanstack/react-query'

// invoke callback instantly
notifyManager.setScheduler((cb) => c())

see: https://tanstack.com/query/latest/docs/reference/notifyManager#notifymanagersetscheduler

I would like to recommend changing the default setting of the networkMode configuration in React Query to 'always'. Given the library's widespread use, with over 200 million downloads per week, the current default setting may lead to significant issues.
Recently, we encountered a bug where the system did not make any network requests due to the networkMode being set to 'online'. This issue arose because the browser's navigator.onLine API inaccurately reported the network status as offline, even though the connection was active. The impact of this bug is particularly severe as it can cause key pages to remain stuck on a loading screen without any indication of the problem. Considering that React Query is a critical part of many projects, such errors can have drastic consequences, including potential job losses, especially if key stakeholders encounter these issues firsthand.
It can be challenging to identify this issue without delving into the source code, making it a silent but deadly problem. To enhance reliability and prevent such problematic scenarios, I strongly urge you to consider setting the default networkMode to 'always'. This change would ensure that network requests are made regardless of the navigator.onLine status, thus providing a more consistent and dependable user experience.
Thank you for considering this suggestion. I believe it will significantly improve the robustness of React Query and safeguard many developers and businesses from facing similar issues.

you can set the scheduler inside cypress tests only.


build error (unresolved dependency)

(...)

    Aborting...

Any suggestions how to fix this? Thanks

Add this line to the flags.archlinux.gn file: icu_use_data_file=false
Will commit it later

already pushed an update, it should build now.


Create Option to Insert Ref after Note Extraction

Is your feature request related to a problem? Please describe.
This is a feature request.
Describe the solution you'd like
When I am extracting text from a note into another file, I would like a ref inserted at the point of extraction.
Describe alternatives you've considered
Currently, I have to copy the note ref and navigate back to the note that I just extracted from to paste the ref in.

Hey, @theianjones, I know this is an old issue, but there is now a LeaveTrace configuration option you can set in dendron.yml to leave a reference when extracting text to a new note. Does this help?